Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

currently I'm using the following scheme to serve both static y and dynamic content.

I have compiled stunnel with X-Forwarded-For support patch.

Internet(http) -> haproxy (frontend1) -> Apache Farm

Internet(https) -> stunnel -> haproxy (frontend2) -> Apache Farm

Stunnel is configured to use the certificate from It is possible to add support for stunnel to serve with other certificates?

cert = /etc/stunnel/group.cert
key = /etc/stunnel/private.key
verify = 0
debug = local0.debug
CAfile = /etc/stunnel/group.cert
chroot = /var/run/stunnel4/chroot
setuid = stunnel4
setgid = stunnel4
failover = prio
xforwardedfor = yes

accept = 443

I know I can run another stunnel instance wich binds to another IP address, but we don't have infinite public address if the we decide to host more sites, I know that one can configure Apache to serve different certificates per VirtualHost, is possible to do this with this scheme? Or maybe changing from stunnel to Apache mod_proxy or another solution.

Many thanks.

share|improve this question
I have found this on "A similar situation arises in the case of encrypted (https) content. But in this case, there is no such workaround: if we could decrypt the data to process it then so could any other man-in-the-middle, and the security would be worthless. This can only be circumvented by installing mod_ssl and a certificate on the proxy, so that the actual secure session is between the browser and the proxy, not the origin server." This is what I need but, I really don't have much experience with mod_proxy, how can I acomplish that? – AndresVia Mar 31 '11 at 0:25
up vote 1 down vote accepted

Serving different certificates on the same port on the same address depends on TLS Server Name Indication support, which is not supported by stunnel.

Using Apache as your proxy would indeed get you the server-side support that you'd need, however, keep in mind that client-side support (ahem, Windows XP) for Server Name Indication is not yet ubiquitous.

An alternative to consider, if it's in your price range, is a certificate that presents Subject Alternate Names.

share|improve this answer
That means that not all applications send the "Host: " header? – AndresVia Mar 31 '11 at 0:29
@AndresVia All modern browsers send the Host: header correctly. However, Server Name Indication is separate from that out of necessity. By the time the request headers are sent, the encrypted tunnel has already been fully established, and it's far to late to select the correct certificate for the site being served. – Shane Madden Mar 31 '11 at 0:33
Based on what I have found here here & here I have adapted a very simple config but I don't know what is wrong I get the "Oops, no RSA or DSA server certificate found for 'myname2:0'?!" and I'm using versions of Apache and OpenSSL with SNI support, @shane do you have any clue? – AndresVia Mar 31 '11 at 5:07
@AndresVia Looks like the SSLEngine on directive might be missing from your config file? You'll need that in each vhost, alongside the SSLCertificate directives. – Shane Madden Mar 31 '11 at 5:44
many thanks, there is my final working configuration [] – AndresVia Mar 31 '11 at 13:43

In general when working with SSL/TLS and multiple sites on the one IP, you have two options.

The first is to have the client send the name of the host that they're interested in with the initial request. This is what delivers, but that isn't supported by all clients (see the wikipedia page for the list of what does and doesn't work for it). With SNI, the hostname is available at the start of the secure negotiation, so the server can pick the right certificate to respond with.

If you're not able to use SNI, then you have a slight problem. The client turns up and says "Hey, I want to do SSL" but you don't know what host name they want, so you can't pick the right certificate. All you know is the IP address. So, to do that you have to ensure that the certificate you return is valid for all the different vhosts on that IP.

This latter one isn't necessarily as bad as it first sounds though. One option is to get a wildcard certificate, eg * . As long as you're serving and (i.e. both within the same wildcard space) you're fine. The other option is to use subjectAltName in your certificate. With this option, your one certificate is valid for multiple websites. That way, when you send the one common certificate back to the client, it'll be valid for whichever of the hosts they wanted. Quite a lot of CAs support this latter option, and it's generally the only option for EVA certs (you can't generally get wildcard ones of those), and you'd normally just ring up your CA every time you wanted to add a new vhost onto that IP, and they'll charge you a small fee and issue a new cert with the extra name in it.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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