The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Feature #6725

Serial # for x509 certificates

Added by Ken Barber almost 4 years ago. Updated over 1 year ago.

Status:AcceptedStart date:03/15/2011
Priority:NormalDue date:
Assignee:Charlie Sharpsteen% Done:

0%

Category:SSL
Target version:Waldorf
Affected Puppet version:2.6.6 Branch:
Keywords: customer

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket may be automatically exported to the PUP project on JIRA using the button below:


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
Related to Puppet - Feature #3143: Fully support multiple CAs and CA trust chains in Puppet Closed 02/03/2010

History

#1 Updated by Garrett Honeycutt almost 4 years 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 almost 4 years ago

  • Status changed from Unreviewed to Accepted

#3 Updated by Luke Kanies over 3 years 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 Anonymous over 3 years 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 about 3 years ago

  • Category changed from ssh to SSL

#6 Updated by James Turnbull about 3 years ago

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

#7 Updated by Josh Cooper about 3 years 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 about 3 years 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 almost 3 years ago

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

#10 Updated by Michael Stahnke almost 3 years 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.

#11 Updated by Charlie Sharpsteen over 1 year ago

  • Assignee set to Charlie Sharpsteen

#12 Updated by Charlie Sharpsteen over 1 year ago

  • Support Urls deleted (http://this.is.a.customer.ticket/zynga)

Test.

#13 Updated by Charlie Sharpsteen over 1 year ago

  • Keywords set to customer

Also available in: Atom PDF