2009-03-26
Apache SSL oddity
If you ever have the problem described below, you have to realize that Apache HTTPD is selecting the SSL certificate (and/or key) not based on you VirtualHost definition, but based on the ServerName in the current context. This means that you have two virtual hosts with the same ServerName, but on two different IPs, and are wondering why the wrong key (and/or certificate) is used, it might be because of this. Assume we have the following (simplified) configuration:
<VirtualHost a.b.c.d:443>
ServerName a.b.c.d
SSLCertificateFile /etc/ssl/certs/a.b.c.d_443.pem
SSLCertificateKeyFile /etc/ssl/certs/a.b.c.d_443-key.pem
</VirtualHost>
<VirtualHost a.b.c.d:444>
ServerName a.b.c.d
SSLCertificateFile /etc/ssl/certs/a.b.c.d_444.pem
SSLCertificateKeyFile /etc/ssl/certs/a.b.c.d_444-key.pem
</VirtualHost>
(note: This happened to me when wanting to open a SSL server for subversion on a host that also had Apache run as a reverse/application proxy for some specific application that managed its own CA)
Both VirtualHosts will use the very same certificate and key (as far as I was able to tell, but at least the same key), in my case that of the specific application (which was(is?), in its way, broken regarding SSL).
This might as well be a bug or a design decision (AKA feature), I don’t know. However the “workaround” that worked for us was to change one of the server names to something else (since it seems it is unused anyway, unless the apache decides to generate a self-refering URL, which it certainly won’t do for the reverse/application proxy part).
Update: Fixed formatting on configuration sample to make it clear this is not about namebased virtual hosts.
See also IP addresses
See also Unifying config file syntaxes with nesting
Permalink
goundoulf said,
March 26, 2009 at 16:34 UTC (+0000)
This is normal, for this to work you have to use IP-based virtual hosting instead.
With name-based virtual hosting, Apache has no way to know which certificate to use, as the SSL transaction starts before Apache gets to know the virtual host name.
sven said,
March 26, 2009 at 18:33 UTC (+0000)
Well, I admit that I didn’t check my post for formatting before posting it, so the “VirtualHost” statements were missing, but the fact that I talked about the “same ServerName” was a giveaway in my opinion:
I was talking about port based virtual hosts (which work in principal, see my workaround) that share the same hostname (but use different ports), as opposed to name-based virtual hosts which share the same IP and port, but differ in ServerName (well, the VirtualHost section should also have the ServerName in it).
I’m quite well understanding that SSL happens before Apache sees any data from the client (apart from IP address and portnumber) that identifies the server it wants to speak to. So the only way to do shared IP/port name-based virtual servers is to also share the SSL certificate/key pair (which will either have to be a wildcard certificate or a certificate listing all used server names in the SubjectAltNames x509 property).
But, as said, this was not what we needed. We needed to have the same IP, but different ports (which makes it possible to use different SSL key/certificate pairs, just like it makes it possible to use completely different applications). And on those different ports, we needed different key/certificate pairs, which is, as said, quite possible. But in Apache, you not only need different (non-overlapping) VirtualHost sections (each specifying their own SSLCertificateFile/SSLCertificateKeyFile), but these sections also needed to use different ServerName statements.
Michael Croes said,
March 26, 2009 at 18:42 UTC (+0000)
Name-based virtual hosting *is* possible with apache (and ssl of course), but it’s somewhat harder to configure and it seems people don’t want you to know that it’s possible. I happen to use cherokee, which will happily do name-based ssl virtual hosts. There’s just one little issue, and that is that the client needs to support it (it needs to send the hostname in the ssl initiation or something), and some older versions of IE are not really good at this (of course). I can only suggest that you look for the solution yourself.
Regards,
Michael
sven said,
March 26, 2009 at 22:27 UTC (+0000)
Yes, there is the option to pass the intended server name in the SSL handshake, and some browsers support it (or are at least supposed to support that). However, this is not the issue at hand here, which is that Apache stores the SSL certificate and key based on ServerName and not – as one might think – based on what is in the <VirtualHost> stanza.
goundoulf@gmail.com said,
March 26, 2009 at 22:36 UTC (+0000)
Well yes it is supported by Apache and it is called Server Name Indication (http://en.wikipedia.org/wiki/Server_Name_Indication), but the problem is that the client has to be at least IE 7 (and Vista, not XP), or Firefox > 2.0, or Opera > 8.0 or Google Chrome or Safari 3.2.1…
And a lot of visitors still use IE 7 and XP, or IE < 7…
pietro said,
March 28, 2009 at 10:03 UTC (+0000)
I wrote about sni a while ago :
https://mancoosi.org/~abate/namebased-virtual-hosting-with-ssl
but it still doesn’t work properly with many browsers…
sven said,
March 28, 2009 at 12:24 UTC (+0000)
Was I really this misunderstandable? I was neither talking about name-based virtual hosts (mine are purely IP/port based) nor about SSL server name indication!
I will not approve any more comments which talk about those unless they show how they are related to my problem (IP/port based virtual hosts with the same ServerName).
hynek said,
October 6, 2010 at 10:11 UTC (+0000)
Thank you sven. I was struggling with that for alost a day, until I found you article.
I’ve got server in DMZ, which is pure HTTPS and has the different domain names to Internet and to internal network, meaning two different certs also.
Appreciate it very much, now working for me correctly.
Thanks, Hynek