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

[Robert Moskowitz]

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 
devices/usages.

For an RSA guide see:

https://jamielinux.com/docs/openssl-certificate-authority/introduction.html

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?

thanks

Bob