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. > - 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. Cordialement, Erwann Abalea -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
