[openssl-users] Personal CA: are cert serial numbers critical?

Robert Moskowitz rgm at htt-consult.com
Wed Aug 16 20:24:59 UTC 2017

On 08/16/2017 11:58 AM, Erwann Abalea via openssl-users wrote:
> Bonjour,
>> Le 16 août 2017 à 16:51, Jakob Bohm <jb-openssl at wisemo.com> a écrit :
>> On 16/08/2017 16:32, Tom Browder wrote:
>>> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users <openssl-users at openssl.org <mailto:openssl-users at openssl.org>> wrote:
>>>     ➢ So, in summary, do I need to ensure cert serial numbers are
>>>     unique for my CA?
>>>     Why would you not?  The specifications require it, but those
>>>     specifications are for interoperability. If nobody is ever going
>>>     to see your certs, then who cares what’s in them?
>>> Well, I do like to abide by specs, and they will be used in various browsers, so I think I will continue the unique serial numbering.
>>> Thanks, Rich.
>> Modern browsers increasingly presume that such private CAs behave exactly
>> like the public CAs regulated through the CA/Browsers Forum (CAB/F) and
>> the per-browser root CA inclusion programs (the administrative processes
>> that determine which CAs are listed in browsers by default).
>> Among the relevant requirements now needed:
>> - Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as standalone
>> numbers and as DER-encoded numbers.  Note that this is not the default in
>> the openssl ca program.
> There’s no such requirement. It MUST be at most 20 octets long.
>> - Serial numbers contain cryptographically strong random bits, currently at
>> least 64 random bits, though it is best if the entire serial number looks
>> random from the outside.  This is not implemented by the openssl ca program.
> It can be easily done by an external script. Generate a secret key for your CA for a 128bits block cipher, keep the monotonic counter, but instead of putting the value of the counter in the serial number, encrypt the counter with the key+cipher, and use the resulting cipher text as the serial number. Of course, increment the counter.
>> - Certificates are valid for at most 2 years (actually 825 days).
>> - SHA-1 (and other weak algorithms such as MD5) are no longer permitted and
>> is already disappearing from Browser code.
>> - RSA shorter than 2048 bits (and other weak settings such as equally short
>> DSA keys) are no longer permitted and is already disappearing from Browser
>> code.
>> - If the certificate is issued to an e-mail address, that e-mail address must
>> also be listed as an rfc822Name in a "Subject Alternative Name" certificate
>> extension.
>> - End user certificates must be issued from an Intermediary CA whose
>> certificate is is in turn issued from a longer term root CA.
> I doubt browsers impose this on purely private CAs.

But it is easy to do, and it allows you to store your root CA totally 
offline.  Like on a mSD in a firebox (I am writing this into my guide).  
It also gives you flexibility to add another leaf for other sorts of 

For an RSA guide see:


For a roughish ECDSA guide see my recent effort:

http://www.htt-consult.com/pki.html  # this will be evolving as I add 
more in (like looking into your seqNum recommendation).

>> - If revocation is implemented (it should be, just in case someone gets their
>> computer or other key storage hacked/stolen), it needs to support OCSP, but
>> should ideally do so without having the actual CA keys online (standard trick:
>> Issue 3-month non-revocable OCSP-signing certificates and provide the
>> corresponding private key to the server running the OCSP responder program).
>>   I would recommend to also implement traditional CRLs, since for smaller CAs
>> it is a better solution for browsers and servers that support it.
> Another requirement is that a TLS server certificate shall have its identity (FQDN) in the SAN extension. Use of the commonName attribute has been deprecated long ago.

Where is this documented?



More information about the openssl-users mailing list