Setup multiple SSL certificates on amazon VPC

Question

I've been banging my head against the wall trying to figure out how to setup multiple SSL certificates on an amazon VPC instance (I'm using amazon's standard linux AMI)

Here's what I did:

1. I setup a VPC instance
2. Added a secondary private IP address
3. Added 2 elastic IP addresses & "linked" them to the private ones
4. Went to my domain registrar & pointed two test domains to the elastic IP addresses
5. Waited until new IP addresses were propagated
6. I uploaded the SSL certificates to the VPC instance

Then I tried editing ssl.conf, see line 74 to 93 & httpd.conf, see line 1046 to 1086:

ssl.conf

<VirtualHost domain1.com:443>
    ServerName www.domain1.com:443
    DocumentRoot "/var/www/html"
    SSLENGINE on
    SSLCertificateFile /etc/ssl/domain1_com.crt
    SSLCertificateKeyFile /etc/ssl/domain1_com.key
    SSLCertificateChainFile /etc/ssl/domain1_com.ca-bundle
</VirtualHost>

<VirtualHost _default_:443>
    ...Default SSL certificate (domain1.com) here...
</VirtualHost>

httpd.conf

<VirtualHost *:80>
    ServerName domain1.com
    ServerAlias www.domain1.com
    DocumentRoot /var/www/html
    ServerAdmin [email protected]
</VirtualHost>

<VirtualHost *:80>
    ServerName domain2.com
    ServerAlias www.domain2.com
    DocumentRoot /var/www/html
    ServerAdmin [email protected]
</VirtualHost>

I also tried <VirtualHost *:443> and <VirtualHost IP.ADDRESS:443>, didn't work either.

The result is basically this:

1. domain1.com (which is the default SSL certificate) works just fine (resolve fine, green bar)
2. domain2.com: doesn't even resolve to anything, even though when I do ping www.domain2.com, I get the correct elastic IP

My question is: Any idea how to make domain2.com resolve & use the correct SSL certificate?

---

EDIT / Additional Info:

I also tried this:

1. Temporarily stopped firewall as suggested, ie. sudo service iptables stop
2. From outside of EC2, curl --connect-timeout 10 https://domain2.com gave me this curl: (28) connect() timed out!

wget https://www.domain2.com/ gave me this: --2013-10-03 15:57:22-- domain2.com Resolving www.domain2.com... 54.229.111.22 Connecting to www.domain2.com|54.229.111.22|:443... failed: Connection timed out. Retrying.

---

EDIT (2):

I noticed 2 things:

1. If I use 2 network interfaces (each NIC with one private IP) sudo ifconfig doesn't show the 2nd NIC (ie. eth1), and wether I use one or two NICs, sudo ifconfig always return the 1st private IP (10.0.0.10), never the 2nd one (10.0.0.183)

Unsurprisingly, the unreachable website domain2.com corresponds to the 2nd IP (which is missing): 10.0.0.183

1. This command curl --interface 10.0.0.10 ifconfig.me correctly retuns the elastic IP address associated to domain1.com while

This command curl --interface 10.0.0.183 ifconfig.me retuns:

curl: (45) bind failed with errno 99: Cannot assign requested address

1. I followed this guid, I can see eth1, but domain2.com is still unreachable

And curl --interface 10.0.0.183 ifconfig.me now returns this:

curl: (7) Failed connect to ifconfig.me:80; Connection timed out

Answer 1

You will need to use ip based virtual hosting for SSL. The IP address you are going to listen will be the private, not public IP.

Your sites on port 80 can use name based virtual hosting. But you need to make sure you are using this directive: NameVirtualHost *:80

Answer 2

This tutorial fixed it for me

One small (but important) note:

Instead of typing this command (step #5):

echo "1 admin" >> /etc/iproute2/rt_tables

You should do this instead:

sudo vi /etc/iproute2/rt_tables

then add 1 admin at the end of the file

Answer 3

I think you need to follow a troubleshooting methodology for this.

Start by simplifying your configuration and verifying the basic components, then gradually build it up to the complete solution. For example:

• Map the elastic IP for domain2 to a new EC2 server.
• On the new server, start by making domain2.com available over HTTP
• Once it is working over HTTP, set it up to work over HTTPS
• Once it is working over HTTPS map the elastic IP back to the original server and make it work on the original server using HTTP
• Once it is working over HTTP take the final step of getting it to work over HTTPS on the original server.

The aim here is to validate each step and isolate exactly where it is going wrong. This will then enable you to best direct your energies for solving the root cause.