|Summary:||mod_ssl: match hostnames against subjectAltName DNS names too|
|Product:||Apache httpd-2||Reporter:||Edgar Holleis <nospam>|
|Component:||mod_ssl||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
|Severity:||enhancement||CC:||k.rennecke, mastamind, steve, yehuda+apache|
|Attachments:||Example code checking subjectAltName|
Description Edgar Holleis 2004-12-12 00:28:13 UTC
Contrary to popular believe and contrary to the apache documentation, it is currently possible to use name virual hosting over ssl as long as all virtual hosts share the same ssl-setup (server-certificate, client-certificates, etc). Using the subjectAltName extension of x509 v3 it is possible for this one server-certificate to be valid for all ssl-virtual hosts. subjectAltName is supported at least by current Mozilla browsers and Internet Explorer versions. Look at http://www.es.net/pub/esnet-doc/SubjectAltName.pdf (found via Google) for more details. The setup works perfectly with Apache 2.0.52 (Debian Package), even though apache complains once per virtual host about the CN of the certificate not matching ServerName. Please change the documentation or at least include a hint that subjectAltName exists, it could be very usefull for small sites. It could also stimulate browser support for subjectAltName if it became widly known. ------------------------------------------------------------------------------ httpd.conf (only relevent parts) NameVirtualHost *:80 <VirtualHost *:80> # Default <VirtualHost> <VirtualHost *:80> ServerName asdf.com </VirtualHost> SSLCipherSuite CipherSpec:foo SSLCertificateFile /path/to/CertificateFile SSLCertificateKeyFile /path/to/KeyFile # all the other common SSL options NameVirtualHost *:443 <VirtualHost *:443> # Default SSLEngine on <VirtualHost> <VirtualHost *:443> ServerName asdf.com SSLEngine on </VirtualHost>
Comment 1 Joe Orton 2005-01-13 14:11:21 UTC
It would be nice if mod_ssl checked the subjectAltName extension and didn't warn about CN mismatches if there is a mataching subjectAltName for the server host, yes. Your assertion that "it's possible to do name-based vhosting with SSL so long as all your vhosts share the same configuration" really belies the meaning of "name-based vhosting", i.e. being able to have multiple server configurations one of which is chosen based on the hostname used in the Host header.
Comment 2 Dr Stephen Henson 2007-12-04 06:13:34 UTC
I've attached a patch which checks subjectAltName and also multiple commonName types if subjectAltName is not present. It can also handle alternative string types in commonName. Logging errors isn't quite as straight forward because several names could be matched. I've set this to initially check a match, then if and only if it fails log all the mismatches. If nothing else the patch should give a few pointers.
Comment 3 Dr Stephen Henson 2007-12-04 06:15:02 UTC
Created attachment 21226 [details] Example code checking subjectAltName
Comment 4 Mike Cardwell 2010-12-21 08:52:52 UTC
This is still happening, 6 years since the bug was found, 3 years since a patch was supplied. :(
Comment 5 Kaspar Brand 2011-09-28 06:54:13 UTC
I have committed a fix for trunk in r1176752, which takes the dNSName entries in the subjectAltName extension into account when checking against the ServerName. Wildcard matching is performed as well, but only in a restrictive fashion: the wildcard character must be THE left-most DNS label, and it is not allowed to match a dot (this basically reflects what common browsers do nowadays).
Comment 6 Kaspar Brand 2011-09-28 06:57:20 UTC
*** Bug 47051 has been marked as a duplicate of this bug. ***
Comment 7 Kaspar Brand 2011-09-28 07:01:54 UTC
(In reply to comment #5) > I have committed a fix for trunk in r1176752, which takes the dNSName entries r1176752 - hopefully Bugzilla properly hyperlinks it this time.
Comment 8 Stefan Fritsch 2012-02-26 16:35:44 UTC
fixed in 2.4.1
Comment 9 Dr Stephen Henson 2012-02-26 17:19:40 UTC
Minor issue with this fix. You need to call: sk_GENERAL_NAME_pop_free(names, GENERAL_NAME_free); and not just sk_GENERAL_NAME_free or you leak memory.
Comment 10 Kaspar Brand 2012-02-28 06:03:31 UTC
(In reply to comment #9) > Minor issue with this fix. You need to call: Thanks for pointing this out. Fixed for trunk in r1294471 - backport for 2.4 proposed.