Re: [openssl-users] Personal CA: are cert serial numbers critical?
Tom Browder wrote: > I plan to tidy my automation before the issue of new certs, but I wonder > how critical it is to ensure unique certificate serial numbers given that > the certs are only used for us. I'm not even sure I'll ever revoke any > cert (they were issued to expire sometime in 2030). > > So, in summary, do I need to ensure cert serial numbers are unique for my > CA? Yes, serial numbers should be unique per issuer-DN because the 2-tuple (issuer-DN, cert serial no.) is expected to be unique in several protocols. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
➢ 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? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Personal CA: are cert serial numbers critical?
Many years ago I started a CA for one group I manage for a private website, and now I want to update members' client certs for the stricter requirements for browsers. My original cert generation was entirely automated including the following: + CN for each is an e-mail address for the member + the passphrase for each member's cert is determined from a pre-generated list by me, it will not change I plan to tidy my automation before the issue of new certs, but I wonder how critical it is to ensure unique certificate serial numbers given that the certs are only used for us. I'm not even sure I'll ever revoke any cert (they were issued to expire sometime in 2030). So, in summary, do I need to ensure cert serial numbers are unique for my CA? With warmest regards, -Tom -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users < openssl-users@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. Best regards, -Tom -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
On Wed, Aug 16, 2017 at 08:32 Michael Ströderwrote: > Tom Browder wrote: ... > > So, in summary, do I need to ensure cert serial numbers are unique for my > > CA? > > Yes, serial numbers should be unique per issuer-DN because the 2-tuple > (issuer-DN, cert serial no.) is expected to be unique in several protocols. Okay, that's good enough reason for me, Thanks, Michael. Cheers! -Tom -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
On 16/08/2017 16:32, Tom Browder wrote: On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users> 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. - 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. - 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. - 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. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
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 >>> 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: gr...@sloop.net http://www.sloop.net - openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
Certificate serial numbers must be unique. They need not be sequential or increasing. (Mozilla's NSS will complain and refuse to work if there are duplicate serial numbers.) I tend not to re-use keys, so I've found that putting 20 bytes (while clearing the high bit) of a digest of the SubjectPublicKeyInfo as the serial number works in that circumstance. [if you leave the high bit set, then DER mandates that it be encoded with a leading 0x00 byte, which makes it 21 bytes... which can cause problems with things built for PKIX.] -Kyle H On Wed, Aug 16, 2017 at 6:24 AM, Tom Browderwrote: > Many years ago I started a CA for one group I manage for a private > website, and now I want to update members' client certs for the stricter > requirements for browsers. > > My original cert generation was entirely automated including the following: > > + CN for each is an e-mail address for the member > > + the passphrase for each member's cert is determined from a pre-generated > list by me, it will not change > > I plan to tidy my automation before the issue of new certs, but I wonder > how critical it is to ensure unique certificate serial numbers given that > the certs are only used for us. I'm not even sure I'll ever revoke any > cert (they were issued to expire sometime in 2030). > > So, in summary, do I need to ensure cert serial numbers are unique for my > CA? > > With warmest regards, > > -Tom > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Implementing deprecation of commonname and emailaddress
I have skimmed through a few RFCs following today's postings and a few web sites. It would seem to me that I should: Remove commonName and emailAddress completely from the cnf file. They no longer belong in any cert, root or intermediate CA certs, server or user certs. For servers include something like in the cnf file: subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost, EMAIL:postmas...@example.com (That is all suppose to be on a single line in case your mail viewer wraps it). Um, I can specify 'localhost' in this manner if I am on the server and connecting in the browser with https://localhost ?? And for clients: subjectAltName = EMAIL:u...@example.com I am looking at how to build the above line using ENV variables. It is more a matter of how I do it than can I do it... thanks for any advice Bob -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Implementing deprecation of commonname and emailaddress
On Thu, Aug 17, 2017 at 12:28 AM, Robert Moskowitzwrote: > I have skimmed through a few RFCs following today's postings and a few web > sites. It would seem to me that I should: > > Remove commonName and emailAddress completely from the cnf file. They no > longer belong in any cert, root or intermediate CA certs, server or user > certs. CommonName is supplied for viewing by tools like certificate viewers. It should probably be a friendly name, like "Example Web Services". Don't include hostnames in the CN. If you list it in the CN, then it must be listed in the SAN, too. You must list it twice. When you see a name like "example.com" in the CN, its usually a CA including a domain name and not a hostname. It confusing for users and user agents. I've seen user agents match a hostname based on the domain name. On the backend, there's usually a redirect for the domain example.com to send user agents to a host like www.example.com. It happens up at layer 7, not at layer 4. > For servers include something like in the cnf file: > > subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost, > EMAIL:postmas...@example.com Don't include an email address. X.509 and PKIX certificates don't really have a proper field for email addresses. That's why they get mashed into CommonName. > (That is all suppose to be on a single line in case your mail viewer wraps > it). > > Um, I can specify 'localhost' in this manner if I am on the server and > connecting in the browser with https://localhost ?? Yes. You can also put IP addresses there. The RFC's mostly allow it. The CA/Browser Forum Baseline Requirements (CA/B BR) forbids it, but its not clear (to me) what current browser behavior is. For completeness, non-browser user agents, like wget and openssl, follow the RFC standards and issuing policies. Browsers follow the CA/B BR. That's why you often see browsers reject something accepted by other user agents. You might also be interested in https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898 and https://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl. They questions and answers reference about 6 different standards. > And for clients: > > subjectAltName = EMAIL:u...@example.com > > I am looking at how to build the above line using ENV variables. It is more > a matter of how I do it than can I do it... This is a whole 'nother can of worms. Also see https://security.stackexchange.com/questions/62746/how-to-encode-a-username-in-pkix-certificate. Jeff -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
On 08/16/2017 05:01 PM, Salz, Rich via openssl-users wrote: 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. Edit apps/apps.h to change SERIAL_RAND_BITS and use the –create_serial flag. I’ll be making a patch to do this more easily for master. Use of the commonName attribute has been deprecated long ago. > Where is this documented? RFC 2818 in 2000. See aslo https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/IGT2fLJrAeo OK. NOW I remember those debates in the PKIX sessions... Boy is THIS rattling some old brain cells! -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
On 08/16/2017 01:12 PM, Viktor Dukhovni wrote: On Aug 16, 2017, at 12:52 PM, Robert Moskowitzwrote: Which is also a problem in openssl. You have to put the SAN into the cnf file. There are a number of hacks to do this from the command line. Yep. For an approach that uses "bash" in-line files see: https://github.com/openssl/openssl/blob/master/test/certs/mkcert.sh#L95 I prefer something like this: openssl req -new -sha256 -key domain.key -subj "/C=US/ST=CA/O=Acme, Inc./CN=example.com"\ -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com"))\ -out domain.csr Bob -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
Bonjour, > Le 16 août 2017 à 16:51, Jakob Bohma écrit : > > On 16/08/2017 16:32, Tom Browder wrote: >> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users >> > 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
Re: [openssl-users] Personal CA: are cert serial numbers critical?
On 08/16/2017 10:51 AM, Jakob Bohm wrote: On 16/08/2017 16:32, Tom Browder wrote: On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users> 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. - 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. - 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. How universal is ECDSA p-256 support? - 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. Which is also a problem in openssl. You have to put the SAN into the cnf file. There are a number of hacks to do this from the command line. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
> On Aug 16, 2017, at 12:52 PM, Robert Moskowitzwrote: > > Which is also a problem in openssl. You have to put the SAN into the cnf > file. There are a number of hacks to do this from the command line. Yep. For an approach that uses "bash" in-line files see: https://github.com/openssl/openssl/blob/master/test/certs/mkcert.sh#L95 -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
On 16/08/2017 19:54, Robert Moskowitz wrote: On 08/16/2017 01:12 PM, Viktor Dukhovni wrote: On Aug 16, 2017, at 12:52 PM, Robert Moskowitzwrote: Which is also a problem in openssl. You have to put the SAN into the cnf file. There are a number of hacks to do this from the command line. Yep. For an approach that uses "bash" in-line files see: https://github.com/openssl/openssl/blob/master/test/certs/mkcert.sh#L95 I prefer something like this: openssl req -new -sha256 -key domain.key -subj "/C=US/ST=CA/O=Acme, Inc./CN=example.com"\ -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com"))\ -out domain.csr Another option is to use a config file that includes environment variables in the relevant fields. So it becomes something like export FOREMAIL=m...@example.com export FORUSER="Moe Madman" export CERTFN=moe openssl req -config /etc/cacfg/ca2017-mail.conf -newkey rsa:3072 -keyout ${CERTFN}.key -out ${CERTFN}.csr Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
> 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. Edit apps/apps.h to change SERIAL_RAND_BITS and use the –create_serial flag. I’ll be making a patch to do this more easily for master. >Use of the commonName attribute has been deprecated long ago. > Where is this documented? RFC 2818 in 2000. See aslo https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/IGT2fLJrAeo -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
On 08/16/2017 11:58 AM, Erwann Abalea via openssl-users wrote: Bonjour, Le 16 août 2017 à 16:51, Jakob Bohma écrit : On 16/08/2017 16:32, Tom Browder wrote: On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users > 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
Re: [openssl-users] Personal CA: are cert serial numbers critical?
On 08/16/2017 05:01 PM, Salz, Rich via openssl-users wrote: 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. Edit apps/apps.h to change SERIAL_RAND_BITS and use the –create_serial flag. I’ll be making a patch to do this more easily for master. So we will have to wait for the next release or build our own... Will there be some option to control the behavior? Use of the commonName attribute has been deprecated long ago. > Where is this documented? RFC 2818 in 2000. See aslo https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/IGT2fLJrAeo No wonder I missed it. My attention was off PKIX then as I was focused on HIP... Bob -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
On 16-08-17 15:24, Tom Browder wrote: [...] > I plan to tidy my automation before the issue of new certs, but I wonder > how critical it is to ensure unique certificate serial numbers given > that the certs are only used for us. I'm not even sure I'll ever revoke > any cert (they were issued to expire sometime in 2030). You should revoke certificates when their private keys are compromised; e.g., when the machine on which they were stored is stolen, lost, or broken into by a remote attacker based on password guessing, user error, social engineering, or something of the sorts. You aren't sure that any of that will happen now, but usually people who are compromised never expected that. Don't assume that just because they are password-protected that they are safe; passwords will delay the attacker, but not stop them. To accomodate for that, you should generate the CRLs for your certificates now, even if they're empty, and make sure that the software you've configured to use your private CA are set up check the CRLs. That way, when you become aware of a compromised private key of one of the certificates, you don't need to hurry to reconfigure all those services, but can simply revoke the certificate and possibly force critical applications to reread the CRL (e.g., by restarting the service), thereby turning a possibly full-day panicked "help I was compromised" into a five-minute "certificate revoked, done" session. > So, in summary, do I need to ensure cert serial numbers are unique for > my CA? Since CRLs expect that your serial numbers are unique, yes, you do need to ensure that. -- Wouter Verhelst -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
>> 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 ? Might be of interest : https://stackoverflow.com/questions/5935369/ssl-how-do-common-names-cn-and-subject-alternative-names-san-work-together -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Personal CA: are cert serial numbers critical?
>So we will have to wait for the next release or build our own... Yes, as always. Features go into the next release; fixes into existing ones. >Will there be some option to control the behavior? Yes, like –rand_serial or some such in the ca and x509 commands. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users