The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
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
This ticket may be automatically exported to the PUP project on JIRA using the button below:
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 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
184.108.40.206. 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 almost 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 2 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.