0

Using SNI, there are multiple domains with their own SSL certificates (LetsEncrypt) on one IP address. For one of the primary domains, let's just say https://thedomain.tld, visiting https://www.thedomain.tld results in a browser error (mis-matching SSL certificate) instead of either serving content for www.thedomain.tld or redirecting. I have tried it a variety of ways. An example:

<IfModule mod_ssl.c>
  <VirtualHost 0.0.0.1:443>
    ServerName              domain.tld
    ServerAlias             www.domain.tld

    DocumentRoot            /var/www/domain.tld/
    ...

    SSLEngine               on
    SSLCertificateFile      /etc/letsencrypt/live/domain.tld/cert.pem
    ...

    <Directory /var/www/domain.tld>
            Options         -ExecCGI -Indexes -Includes +FollowSymLinks
            AllowOverride   FileInfo AuthConfig

            RewriteEngine   on
            RewriteBase     /
            RewriteCond     %{HTTP_HOST} ^www\.(.*)$ [NC]
            RewriteRule     ^/(.*)$ https://%1/$1 [R=301,L]
    ...

Version: Apache 2.4.18

Side note: One one server, this works fine (Dedicated Ubuntu 16.04). On the other (Amazon Ubuntu 16.04), its ability to redirect or reference or whatever the www- and without is nonexistent.

conspireagainst
  • 1
  • 2
  • 1
    Fix the certificate, then. – Michael Hampton Apr 05 '18 at 03:38
  • Like Michael implies, you need a wildcard certificate or a certificate with alternate names which fit the scheme of names you are using. This is the normal behaviour when dealing with SSL certificates, not a server software thing. – Daniel Ferradal Apr 05 '18 at 06:00
  • It's simply easier (in my situation) to issue a second certificate for the domain, minus the www and redirect. I've posted my solution as the answer. – conspireagainst Apr 05 '18 at 17:56

2 Answers2

0

First things first, if you serve http://www.thedomain.tld at all, I would consider redirecting it to https://thedomain.tld. This solves the problem for users typing www.thedomain.tld in their browser (but doesn't solve it for users that type https: or already have https links/bookmarks or are forced to https by browsers/HSTS).

If you don't serve plain http, then unfortunately you either need a certificate that contains either www.thedomain.tld or *.thedomain.tld in certificate's SAN field (or CN field if SAN is absent) .

There is no way you could bypass it with anything Apache produces. The first thing that a browser gets after a TCP connect is a certificate. If the SAN/CN doesn't match precisely the hostname that browser wants, it's game over. Browser displays a warning and doesn't even send http request so Apache is never bothered to respond.

A redirect doesn't happen all the same.

If you obtain www.thedomain.tld certificate separately from thedomain.tld certificate, you need to put a separate ServerName in a separate Apache VirtualHost. But it generates a maintenance hassle.

I'd recommend a single certificate (SAN field can contain many names) and then a ServerName+ServerAlias config would work as you specified.

kubanczyk
  • 13,812
  • 5
  • 41
  • 55
0

I was able to solve it by hacking in a redirect, using two SSL certificates. This is not my preferred method, but it's working now.

www. is authoritative for this website, so here is what I did:

  • issue another certificate for domain.tld

  • blanket redirect https://domain.tld to https://www.domain.tld

    <VirtualHost *:443>
    ServerName              domain.tld
    DocumentRoot            /var/www/domain.tld

    SSLEngine               on
    SSLCertificateFile      /etc/letsencrypt/live/domain.tld/cert.pem
...

    RedirectMatch           301 (.*) https://www.domain.tld$1
</VirtualHost>
<VirtualHost *:443>
    ServerName              www.domain.tld
...
conspireagainst
  • 1
  • 2