Bug 32652

Summary: mod_ssl: match hostnames against subjectAltName DNS names too
Product: Apache httpd-2 Reporter: Edgar Holleis <nospam>
Component: mod_sslAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: RESOLVED FIXED    
Severity: enhancement CC: k.rennecke, mastamind, steve, yehuda+apache
Priority: P2 Keywords: FixedInTrunk
Version: 2.2-HEAD   
Target Milestone: ---   
Hardware: All   
OS: All   
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.
Comment 11 Kaspar Brand 2012-02-28 17:48:57 UTC
Memleak fix backported to 2.4 in r1294602 - will appear in 2.4.2