I set up an ubuntu 9.10 - apache2 - php5 server. I was under the impression that each valid SSL certificate (no domain wild cards) required it's own unique IP address and port number combination. But the answer to a previous question I posted is at odds with this claim:

http://serverfault.com/questions/109766/ssl-site-not-using-the-correct-ip-in-apache-and-ubuntu

Using the accepted answer, I was able to get multiple domains, each with it's own valid SSL to work on the same IP address and on port 443.

I am very confused as to why the above answer works, especially after hearing from others that each SSL domain website on the same server requires its own IP+port combination.

I am suspicious that I did something wrong. Can someone clear up the confusion?

Websites currently using different SSL but on the same IP and Port are: https://www.yummyskin.com/ https://staging.bossystem.org/

link|improve this question

If you would like to post the links to these sites, I can verify if they are or are not set up correctly by opening them up in IE. If you don't get a cert error then you've set it up correctly. I've moved my certs between many different servers and IP addresses and never had to recreate them as long as I used the domain name (or wildcard) associated with the cert. – Patrick R Feb 4 '10 at 23:02
ok, they are yummyskin.com and staging.bossystem.org – John Feb 4 '10 at 23:07
1  
OK. How did you do that? Those two sites are on the same IP and use different certs! – Josh Feb 4 '10 at 23:28
doh, you're right.....ok, so i didn't actually solve the problem in my initial question – John Feb 4 '10 at 23:33
But I am still confused. I thought SSL required a unique IP for each cert... How are you using two different certs on a single IP? – Josh Feb 4 '10 at 23:43
show 1 more comment
feedback

3 Answers

up vote 27 down vote accepted

For the most up-to-date information on Apache and SNI, including additional HTTP-Specific RFCs, please refer to the Apache wiki:http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI


FYsI: "Multiple (different) SSL certificates on one IP" is brought to you by the magic of TLS Upgrading. It works with newer Apache servers (2.2.x) and reasonably recent browsers (don't know versions off the top of my head).

RFC 2817 (upgrading to TLS within HTTP/1.1) has the gory details, but basically it works for a lot of people (if not the majority).
You can reproduce the old funky behavior with openssl's s_client command (or any "old enough" browser) though.

Edit to add: apparently curl can show you what's happening here better than openssl:


SSLv3

mikeg@flexo% curl -v -v -v -3 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* 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=wq8O9mhOSp9fY9JcmaJUrFNWWrANURzJ; C=CA; 
              O=staging.bossystem.org; OU=GT07932874;
              OU=See www.rapidssl.com/resources/cps (c)10;
              OU=Domain Control Validated - RapidSSL(R);
              CN=staging.bossystem.org
*    start date: 2010-02-03 18:53:53 GMT
*    expire date: 2011-02-06 13:21:08 GMT
* SSL: certificate subject name 'staging.bossystem.org'
       does not match target host name 'www.yummyskin.com'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'staging.bossystem.org'
does not match target host name 'www.yummyskin.com'

TLSv1

mikeg@flexo% curl -v -v -v -1 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* 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: C=CA; O=www.yummyskin.com; OU=GT13670640;
              OU=See www.rapidssl.com/resources/cps (c)09;
              OU=Domain Control Validated - RapidSSL(R);
              CN=www.yummyskin.com
*    start date: 2009-04-24 15:48:15 GMT
*    expire date: 2010-04-25 15:48:15 GMT
*    common name: www.yummyskin.com (matched)
*    issuer: C=US; O=Equifax Secure Inc.; CN=Equifax Secure Global eBusiness CA-1
*    SSL certificate verify ok.
link|improve this answer
That's very useful -- Thanks! Any info on how to configure Apache for TLS instead of SSL? – Josh Feb 4 '10 at 23:56
2  
I think that Apache 2.2 just needs to have the TLS bits enabled in its cypher list. I'll admit I've never see the whole "Upgrading from SSL to TLS" bit in action until these two sites though. My understanding of the TLS docs is that it's an allowable (but unusual) situation to negotiate this kind of upgrade... – voretaq7 Feb 5 '10 at 0:01
This is the first time I've ever seen it either and I'm still trying to pull my jaw off the floor... – Josh Feb 5 '10 at 0:04
1  
OK my answer just tripled in length - Apparently curl can do both SSLv3 and TLSv1 negotiations so I can show the failure & the success. I wish I had a protocol debugger handy to show the magic part though. (Also tested and happy to report that johnlai2004's server correctly denies SSLv2 connections :-) – voretaq7 Feb 5 '10 at 0:18
That is extremely helpful and I hope johnlai2004 accepts your answer. Thanks a lot! – Josh Feb 5 '10 at 0:52
show 7 more comments
feedback

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

The client browser must also support SNI. Here are some browsers that do:

* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (with TLS 1.1 enabled)
* Internet Explorer 7.0 or later (on Vista, not XP)
* Google Chrome
* Safari 3.2.1 on Mac OS X 10.5.6 
link|improve this answer
feedback

Not an expert in apache but I would lean toward using host headers: redirection based on url request.

link|improve this answer
There's no redirection happening here. See voretaq7's answer, that seems to be the correct answer. – Josh Feb 5 '10 at 0:05
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.