The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
Serial # for x509 certificates
|Assignee:||Charlie Sharpsteen||% Done:|
|Affected Puppet version:||2.6.6||Branch:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
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:
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.
#3 Updated by Luke Kanies over 4 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 4 years ago
18.104.22.168. 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…
#8 Updated by Nigel Kersten over 3 years ago
- Status changed from Needs Decision to Accepted
- Assignee deleted (
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’. ”.
#10 Updated by Michael Stahnke over 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.