Feature #6725

Serial # for x509 certificates

Added by Ken Barber about 1 year ago. Updated 4 months ago.

Status:Accepted Start date:03/15/2011
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:SSL
Target version:Waldorf
Affected Puppet version:2.6.6 Branch:
Keywords:
Votes: 1

Description

So the way we sequentially assign serial numbers for certificates is not optimal and forces us to do weird things like locking files to ensure we avoid duplication. The reality is a serial number in an x509 certificate does not need to be sequential, it just needs to be random:

http://tools.ietf.org/html/rfc5280#page-19

Now I believe the RFC wording can support a serial number up to 20 octets wide. If this is the case we can probably just use uuids (which are 16 octets wide?) … which would reduce the amount of collision possibilities.

There are a few reasons that this is beneficial:

  • to allow us to potentially remove the locking of our serial file. I found in the past this locking reduces scalability in cases of en-masse auto-signing.
  • Also – in auto-sign situations – this removes the need to have a single CA for sequential serial allocation … if the serials are uuids they have a low chance of collision more or less. In the future if we move cert storage to a central place we can avoid having to lock for the next number as well.

Related issues

related to Puppet - Feature #8278: Puppet cert should safeguard itself when revoking. Rejected 07/06/2011

History

#1
Updated by Garrett Honeycutt about 1 year ago

Great suggestion using UUID’s.

This functionality is critical to allow for the common situation where you have multiple CA servers sharing an SSL directory so that all nodes may work with all CA servers.

#2
Updated by Ben Hughes about 1 year ago

  • Status changed from Unreviewed to Accepted

#3
Updated by Luke Kanies about 1 year ago

  • Category changed from SSL to ssh

I’m comfortable with this as long as ‘they have to be random’ changes to ‘they cannot collide’. It’s true we’ve chosen a naive means of making sure they don’t collide, and UUIDs would be better as long as we can be sure of the lack of collision.

#4
Updated by Daniel Pittman about 1 year ago

4.1.2.2.  Serial Number

   The serial number MUST be a positive integer assigned by the CA to
   each certificate.  It MUST be unique for each certificate issued by a
   given CA (i.e., the issuer name and serial number identify a unique
   certificate).  CAs MUST force the serialNumber to be a non-negative
   integer.

We can’t use an unmodified UUID, but we can use the bignum representation of one. A generally satisfactory version would be a UUID v5 based on the CN and/or ancillary data present in the certificate, which ensures we are as unique as SHA-1 over a controlled set of inputs is, without coordination. Otherwise, a v2 or v4 with a decent PRNG would probably work, but would need checking to ensure they don’t have risk of collision when one of the randomness inputs fails…

#5
Updated by James Turnbull 5 months ago

  • Category changed from ssh to SSL

#6
Updated by James Turnbull 5 months ago

  • Status changed from Accepted to Needs Decision
  • Assignee set to Nigel Kersten

#7
Updated by Josh Cooper 5 months ago

This wouldn’t be a problem if we supported trust chains right? Have a top level CA that is used to sign intermediate CAs, each of which can then issue certs serially.

#8
Updated by Nigel Kersten 5 months ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Nigel Kersten)

That would also work, but would be more complicated to set up than the shared NFS directory many people run with.

I concur with Luke that “I’m comfortable with this as long as ‘they have to be random’ changes to ‘they cannot collide’. ”.

#9
Updated by Ben Hughes 4 months ago

  • Description updated (diff)
  • Status changed from Accepted to Unreviewed

#10
Updated by Michael Stahnke 4 months ago

  • Description updated (diff)
  • Status changed from Unreviewed to Accepted
  • Target version set to Waldorf

I think Josh’s suggestion is the more correct way of doing it, but possibly more complicated for many implementations.

If we’re going to make this change, I imagine it would not be very soon.

Also available in: Atom PDF