Weird Apache SSL certificate behaviour

Today, I encountered the following weirdness in Apache’s SSL certificate handling. I have two SSL virtual hosts on different IP addresses. The essentials:

<VirtualHost a.b.c.d:443>
    SSLCertificateFile /path/to/cert1
</VirtualHost>

<VirtualHost a.b.c.e:443>
    SSLCertificateFile /path/to/cert2
</VirtualHost>


This works as expected, as long as the ServerName for both virtual hosts is different. If the ServerNames are identical,

• either, you specify a ServerName with identical values in the virtual host definition
• or, and this is the tricky part, IP addresses a.b.c.d and a.b.c.e resolve to the same host name

Apache serves the certificate from /path/to/cert1 for both virtual hosts, and doesn’t use /path/to/cert2 at all.

Is this somehow documented behaviour or otherwise to be expected?

I understand that there is a close relationship between a virtual host’s name, the server certificate, which also contains the host name, and the name that the client uses to connect to the site, but of these three, the virtual host’s name matters the least of the three. It will cause a warning in Apache error log:

RSA server certificate CommonName (CN) `example.com' does NOT match server name!?

but that’s it. Clients still are able to verify the certificate, because the certificate name still matches the hostname in the request.

I think it should very well be possible to serve different certificates on different virtual hosts, even if they have the same name. The setup that caused me this trouble uses client certificate verification to authenticate and authorize clients to connect. We distinguish between ‘production’ clients and ‘development’ clients, which have different client certificates, signed by different CAs, and we have different server certificates to match. We use DNS views or even /etc/hosts to direct clients to the right server. I don’t see why this shouldn’t work, do you?