3

I'm running a website where the checkout flow is SSL certified using a Comodo EV certificate.

We also have Piwik web analytics tracking across the site, which is served off a stats subdomain. To prevent mixed domain errors, the Piwik is accessible via HTTPS as well as HTTP - for HTTPS, our Piwik subdomain is certified using a (much cheaper) Comodo PositiveSSL certificate.

Here's the weird part - when an HTTPS page on the main site is accessed through wget and some versions of Internet Explorer, the stats.psychicbazaar.com certificate seems to somehow get loaded by mistake, leading to "Mismatched Address" warnings in IE, and in wget:

ERROR: certificate common name `stats.psychicbazaar.com' doesn't match requested host name `www.psychicbazaar.com'.

This problem does not occur with curl, Chrome or Firefox. For example, with curl:

$ curl -Iv https://www.psychicbazaar.com/shop/checkout

* <snip>
* Connected to www.psychicbazaar.com (178.79.183.162) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: serialNumber=07440589; 1.3.6.1.4.1.311.60.2.1.3=GB; 1.3.6.1.4.1.311.60.2.1.
2=Greater London; businessCategory=Private Organization; C=GB; postalCode=EC24 4RQ; ST=Greater 
London; L=London; street=The Roma Building 32-38; O=Psychic Bazaar Ltd; OU=COMODO EV 
*    start date: 2012-02-16 00:00:00 GMT
*    expire date: 2013-02-15 23:59:59 GMT
*    subjectAltName: www.psychicbazaar.com matched
*    issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO Extended Validation Secure Server CA
*    SSL certificate verify ok.
> HEAD /shop/checkout HTTP/1.1
> User-Agent: curl/7.21.6 (x86_64-pc-linux-gnu) libcurl/7.21.6 OpenSSL/1.0.0e zlib/1.2.3.4 libidn/1.22 librtmp/2.3
> Host: www.psychicbazaar.com
> Accept: */*
> 
< <snip>

What could be going on here - why would a browser be reading and erroring on a subdomain's SSL certificate when it's loading a page on the main domain? Any help much appreciated!

Alex Dean
  • 143
  • 6

1 Answers1

3
# dig stats.psychicbazaar.com
[...]
;; ANSWER SECTION:
stats.psychicbazaar.com. 3600   IN      A       178.79.183.162
[...]
# dig www.psychicbazaar.com
[...]
;; ANSWER SECTION:
www.psychicbazaar.com.  3600    IN      A       178.79.183.162
[...]

How exactly is your web server supposed to know which certificate to serve for a TLS exchange if you are using the same IP address for both? This won't work:

http://wiki.apache.org/httpd/NameBasedSSLVHosts

As a rule, it is impossible to host more than one SSL virtual host on the same IP address and port. This is because Apache needs to know the name of the host in order to choose the correct certificate to setup the encryption layer. But the name of the host being requested is contained only in the HTTP request headers, which are part of the encrypted content. It is therefore not available until after the encryption is already negotiated.

the-wabbit
  • 40,319
  • 13
  • 105
  • 169
  • Huge thanks for this answer syneticon-dj - I am moving Piwik onto a separate IP now. But I don't fully understand the symptom and the cause: if Nginx cannot know which cert to serve when two certs are sharing one IP and port, surely all clients would error on average 50% of the time? Why would some browsers always get the right cert, and some browsers always get the wrong cert? – Alex Dean Apr 05 '12 at 22:21
  • 2
    @AlexDean Because most (but not all) clients support Server Name Indication, which allows Apache to send them the cert that's configured on the virtual host that they're requesting - those clients will have no issue with your setup. Clients that don't support SNI will always be sent the certificate from the first vhost on the port in terms of load order. – Shane Madden Apr 06 '12 at 02:40
  • Many thanks for the explanation @ShaneMadden! There's a lot of good info about Nginx, HTTPS and SNI here: http://nginx.org/en/docs/http/configuring_https_servers.html – Alex Dean Apr 06 '12 at 10:18
  • @AlexDean Oh, sorry - the link in the answer to the Apache documentation was fresh in my mind when I wrote that comment, so I assumed that you were using Apache. – Shane Madden Apr 06 '12 at 14:57
  • you might be able to just get a cert with multiple SANs (subjectAltNames)... that way each client will get the cert they need (imagine a certificate valid for each of one.example.com, two.example.com and three.four.example.com rolled into one) – Ram Apr 06 '12 at 23:04