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@xxxxxxxxxx> 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@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>> 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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
