How to create the virtual web site (name based) accessible on http and https simultaneously ?
Example
server have ip address: 192.168.251.22 and virtual IP address=192.168.151.22
Target: create VirtualWebSite(name based) accessible on http and https simultaneously. ?
I can create a virtual site(name based), but he will be accessible ONLY on http or ONLY on https.
Pleae, help me.
Serg
Please don’t post the same question twice. It drives ppl nuts following two discussions simultaneously. I’ll delete the other thread for you.
In the meantime, this background might help: openSUSE Linux Apache Web Server
I just noticed your need for https, my link doesn’t cover that, hope someone else can help there.
Virtual Websites are for when you want to deploy multiple websites sharing the same IP address, then you would want Apache to parse the HTTP header of the request to determine which virtual website to connect to.
You’re asking instead how to configure both http and https access to a single website running on the machine, and the default Apache install should support that without additional configuration (well, almost).
(Of course unless things have changed since I’ve done this), What you will need to do is <do not> configure virtual websites simply deploy your website files to the Apache default website location and configure an appropriate SSL certificate.
Then, DNS should point clients to your machine for both http and https.
HTH,
Tony
PS. You can configure only one SSL certificate per IP address. You didn’t describe multiple websites but if that really is the situation then you may be trying to do something that isn’t permissable.
One SSL cert per IP address. Basically yes, but here’s why:
When your browser is asked to access a https URL among other things, it takes the IP address that results from the resolution of the domain name and maps it back to a domain name. If that doesn’t match the domain name in the certificate, it shows a warning and won’t let you proceed unless you click “I know what I’m doing”.
The negotiation of the SSL takes place before the dispatch to virtual hosts. It follows that name-based virtual hosting doesn’t work for https. You can only have one https site per IP address, which has to be the primary web site.
There is one way to get around the one https site per IP address and that is to rent a wildcard certificate, which will work for all URLs of the form *.domain. They cost more.
This is just a rough outline. There’s more in the details.
All true, but I’ve mused over time that this is how things work only because that’s the way things are designed to work (now). I haven’t researched but assume that the webserver ordered process of inspecting Host Headers is likely based on an RFC because all webservers work this way but I don’t know if security would necessarily be compromised if the process was modified in a way that would support multiple certificates per IP address.
Depending on exactly what the OP wanted to do if he reposted, the wildcard cert might have been a solution (note though that it still is restricted to at least the secondary domain (immediately below the TLD).
Tony
Vhosts don’t work with SSL simply because the SSL negotiation must happen first to ensure the confidentiality of the data. When that’s finished it’s too late to decide on a vhost based on the Host: header, you are stuck with the host you connected to. This is well explained in the Apache doco.
Yes, as SSL happens before any http is exchanged there is exactly one SSL configuration per IP:port possible.
In order to have multiple SSL context there are only three alternatives:
Use different ports for each service (does not work with https protocol type in many browsers)
Checkout mod_ssl - Apache HTTP Server and use SSL/TLS for different virtual hosts (enable/disable SSLEngine per virtual host) but this requires a *.domain.tld kind of certificate
Bet on RFC 2817 which brings TLS to HTTP and avoids the port related limitations of SSL. Even thouhg this RFC is more than 10 years old it is not widly adopted.
Yes,
And that is the (very common to all webservers) problem. Webservers route the whole session to the “website container” before decryption and parsing.
If webservers instead implemented a thin security later in front of the virtual webservers, it would enable a common shared management of security for all virtual websites and sessions would be decrypted and parsed <before> properly routing to the proper virtual server.
The proposed solution is a common software architectural problem and applying a common solution – The problem is that the procedure is too tightly integrated which forces inflexibility. Separate the functionality and the result is new flexibility in the execution plan. Note that just because the execution plan is modified, it does not compromise security because it’s still a closed plan with no diffeernt input.
As for TLS replacing HTTP to support encrypted sessions to different web hosts… it’s an interesting thought but I doubt makes any real difference(and notice the date, year 2000 
. I wouldn’t be real excited about an approach which sends encrypted and unencrypted payloads separately, I’d favor the way TLS and HTTPS work now which is to send all as one and expose as little unencrypted as possible. On this topic, who knows maybe someone will propose an RFC similar to how XML Web Services has evolved to support Secure Web Services, the problems and content are very similar… routing encrypted ANSI payloads.
IMO and just theorizing,
Tony
In industrial strength HTTPS sites this is not an issue. There is only one IP address and one domain name “fronting” the HTTPS but in reality it may be a cluster of machines using packet redirection, failover and various gnarly techniques to handle the load and assure availability. You didn’t think https://order.amazon.com was only one machine did you?
gnu_tls is another option to allow one IP to have multiple SSL sites - using wildcard or non-wildcard SSL certs. It is pretty cool - I recently used this for the first time and have several SSL vhosts all running on one shared IP - works pretty darn well.
Lews Therin
They’re called “SSL Accelerators” - essentially Web Proxies with extra resources to support the extra SSL load (because of the disconnected nature of http, <every> individual packet needs to be encrypted/decrypted, that is one of the primary differences between using an SSL tunnel vs some other more conventional VPN protocol).
BigIP is probably one of the biggest names of the many who do this, and yes they can be clustered.
Tony
There are many architectures to do this, accelerators are just a part of the picture.
Big IP - - - nice stuff, just bring your checkbook!
However, I think we may have wondered a bit far from the question the OP asked. Not that I mind too much, it’s a fun thread. Just funny though - we’ve gone from a very basic vhost config to discussing load balanced clusters of BigIP SSL boxes costing about $30K. There is some humor here.
Cheers,
Lews Therin