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

[Gregory Sloop]

Replying personally:

I'm a nobody, and you have no reason to know me - but wanted to thank you for the input you give here.

You're nearly always quite thoughtful, careful in what you say, respectful, and give such [IMO] good insightful feedback and information to people looking for help. I follow quite a number of lists, and IMO, it's a rare breed of individuals who do such a fine job.

Perhaps you care nothing for such accolades, and I'm truly a "nobody" in giving them - but still I wanted to recognize excellence when I see it.

So, Thanks!

-Greg

JB> 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.

JB> Modern browsers increasingly presume that such private CAs behave exactly
JB> like the public CAs regulated through the CA/Browsers Forum (CAB/F) and
JB> the per-browser root CA inclusion programs (the administrative processes
JB> that determine which CAs are listed in browsers by default).

JB> Among the relevant requirements now needed:

JB> - Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as 
JB> standalone
JB>   numbers and as DER-encoded numbers.  Note that this is not the default in
JB>   the openssl ca program.

JB> - Serial numbers contain cryptographically strong random bits, currently at
JB>   least 64 random bits, though it is best if the entire serial number looks
JB>   random from the outside.  This is not implemented by the openssl ca 
JB> program.

JB> - Certificates are valid for at most 2 years (actually 825 days).

JB> - SHA-1 (and other weak algorithms such as MD5) are no longer permitted and
JB>   is already disappearing from Browser code.

JB> - RSA shorter than 2048 bits (and other weak settings such as equally short
JB>   DSA keys) are no longer permitted and is already disappearing from 
JB> Browser
JB>   code.

JB> - If the certificate is issued to an e-mail address, that e-mail address
JB> must
JB>   also be listed as an rfc822Name in a "Subject Alternative Name" 
JB> certificate
JB>   extension.

JB> - End user certificates must be issued from an Intermediary CA whose
JB>   certificate is is in turn issued from a longer term root CA.

JB> - If revocation is implemented (it should be, just in case someone gets
JB> their
JB>   computer or other key storage hacked/stolen), it needs to support 
JB> OCSP, but
JB>   should ideally do so without having the actual CA keys online 
JB> (standard trick:
JB>   Issue 3-month non-revocable OCSP-signing certificates and provide the
JB>   corresponding private key to the server running the OCSP responder 
JB> program).
JB>    I would recommend to also implement traditional CRLs, since for 
JB> smaller CAs
JB>   it is a better solution for browsers and servers that support it.


JB> Enjoy

JB> Jakob
JB> -- 
JB> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
JB> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
JB> This public discussion message is non-binding and may contain errors.
JB> WiseMo - Remote Service Management for PCs, Phones and Embedded


-- 
Gregory Sloop, Principal: Sloop Network & Computer Consulting
Voice: 503.251.0452 x82
EMail: gregs at sloop.net
http://www.sloop.net
---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170816/da61ac19/attachment-0001.html>