I've been spending days to get my head around apache+ssl and im still left with uncertainties.
I know people keep saying you "Cannot have multiple SSL sites with the same IP!". But I kept assuming they were talking about internal IP not the external-IP.

External-IP as in 220.245.32.14 , outside the router, provided by the ISP.
Internal-IP as in 192.168.0.2 or 10.1.1.2 , behind the router, inside a LAN network.

So I wanna get things straight. This is what I gathered so far. Correct me if im wrong.

For a PROPER Apache+SSL configuration with multiple websites:
Each site must have a unique external-IP and a unique internal-IP.

For example:
https://www.aaa.com goes to 215.323.24.54 which goes into my router which forwards to 192.168.0.2
https://www.bbb.com goes to 223.436.34.57 which goes into my router which forwards to 192.168.0.3
which probably means these URLs are going to 2 different computers and 2 different routers.

Whereas the following example is not correct:
https://www.aaa.com goes to 215.323.24.54 which goes into my router which forwards to 192.168.0.2
https://www.bbb.com goes to 215.323.24.54 which goes into my router which forwards to 192.168.0.3
Because the External-IPs are not unique.

Am I correct? Or greatly confused?

Still talking about SSL, I know that you can use namevirtualhost in /etc/apache2/httpd.conf that allows one external-IP and one internal-IP, and it works but I gathered that it is not the 'proper' way.


Thank you in advance.

The internal-IP address doesn't matter much, you can run multiple SSL sites with only one apache and so only one internal IP address. Of course it's possible to do this with multiple internal addresses.

The external-IP addresses must be different, due to the SSL protocol. The problem is that you can't do
a namevirtualhost because SSL doesn't notice the web server the host it wants to connect to, so the webserver doesn't know what certificate send.

To amplify on what fatzeus has posted, the thing that matters is that SSL requests to start a new connection with your Apache server need to arrive at the Apache host with distinct IP addresses per host. This requirement arises because, as fatzeus says, the server needs to know which SSL certificate to send as authentication to the requestor before the requestor sends along the first HTTPS packet that contains the identification
of the (virtual) server of which the request is being made.

Thank you all for your responses.

So that makes IP aliasing, the ability to have many internal IPs for one webserver ( http://www.ibm.com/developerworks/we...-multissl.html ) pretty pointless then?

Does that pretty much mean 1 SSL site per apache per machine per router per ISP account?

Alright now here's my httpd.conf:

This setup seems to work great at the moment.
The certificate, apache.pem, has ServerName *.aaa.com.
So no errors (except it is self-signed, not trustworthy) for aaa.com and sub.aaa.com , except bbb.com which throws an error saying the certificate is not issued for this host.

NameVirtualHost 192.168.0.10:443 seems to allow each site to have it's own unique DocumentRoot. Whereas without it, if I access https://sub.aaa.com, and https://bbb.com, I will be accessing https://aaa.com

Considering I only have 1 external IP, is my current httpd.conf setup secure enough under SSL for aaa.com, sub.aaa.com and bbb.com? What should I change?

Thank you too dkm999 for further explanation.

I did some reading on the internet in the past couple of days as I converted my intranet server from separate sites to one site with subdomains. As far as I understand what I have read, none of the secure subdomains in your config match the wildcard certificate.
Only sub.aaa.com should match your certificate but aaa.com should not. It however may to be depending on the browser.

IE6 does not like wildcard certificates (it will tell you that the site name does not match the certificate), I hope I can test IE7 today. Firefox accepts (in your example) a.sub.aaa.com as well which it should not; this according to info on the internet.

PS: Checked IE7 today and it's also not happy. Opera however does not have a problem with wildcard certificates.

Just a note, when i was talking about Ips i was thinking on a more "enterprise" setup. You have for example 8 pulic IPs, your router have one Ip and your SSL server has 2 public IPs.

Like this:
Router 82.60.100.20
Server 82.60.100.21
Server 82.60.100.22

So in you httpd.conf you have something like:

#$%#@^*&^ Sorry for complicating things! it was a typo. Lets just forget about the '.au'.

Typo fixed in Post #4
If you all be so kind as to rid of '.au' in your posts, I don't wanna confuse future readers and responders. Thanks!

I have not seen addresses like 82.60.100.22 before, I've only seen 192.168.0.* , 10.1.1.* , 127.0.0.1 .

Ok, I'm not sure I understand these 'public IPs'. If you meant 'external IP' (for consistency sake, for this thread), then how can you get 8? How does my apache server get, not one, but two 'external IPs'?

The only thing that contains only one 'external IP' is the router, and all the computers behind the router, has 'internal IPs'. The router forwards the 'external IP' to the 'internal IP'.

That is my current understanding of IPs. If you can further elaborate, that would be good.

I think the discussion is every time more complicated:

-We should agree that if you have two different domains with SSL(e.g aaa.com and bbb.com) each must be server by two different public (or external if you wnat) IPs. For example 82.60.100.22, 82.60.100.23, but non 192.168.0.*, 10.*.*.*., 172.16.*.*.

-If we agree with the first point, than the ISP must give us at least two public IP addresses. Typical an ISP can give you 1 public IP, 8 public IPs, 16, 32, and so on (of course you pay for more ips).

-In your internal network you can have two apache servers, one for aaa.com and one for bbb.com, or you can have only one server with two ip public addresses.

-If the ISP gives you 1 IP that the typical config is to assign it to the router that through NAT gets you internal PCs (with internal Ips) to internet.

-If you have 8 IPs (or more) you assign public Ips to the router and to each PC, so you don't have NAT and you don't have internal Ips (you can also have internal Ips, in lots of setup you have tow NICs, one for the internal and one for the external network).

It seems to me that the discussion here could use a little additional clarification on IP addresses: these addresses are assigned to the systems, not exclusively to the Apache service. Usually, each network interface gets one address. In the case where a router is placed between the Internet and your computers, it handles blocks of addresses rather than a single one.

Since, nowadays, a computer can behave like a router in some ways, it, too, can respond to several addresses; this is what happens when you assign multiple IP addresses to a single network interface. As fatzeus has emphasized, each webhost (eg, aaa.com) needs to have its own IP address for SSL communication, whether Apache serves pages for that webhost or some other program does it. This is because of the SSL protocol, which requires that the connection be established both ways before the requestor can identify which hostname he is trying to reach.

There is an additional complication introduced when you use Network Address Translation or Port Mapping to redirect HTTP and HTTPS traffic within your site. Such redirection schemes change the view that some (but not all) hosts have of your actual web server setup. Requestors inside your private network (those that have 192.168.x.y or 172.16.x.y or 10.x.y.z addresses) may see several distinct IP addresses, ("local" or "private" addresses) each corresponding to a different webhost. But requestors outside your shop, elsewhere in the Internet, will only see "public" addresses for these webhosts. If the addresses for your several webhosts are not distinct from that viewpoint, the remote requestor will only be able to reach the first webhost in the set that all have the same IP address. First is defined as the one that appears earliest in your apache config file (/etc/httpd/conf/httpd.conf or equivalent). This behavior is Apache-specific; if Apache gets a request on the SSL port, it responds with the certificate for the first virtual server configured for that IP address and port.

There are a great many ways to configure things when you have several IP addresses assigned to you by your ISP. One is to assign a public address to each of several servers that are supposed to provide services to public requestors. The down side of this approach is that you have to secure each of those several servers against every conceivable attack that can arrive from anywhere on the Internet, and you have to maintain your Apache configuration separately on each server.

A second approach (which I favor) is to configure your router to redirect particular IP/port combinations to a single server. This approach centralizes the defense (at the router) and the HTTP/HTTPS configuration (at the Apache server). Using this scheme, you can redirect incoming connection requests for IP(1)/port 443 to a chosen port on your webserver (eg, 31701, not normally a well-known port) and redirect incoming requests for IP(2)/port 443 to the same webserver, but another chosen port. Then, configure your Apache server to listen on these ports, and your virtual host definitions to specify one of these ports each. Then, when a remote requestor tries to contact aaa.com, the router will redirect the SSL request to the correct port on your common webserver, which will respond with the certificate for aaa.com. A request for bbb.com will be redirected to a different port, and the webserver will respond with the certificate for bbb.com, just as if the requestor had reached a distinct host supporting only one domain.

HTH

Sorry I've been real busy. I appreciate all your time and effort in helping.

Not even www.aaa.com ? (with the w's)
What happens if it does not match? Does the site simply act as a normal port 80 http site?
Is there actually a way to test that SSL and certificate are working? Cos there is not much complaint from the web browsers after accepting the certificate. Maybe try to do a simple 'man in a middle' attack or something?

With this setup, since it is 1 router, do I still need 2 public/external IPs? How will my httpd.conf look like with this setup? What else needs to be configured? I only have 1 public/external IP, 1 router which forwards port 443 and port 80 to 192.168.0.10 which tries to host https://www.aaa.com , https://www.bbb.com and http://www.aaa.com, http://www.bbb.com

Hold it. I only took your example and commented on that one. You did not mention www.aaa.com

If it does not match the certificate, it will still do the encryption part, but users can not trust it. You can check if SSL is working by switching the SSL engine of and using a https url in your browser. You will see an error message in the apache error log

As noted previously, in order to support distinct HTTPS sites, you need distinct IP addresses; otherwise, the Apache server doesn't respond with the correct data. That requirement still stands if you use port forwarding to consolidate the Apache service onto a single machine.

There are two parts to setting up such a configuration: port forwarding on the firewall/router system, and virtual server setup on the web server machine(s).
1. Port forwarding is done on my systems using iptables.
In the NAT table, forward both the HTTP and HTTPS ports to the internal server:

-A PREROUTING -p tcp -d first_IP/32 --dport 80 -j DNAT --to-destination 192.168.your.internal_server:80
-A PREROUTING -p tcp -d first_IP/32 --dport 443 -j DNAT --to-destination 192.168.your.internal_server:443
-A PREROUTING -p tcp -d second_IP/32 --dport 80 -j DNAT --to-destination 192.168.your.internal_server:80
-A PREROUTING -p tcp -d second_IP/32 --dport 443 -j DNAT --to-destination 192.168.your.internal_server:10443

Note that even though the HTTPS traffic is redirected from two separate IP addresses to a single destination, the traffic is kept separate because it arrives at the destination server on separate ports.

Also, I have assumed for simplicity that the firewall machine does not originate HTTP or HTTPS traffic destined for the Apache server, and that it is OK for requests from behind the
firewall (other machines on your private net) to loop through the firewall machine and then back to the Apache server. Both of these inefficiencies can be improved with further complications to the port forwarding configuration.

I chose the port number 10443 for only two reasons: first, it is larger than 1023, the highest-numbered "privileged" TCP port, and second, it is easy to remember what this port is for, since it sort of looks like the HTTPS default port. Any port number will do, as long as the port-forwarding configuration agrees with the Apache configuration. Adjust as necessary for your setup.

2. Apache virtual server setup:
For each supported domain, you need a <virtualhost> declaration for each domain and service, taking account of the port mapping. For HTTPS domains, you need to use IP-based virtual hosts, while for HTTP, you can use Name-based virtual hosting:

Listen 80
Listen 443
Listen 10443
NameVirtualHost your_internal_server_IP:80
<virtualhost server_IP:80>
ServerName first.domain.com
...
</virtualhost>
<virtualhost server_IP:80>
ServerName second.domain.com
...
</virtualhost>
<virtualhost server_IP:443>
ServerName first.domain.com
...
</virtualhost>
<virtualhost server_IP:10443>
ServerName second.domain.com
...
</virtualhost>

For further reading, the iptables program is described both in its man pages, and in several places on the web. The Apache server manual has a good section on virtual hosting, and the differences between name-based and IP-based virtual hosting.

Fairynuff
Alright so it seems that posted data is encrypted and secure but it is just the issue of whether the certificate is trustworthy. But what's the worst that could happen if I accept a certificiate that's self-signed by some unknown individual? Additionally, what could happen if that certificate does not belong to that site?
---

In response to post #12 right above,
I forgot to mention my router is Netgear DG834. But anyway I know how to port forward but not sure how to get it to have more than 1 external IPs. Probably need to talk to the ISP about that. Your instructions about iptables will be useful if I use a computer as a router in the future.

Your virtualhost setup clearly shows that Namevirtualhost cannot be used with SSL sites. Each SSL site has its own unique external/public IP and unique ports.

Now look at my setting, in contrast to your proper way of setting up the virtual host.

I have only 1 external IP. I do use Namevirtualhost for my SSL sites and only 1 SSL port, 443 and 1 internal IP, 192.168.0.10. Pretty much the same setup as non-ssl sites except, non-ssl use port 80. This setup works for me, aaa.com shows its own proper content in the browser, and asks to accept the certificate, same goes with sub.aaa.com and bbb.com (except bbb.com complains that of certificate mismatch because the certificate is from aaa.com).

This setup goes against:
1. "...in order to support distinct HTTPS sites, you need distinct IP addresses..."

2. "For HTTPS domains, you need to use IP-based virtual hosts..."

3. and the need to have separate ports for each distinct HTTPS sites.

Why is it working? What errors am I missing? Or does it 'seem' to be working but not?

The fact that the sites shows its own unique content on the browser and asking for accepting the self-signed certificate or warn about certificate mismatch, proves to me that HTTPS is working.

Maybe I should just post the real URL for you all to check out instead of using aaa.com and bbb.com . Should I? my server is running on a very slow iMac G3 running Ubuntu. I'm afraid if I post the site, it will get bombarded with hackers and spammers or whatever. I'm paranoid.

Anyway here it is:
aaa.com= https://www.robin.com.au <- dont b fooled by the error page
sub.aaa.com= https://simmon.robin.com.au
bbb.com= https://www.infiniti-home-theatres.com <- dont b fooled by the error page

edit:
Actually here is /var/log/apache2/error.log after I sudo /etc/init.d/apache2 restart.

I think a point is being overlooked. It is not a question of whether you will accept a certificate, but whether other people will accept a (potentially bogus) certificate from you. The only reason to resort to HTTPS with all its complexity is so that other people will trust that, when they contact your site, they actually are talking with your server. If they accept a bogus certificate, they run a real risk that they are communicating with a hijacker. If they are willing to accept that risk, then you might as well use plaintext HTTP, and save yourself a lot of trouble.

Au contraire, as they say. HTTPS is an acronym for "HTTP over SSL". What is working is the HTTP part. The SSL protocol can be broken down fairly simply into 3 stages: hello and authentication, cipher change, and everything after that. In the first stage, right after the initial message has arrived, the server is required to reply with a server Hello and a certificate, which the client uses to make sure that the server is who the client thought he was talking with. After some more preliminaries, the client and server change ciphers, and only then begin to exchange "application data", in this case HTTP messages. One of the headers sent in the initial HTTP GET request is the Host: header, which is used by Apache to match with the ServerName string in your VirtualHost container.

But you have already noted that you are getting log warnings that the certificate being sent out in the SSL Hello stage does not match the one that is going to be required by the client browser. So I submit that it is not working, even though, if you dismiss the security warning, then you get the data you expect. See my opinion above about using HTTPS at all.

My statements that you quoted above are thus shown to be a little inaccurate. I suppose that I should have qualified them by saying "If you want clients to assume the security that normally goes with using HTTPS, ...". With this qualifier, my assertions stand.

But if the user accepts a bogus certificate, is the data transaction between the client and server at least secure/encrypted? As pointed out by Wim in Post #11

I did some further reading at http://en.wikipedia.org/wiki/Https .

These snippets are what caught my attention.
---------
"Some sites, especially those operated by hobbyists, use self-signed certificates on public sites. Using these provides protection against simple eavesdropping, but unlike a well-known certificate, preventing a man-in-the-middle attack with a self-signed certificate requires the site to make available some other secure method of verifying the certificate."

"A common misconception among credit card users on the Web is that https: fully protects their card number from thieves. In reality, an encrypted connection to the Web server only protects the credit card number in transit between the user's computer and the server itself. It doesn't guarantee that the server itself is secure, or even that it hasn't already been compromised by an attacker."
----------

What I got from this, is that the certificate is reponsible for 'securing' the server-side, as in verifying the authenticity of the site, but not really data encryption during transaction. Right?

What I really care about at the moment, is that the users can transfer username,password securely from client to server. I want the transaction to be secure. Lets not care if my server can be trusted for now.

So with my current flawed configuration, is the transaction between the client and server secure at all?

Or is the certificate essential for a secure encrypted transaction? If so, even with a bogus certificate, is the transaction secure? (same question as the 1st paragraph really).

Sorry if im being 'slow', cos i am.