Apache: Conditional SSLCertificateFile depending on domain? - apache

I am running a multi-language web store accessible from differents domains, that lead to different languages.
The apache configuration is quite complex and I would like to have one single file shared with all the stores. I had this in place until I had to introduce SSL.
When it comes to apache and SSL certificates I would need to do something like:
SetEnv is_es 0<br>
SetEnvIfNoCase Host .*es is_es 1<br>
SSLCertificateFile /etc/ssl/certs/spanish.server.crt env=is_es<br>
This is aparently not possible, apache tells me:
<i>SSLCertificateFile takes one argument, SSL Server Certificate file (`/path/to/file' - PEM or DER encoded)</i>
I was wondering if there is any workaround. My goal is to avoid having different copies of the same configuration and having to propagate manually any changes I want to make.
It is hosted on a dedicated server, so I am free to do any changes to the setup.

When you are on a https connection, the Host header is inside the SSL encapsulation, so you need the full SSL handshake before you check for an hostname for your virtualhost.
You should go for SSL certificates with SAN (Subject Alternative Names), this will allow that a single certificate for multiple hostnames. (or a wildcard cert)
All the main browsers supports it already:
http://www.digicert.com/subject-alternative-name-compatibility.htm
And you can get one of this certs from the majors CAs:
http://www.digicert.com/subject-alternative-name.htm
http://www.verisign.com/ssl/buy-ssl-certificates/subject-alternative-name-certificates/index.html
http://www.thawte.com/ssl/san-uc-ssl-certificates/index.html

Related

Use more than 100 multi-domains with single ssl cerficate

I have a requirement of providing different domain to each seller in my e-commerce application like Shopify does. I don't think using multiple ssl certificates(one ssl certificate for each domain/seller) is a good option. For managing multiple domains, as I get to know so far is that I can use SAN multi-domain certificates which can handle different domains but only upto 100 different domains. Is it possible to handle multiple SAN ssl certificates on single server? Also I am using load-balancer for my AWS instances, how can I manage my load-balancer in case of multiple SAN ssl certificates. Can any one please answer?
Currently most certificate authorities limit the maximum number of SANs you can request in a single certificate to around 100, although, I've heard of some offering up to 150.
You can use multiple SSL certificates in Apache with multiple VirtualHost blocks, and Nginx with multiple server blocks. You can also specify multiple certificates for the same VirtualHost or server block, if you didn't want to split them up. Or if each client is getting their own block anyway, you can just point them all to the same certificate that has their domain in the SAN field. It just depends on your setup.
Whichever method you choose, you'll want to ensure that the VirtualHost or server block has a ServerName (apache) or server_name (nginx) listed for each SAN it will be answering for.
As for load balancing with multiple certificates in AWS, Amazon implemented support for this recently (October 2017).

Apache2 - Install several certificates for different domains without virtualhosts

I have an application written in Symfony2 which basically is a website builder. There are many domains pointing to the server IP, the php app inspects the request and displays the contents associated to that domain.
Is there a way to install ssl certificates on Apache for every domain, every domain should have its own certificate, whithout having any Virtuahost?
Apache is configured to answer to every request on port 80 and 443
Apache permits only 1 certificate per configured host.
So to achieve your goals, you will either need to use a multidomain certificate and include all domain in that certificate. By default, most vendors limit you to 100 domains per certificate. Note that www.domain.com and domain.com count as 2 different domains for the purpose of multi-domain certificates.
https://wiki.apache.org/httpd/UnderstandingMultiUseSSLCertificates
Otherwise, you will need to configure Vhosts for each domain. Depending on your OS, you may be able to use SNI with Apache so you don't need unique IPs for each domain.
https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Avoiding SNI for SSL on a single server hosting multiple vhost entries

I am trying to host 2 sites on a single IP address and they need to be accessed via SSL however the majority of my users use Internet Explorer on Windows XP meaning using multiple SSLs with SNI may prevent them getting access.
I was wondering if I could use a multiple virtual hosts but still use a single SSL certificate and avoid SNI ?
Alternatively how feasible is it for me to install two Apache webserver instances, each its own DocumentRoot and own SSL certificate and for me to simply use the first Apache webserver as an entry point to entertain some requests and to redirect others to the other SSLed Apache instance ?
Could I potentially use the Windows Host file (Windows 2008 Server) to redirect incoming requests to the intended Apache Server instead of using VirtualHosts ?
Apologies if I have confused concepts.
You can try to purchase an X.509 certificate with two domains in it. I don't know what particular CAs do this, but I also don't see why they would refuse. You need to ask their support, though.
Your idea to redirect some requests to another server residing on a different port sounds good as well, though you will have to use two different certificates for different domain names, of course.
Finally if your second domain can be something like additional.mydomain.com , you have greater chance to buy a certificate issued for mydomain.com + www.mydomain.com + additional.mydomain.com (this can be a wildcard certificate or a certificate with additional subdomain names).

validate SSL certificate on a shared hosting

according to this question all HTTP header when we are using HTTPS are encrypted(including request URI and Host header).
when browser want to browse a page on website that using HTTPS, it first create secure connection, then it sends HTTP request(encrypted) and server return the answer to browser. Now assume there are more than one secure website with more than one SSL certificate, so when server want to create secure connection how does it detect which certificate should be used because it doesn't know anything about request!!!
Since the SSL channel is negotiated prior to the reception of the Host header, an HTTPS server can use at most one certificate per bound IP endpoint (IP address and port). In other words, to use two different SSL certificates, you will either need to bind each virtual host to a different port, or a different IP address.
Before TLS the server indeed didn't have a way to know certificate of which host it should present to the client and this caused problems.
In TLS there was a special extension named Server Name introduced (see RFC 3546), which lets the client tell the server, what host the client wants to connect to. Based on contents of this extension the server can present proper certificate. Of course, all of this requires that TLS and the extension itself are supported and used by both parties.
The basis of this is to provide a SSL key(set) for each virtual server.
In Apache, for example, it's relatively simple. Each shared site is likely in a <VirtualHost> directive. The SSL keys can be specified within that, and thus apply to that virtual host only.
Rough example:
<VirtualHost *:443>
ServerName server.com
SSLEngine on
SSLCertificateKeyFile /etc/ssl/server_com.key
SSLCertificateFile /etc/ssl/server_com.crt
SSLCertificateChainFile /etc/ssl/server_com.ca-bundle
The server will then use the specified keys for all requests directed to that site over HTTPS. Further details on the Apache site. Similar things should apply to most web servers that support a concept of virtual hosts.
You won't get any errors, as the certificate and domain name match up.

static IP address, ssl certificate, and the root of all evil

I have a question, I fear the answer.
I have:
a top level domain name (free from Tokelau, a territory of New Zealand, .tk, where else?),
a free 2 year ssl certificate from startSSL.com,
a free hosting package.
Now I jumped through every hoop startSSL wanted (admittedly wasn't too difficult), to get me my 2 year ssl certificate, and now I fear I have encountered a final barrier to success that might still stall my plans. I dreamt of a corner certificate stating "Secured by startSSL". I got the code snippet and everythings, and have pasted it into my website.
Problem. my host is not so keen on a free package to allow me to ssl.
As far as I know you need access to some config files to allow this to happen?
or can you just like with .htaccess and .htpassword files do the setting on your webhost?
Also you need a static IP. Are there any workarounds?
Or am I dreaming? Anyone with advice?
SSL Requires some files and configuration changes, pointing to the files.
Also, the static IP is required because with an encrypted request, there's no way to know to what host the request is intended without decryption. The use of a static IP address gives that request a destination.
To clarify: when using virtual hosts, multiple hosts will share the same IP address, so when a request comes in, the first two lines are:
GET /path/to/resource HTTP/1.1
Host: www.example.com
Apache (or any web server), looks at the 'Host' field to determine how to route the request. If the request is encrypted, there's no way to determine how to route the request, and you need to know what certificate to use in order to decrypt it.
Forget it. If your host doesn't have SSL configured, you have no chance to add it without their help
There are two problems with your proposed set-up.
Free hosts generally don't provide a control panel interface to allow installation of SSL Certificates (at least I've never seen it) as this requires either their help on the back-end or VPS / Dedicated Server access from the front-end.
Static IP address is a must for SSL certificate installation.
From webserver perspective, SSL cert is about a port and an IP address, even when being used with Name-based virtual hosts.
SSL is about the IP the matching the cert and domain in the URL/request(to verify the cert).
You would have to give a second SSL cert different port or different IP address on the webserver.
Alternatively, you can also get multi-domain and wildcard certs that allow different hostnames or domains to match the cert with different client request URLs, but the cert is still the only thing on that port/IP of the webserver.
Just my $.02