0

I have an apache 2.4 webserver running on Ubuntu 14.04 LTS.

Is it possible to enable SSL only for a single VirtualHost and leaving the other VirtualHosts unaffected (including the default one)?

For example, in my web server I have this sites running over HTTP: 

000-default.conf  
hello.com.conf  
welcome.com.conf  
secure.com.conf

I don't have default-ssl.conf enabled.

Now I want to run secure.com.conf under HTTPS (:443) so I enabled the ssl plugin with a2enmod ssl and changed the VHost configuration in this way:

<VirtualHost *:443>
    ServerName www.secure.com
    ...
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/www.secure.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/www.secure.com/privkey.pem
</VirtualHost>

Anyway, when I restart apache with service apache2 restart it fails and says:

[ssl:emerg] AH02240: Server should be SSL-aware but has no certificate configured [Hint: SSLCertificateFile] ((null):0)
[ssl:emerg] AH02312: Fatal error initialising mod_ssl, exiting.

EDIT:
By adding SSLCertificateChainFile to the configuration I managed to start the webserver...

Anyway, if I try to load (just for testing) https://hello.com, apache now wants to serve it and all the other VirtualHosts with the secure.com certificate and of course the browser gives the error: NET::ERR_CERT_COMMON_NAME_INVALID

TesX
  • 149
  • 1
  • 2
  • 6
  • Could you add the output of ```egrep -ir '^[^#]* (sslcertificate|sslengine|virtualhost)' /etc/apache2/*conf* /etc/apache2/*enabled``` to the question ? – ALex_hha Apr 01 '16 at 10:22
  • @ALex_hha It returns nothing... PS: I have commented those lines in secure.com.conf, otherwise my webserver won't start... – TesX Apr 01 '16 at 10:48

3 Answers3

1

The error seems to indicate that the letsencrypt certificate is not available at the location of SSLCertificateFile. Without a certificate, the server cannot serve SSL. Did you install the letsencrypt setup correctly? Usually there is a snakeoil self-encrypted certificate in your /etc/ssl/certs and /etc/ssl/private paths. You could use that for testing purposes: the server will run fine, but the browser will complain.

Michiel Uitdehaag
  • 61
  • 3
  • The file `/etc/letsencrypt/live/www.secure.com/fullchain.pem` exists though... Maybe it complains about not having a default certificate for the other VirtualHosts? – TesX Apr 01 '16 at 11:31
  • The ServerName will make sure that SNI works. However, if the other virtual-hosts do not have an SSL configuration, than the secure.com configuration is the only site available on the SSL port. That means, if the browser connects to the IP address on port 443, Apache can only serve the secure.com domain. You need to specify a default SSL site without a servername as a catch-all to allow Apache to redirect traffic for other sites to something useful. This usually displays an 'Its working' message. – Michiel Uitdehaag Apr 01 '16 at 13:32
  • Does this change something for SEO? Or, is it possible to redirect the non HTTPS VHosts to the HTTP version? Thanks. – TesX Apr 01 '16 at 13:44
  • 1
    Yes, you can use a simple redirect statement in the default SSL configuration to always redirect to the non-SSL versions. Yes, this probably has some effect on SEO, but primarily because search engines take everything into account for determining relevancy, so everything has effect. A misconfigured site serving the wrong certificate causes search-ranking to drop. An SSL site redirecting to a non-SSL site will probably also cause ranking to drop. But for the SSL site secure.com, this has no SEO implications. – Michiel Uitdehaag Apr 05 '16 at 07:13
1

(1) Check your private key permissions (2) Where's your CA CRT?

So generally we need:

a) private key, b) server CRT, c) root/CA CRT.

This is an example

SSLCertificateFile /etc/pki/tls/certs/ca.crt
SSLCertificateKeyFile /etc/pki/tls/private/ca.key
SSLCertificateChainFile /etc/pki/tls/certs/DigiCertCA.crt
0

If you actually tried to hit https://hello.com (i.e. http SECURE), this is because of the way that Apache resolves the correct virtual host. As noted in the Apache documentation,

Name-based virtual host resolution only chooses the most appropriate name-based virtual host after narrowing down the candidates to the best IP-based match. When a request arrives, the server will find the best (most specific) matching argument based on the IP address and port used by the request.

If no matching ServerName or ServerAlias is found in the set of virtual hosts containing the most specific matching IP address and port combination, then the first listed virtual host that matches that will be used.

So, in this case, because you have asked for port 443 service, the ONLY option the server can try is the www.secure.com virtual host (secure.com.conf). Because at this point hello.com does not match secure.com, you are seeing this error.

This error is what is supposed to happen because there is NO https://hello.com, only a http://hello.com. If you want such traffic to go somewhere by default, you can set up a default secure virtual host that redirects all secure traffic not matching a virtual host to a secure virtual host with a correct certificate.

Colt
  • 2,029
  • 6
  • 21
  • 27