Quantcast

RFC2818 and subjectAltName

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RFC2818 and subjectAltName

Murray, Ronald-1 (ANF)

We had an issue a few days ago when people with the newest version of Chrome were seeing security errors on our internal sites which were using SSL certificates signed with our internal CA. This turned out to be caused by Google adhering to RFC2818, which says:

 

If a subjectAltName extension of type dNSName is present, that MUST

be used as the identity. Otherwise, the (most specific) Common Name

field in the Subject field of the certificate MUST be used. Although

the use of the Common Name is existing practice, it is deprecated and

Certification Authorities are encouraged to use the dNSName instead.

 

Our certificates, of course, only contained the Common Name (CN), with no subjectAltName (SAN). I solved the problem by creating new certificates and hacking openssl.cnf to request a SAN in the CSR.

 

Now, our CA isn’t openssl-based (it’s Microsoft), but it’s occurred to me that openssl-created certificates should really include the site ID in a SAN as well as in the CN. RFC2818 has been out since May, 2000, so I’m rather surprised that this hasn’t been widely implemented before now. I note that certificates we get from Symantec have lately included a SAN, but I think that’s quite recent.

 

Is there any chance of this being included in openssl?

 

 


This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this mail in error please notify the postmaster at dor.state.ma.us.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC2818 and subjectAltName

Viktor Dukhovni

> On Apr 26, 2017, at 11:55 AM, Murray, Ronald-1 (ANF) <[hidden email]> wrote:
>
> Our certificates, of course, only contained the Common Name (CN), with no subjectAltName (SAN). I solved the problem by creating new certificates and hacking openssl.cnf to request a SAN in the CSR.

An appropriate openssl.cnf is the supported way to populate DNS altnames
into certificates created with the req(1), x509(1) and ca(1) utilities.

> Is there any chance of this being included in openssl?

It is already included, via the openssl.cnf interface.  You can
also create openssl.cnf sections on the fly, without creating
any persistent files, with "bash" or similar shells.  See, for
example:

   https://github.com/openssl/openssl/blob/master/test/certs/mkcert.sh

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC2818 and subjectAltName

Ryan Murray

If you are asking me, by all means yes. Thanks for asking, I respect the value of honesty in world that has so very few people left.

 

Sent from Mail for Windows 10

 

From: [hidden email]
Sent: Wednesday, April 26, 2017 1:55 PM
To: [hidden email]
Subject: Re: [openssl-users] RFC2818 and subjectAltName

 

 

> On Apr 26, 2017, at 11:55 AM, Murray, Ronald-1 (ANF) <[hidden email]> wrote:

>

> Our certificates, of course, only contained the Common Name (CN), with no subjectAltName (SAN). I solved the problem by creating new certificates and hacking openssl.cnf to request a SAN in the CSR.

 

An appropriate openssl.cnf is the supported way to populate DNS altnames

into certificates created with the req(1), x509(1) and ca(1) utilities.

 

> Is there any chance of this being included in openssl?

 

It is already included, via the openssl.cnf interface.  You can

also create openssl.cnf sections on the fly, without creating

any persistent files, with "bash" or similar shells.  See, for

example:

 

   https://github.com/openssl/openssl/blob/master/test/certs/mkcert.sh

 

--

                Viktor.

--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC2818 and subjectAltName

Ryan Murray
In reply to this post by Murray, Ronald-1 (ANF)

yes

 

Sent from Mail for Windows 10

 

From: [hidden email]
Sent: Wednesday, April 26, 2017 1:25 PM
To: [hidden email]
Subject: [openssl-users] RFC2818 and subjectAltName

 

We had an issue a few days ago when people with the newest version of Chrome were seeing security errors on our internal sites which were using SSL certificates signed with our internal CA. This turned out to be caused by Google adhering to RFC2818, which says:

 

If a subjectAltName extension of type dNSName is present, that MUST

be used as the identity. Otherwise, the (most specific) Common Name

field in the Subject field of the certificate MUST be used. Although

the use of the Common Name is existing practice, it is deprecated and

Certification Authorities are encouraged to use the dNSName instead.

 

Our certificates, of course, only contained the Common Name (CN), with no subjectAltName (SAN). I solved the problem by creating new certificates and hacking openssl.cnf to request a SAN in the CSR.

 

Now, our CA isn’t openssl-based (it’s Microsoft), but it’s occurred to me that openssl-created certificates should really include the site ID in a SAN as well as in the CN. RFC2818 has been out since May, 2000, so I’m rather surprised that this hasn’t been widely implemented before now. I note that certificates we get from Symantec have lately included a SAN, but I think that’s quite recent.

 

Is there any chance of this being included in openssl?

 

 

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this mail in error please notify the postmaster at dor.state.ma.us.

 


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Loading...