Re: [openssl-users] Subject CN and SANs

2018-12-24 Thread Viktor Dukhovni
> On Dec 24, 2018, at 5:51 PM, Kyle Hamilton wrote: > If a certificate identifies an Issuer, then the certificate cannot contain an > empty sequence of RDNs in the Subject and still be conformant to PKIX. Yes, CA certificates need to have a non-empty subject name if they're to be used for

Re: [openssl-users] Subject CN and SANs

2018-12-24 Thread Kyle Hamilton
In order for an Issuer to exist in PKIX, it must be the Subject of another Certificate (or of a trust anchor). If a certificate identifies an Issuer, then the certificate cannot contain an empty sequence of RDNs in the Subject and still be conformant to PKIX. This is because the Subject of the

Re: [openssl-users] Subject CN and SANs

2018-12-24 Thread Felipe Gasper
I’m not sure, heh. ;-) -F > On Dec 24, 2018, at 3:17 AM, Walter H. wrote: > > and which CA does this as the forum guidelines say? > >> On 23.12.2018 22:50, Felipe Gasper wrote: >> Actually, per the latest CA/Browser forum guidelines, subject.CN is not only >> optional but “discouraged”. >>

Re: [openssl-users] Subject CN and SANs

2018-12-24 Thread chris . gray
A bit off-topic but is it also a good idea to follow these guidelines in non-browser use cases, for example for a client certificate which is used to autenticate on a TLS connection which will be used for another protocol such as MQTT? In this case the SubjectCN looks like a "natural" place to put

Re: [openssl-users] Subject CN and SANs

2018-12-24 Thread Walter H.
and which CA does this as the forum guidelines say? On 23.12.2018 22:50, Felipe Gasper wrote: Actually, per the latest CA/Browser forum guidelines, subject.CN is not only optional but “discouraged”. -FG smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list

Re: [openssl-users] Subject CN and SANs

2018-12-23 Thread Viktor Dukhovni
> On Dec 23, 2018, at 6:01 PM, Kyle Hamilton wrote: > > You're right, I typoed. SubjectDN is non-optional. But it can, as > you mentioned, be an empty sequence. > > But for PKIX purposes, it can't be empty if it's an Issuer (because > IssuerDN can't be empty in the certificates that it

Re: [openssl-users] Subject CN and SANs

2018-12-23 Thread Kyle Hamilton
You're right, I typoed. SubjectDN is non-optional. But it can, as you mentioned, be an empty sequence. But for PKIX purposes, it can't be empty if it's an Issuer (because IssuerDN can't be empty in the certificates that it issues). -Kyle H On Sun, Dec 23, 2018 at 3:35 PM Viktor Dukhovni

Re: [openssl-users] Subject CN and SANs

2018-12-23 Thread Felipe Gasper
Actually, per the latest CA/Browser forum guidelines, subject.CN is not only optional but “discouraged”. -FG > On Dec 23, 2018, at 4:29 PM, Kyle Hamilton wrote: > > SubjectCN is an operational requirement of X.509, I believe. It's not > optional in the data structure, at any rate. > > -Kyle

Re: [openssl-users] Subject CN and SANs

2018-12-23 Thread Viktor Dukhovni
> On Dec 23, 2018, at 4:29 PM, Kyle Hamilton wrote: > > SubjectCN is an operational requirement of X.509, I believe. You're confusing the DN and the CN. > It's not optional in the data structure, at any rate. The subjectDN is not optional, but it can be empty sequence, and is empty for

Re: [openssl-users] Subject CN and SANs

2018-12-23 Thread Kyle Hamilton
SubjectCN is an operational requirement of X.509, I believe. It's not optional in the data structure, at any rate. -Kyle H On Sun, Dec 23, 2018 at 9:22 AM Michael Richardson wrote: > > > Salz, Rich via openssl-users wrote: > > Putting the DNS name in the CN part of the subjectDN has been

Re: [openssl-users] Subject CN and SANs

2018-12-23 Thread Viktor Dukhovni
> On Dec 23, 2018, at 10:21 AM, Michael Richardson wrote: > > It seems that the "openssl ca" mechanism still seem to want a subjectDN > defined. Am I missing some mechanism that would let me omit all of that? Or > is a patch needed to kill what seems like a current operational requirement? It

Re: [openssl-users] Subject CN and SANs

2018-12-23 Thread Michael Richardson
Salz, Rich via openssl-users wrote: > Putting the DNS name in the CN part of the subjectDN has been > deprecated for a very long time (more than 10 years), although it > is still supported by many existing browsers. New certificates > should only use the subjectAltName extension.

Re: [openssl-users] Subject CN and SANs

2018-12-23 Thread Walter H.
I guess its a matter of which Linux you use, CentOS 7 doesn't give this warning; CentOS 6 warns about this; a Debian (don't really know which release) uname -a Linux a2f78 3.16.0-7-amd64 #1 SMP Debian 3.16.59-1 (2018-10-03) x86_64 GNU/Linux does warn ... Walter On 23.12.2018 13:21, Felipe

Re: [openssl-users] Subject CN and SANs

2018-12-23 Thread Felipe Gasper
Wow that’s pretty bad .. is that the current version of httpd?? That’d be worth a big report if so, IMO, though I’d imagine it’s an issue they’re aware of. -FG > On Dec 23, 2018, at 6:53 AM, Walter H. wrote: > > > I tried the following > > the certificate had a CN oftest.example.com

Re: [openssl-users] Subject CN and SANs

2018-12-23 Thread Walter H.
I tried the following the certificate had a CN oftest.example.com and in subjectAltNames dNS were test.example.com and test.example.net when the Apache ServerName is test.example.net I get this warning [Sun Dec 23 12:45:03 2018] [warn] RSA server certificate CommonName (CN)

Re: [openssl-users] Subject CN and SANs

2018-12-23 Thread Kyle Hamilton
Does Apache only examine CN=, or does it also check subjectAltNames dNS entries? -Kyle H On Sun, Dec 23, 2018 at 3:25 AM Walter H. wrote: > > On 23.12.2018 03:47, Salz, Rich via openssl-users wrote: > > > >. New certificates should only use the subjectAltName extension. > > > >> Are

Re: [openssl-users] Subject CN and SANs

2018-12-23 Thread Walter H.
On 23.12.2018 03:47, Salz, Rich via openssl-users wrote: > >. New certificates should only use the subjectAltName extension. Are any CAs actually doing that? I thought they all still included subject.CN. Yes, I think commercial CA's still do it. But that doesn't make my statement

Re: [openssl-users] Subject CN and SANs

2018-12-22 Thread Salz, Rich via openssl-users
> >. New certificates should only use the subjectAltName extension. >Are any CAs actually doing that? I thought they all still included > subject.CN. Yes, I think commercial CA's still do it. But that doesn't make my statement wrong :) -- openssl-users mailing list To

Re: [openssl-users] Subject CN and SANs

2018-12-22 Thread Felipe Gasper
> On Dec 22, 2018, at 9:12 PM, Salz, Rich via openssl-users > wrote: > > Putting the DNS name in the CN part of the subjectDN has been deprecated for > a very long time (more than 10 years), although it is still supported by many > existing browsers. New certificates should only use the

Re: [openssl-users] Subject CN and SANs

2018-12-22 Thread Salz, Rich via openssl-users
Putting the DNS name in the CN part of the subjectDN has been deprecated for a very long time (more than 10 years), although it is still supported by many existing browsers. New certificates should only use the subjectAltName extension. -- openssl-users mailing list To unsubscribe:

Re: [openssl-users] Subject CN and SANs

2018-12-22 Thread Felipe Gasper
It shouldn’t matter. Technically subject.CN is deprecated anyway, but all the CAs still create it. -FG > On Dec 22, 2018, at 4:29 PM, Walter H. wrote: > > Hello, > > I found several different certificates on the net > > some are like this: > > CN=example.com > SANs areDNS:example.com,

[openssl-users] Subject CN and SANs

2018-12-22 Thread Walter H.
Hello, I found several different certificates on the net some are like this: CN=example.com SANs areDNS:example.com, DNS:www.example.com and some are like this: CN=www.example.com SANs areDNS:example.com, DNS:www.example.com does this matter or is one them the preferred one?