Apache SSL: server cert does not include ID which matches server name

Question

I'm trying to set up SSL on my apache2 webserver, but it seems that it does not work at all.

I have followed a tutorial to create cert files with openssl and configured the /etc/apache2/sites-available/default-ssl.conf properly.

Every time I try to open my website with https, my browser refuse to connect due to security issues. It says that I haven't configured my website correctly.

In my /var/log/apache2/error.log I'm getting warnings, which say that my server certificate does not include an ID which matches the server name.

[Mon Apr 10 11:03:24.041813 2017] [mpm_prefork:notice] [pid 1222] AH00169: caught SIGTERM, shutting down
[Mon Apr 10 11:03:30.566578 2017] [ssl:warn] [pid 661] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Mon Apr 10 11:03:31.579088 2017] [ssl:warn] [pid 1194] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Mon Apr 10 11:03:31.592958 2017] [mpm_prefork:notice] [pid 1194] AH00163: Apache/2.4.25 (Raspbian) OpenSSL/1.0.2k configured -- resuming normal operations
[Mon Apr 10 11:03:31.593136 2017] [core:notice] [pid 1194] AH00094: Command line: '/usr/sbin/apache2'

Do you have any ideas on how to solve this? Thanks in regard!

Solution 1

Okay, I noticed that this post is viewed quite often recently and so it seems that a lot of people are facing the same issue that I did. If so then this might help you.

I have followed a simple step-by-step tutorial to create a SSL-certification for my webserver. Like so many tutorials out there the outcome of the tutorial I followed was a self-signed certificate using OpenSSL. Yep self-signed, that was the problem. The browser could not trust the server due to it's certificate which is signed by itself. Well I wouldn't do either...

A certificate has to be signed by an external trustworthy certificate authority (CA). So I stumbled upon Let's Encrypt which does all the work for you and is even easier to set up and the best is: it is absolutely free.

Installation

1) Delete your old ssl cert files which you have created by using OpenSSL

2) Open backports to get certbot client on Debian. You should know that this will open a hole for unfinished software! Install only the packages when you are aware about what you are doing.

echo 'deb http://ftp.debian.org/debian jessie-backports main' | sudo tee /etc/apt/sources.list.d/backports.list

3) Update your linux system

sudo apt-get update

4) Install certbot

sudo apt-get install python-certbot-apache -t jessie-backports

5) Set up apache ServerName and ServerAlias

sudo nano /etc/apache2/sites-available/000-default.conf

6) Edit apache config file

<VirtualHost *:80>
    . . .
    ServerName example.com
    ServerAlias www.example.com
    . . .
</VirtualHost>

7) Check for a correct syntax

sudo apache2ctl configtest

8) If the config file looks fine, restart apache server

sudo systemctl restart apache2

9) Set up a certificate using certbot and follow the instruction on screen.

sudo certbot --apache

Renewal

All certificates by Let's Encrypt are valid through 3 months. To renew the you can manually run

sudo certbot renew

Or automate this service as a cron job

sudo crontab -e

and enter the following row to invoke a renewal every Monday at 2:30 am.

. . .
30 2 * * 1 /usr/bin/certbot renew >> /var/log/le-renew.log

You can follow a more detailled tutorial here: https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-debian-8

Solution 2

In my case I have resolved this by replaced in my apache ssl config file for each concerned domain :

ServerName mydomain.com
ServerAlias www.mydomain.com

by :

ServerName www.mydomain.com
ServerAlias mydomain.com

Because my certificate is for "www.mydomain.com" and not for "mydomain.com"

complete apache file :

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerAdmin [email protected]
        ServerName www.mydomain.com
        ServerAlias mydomain.com
    DocumentRoot /home/mydomain.com/public_html
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|ico|png)$ \ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ \no-gzip dont-vary
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

    <Directory />
        Options +FollowSymLinks
        AllowOverride All
    </Directory>
    <Directory /home/mydomain.com/public_html>
        Options -Indexes +FollowSymLinks +MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
    </Directory>

    ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
    <Directory "/usr/lib/cgi-bin">
        AllowOverride All
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        Allow from all
    </Directory>


ErrorLog ${APACHE_LOG_DIR}/error.log

LogLevel warn
SSLCertificateFile /etc/letsencrypt/live/www.mydomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.mydomain.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Solution 3

If you are seeing no other SSL errors, and if you have tried setting 'LogLevel debug' in the httpd.conf file, this error message can also suggest 'Listen 443' is missing from the httpd.conf file.

Solution 4

Those are not errors - they are warnings. It is quite possible to run mod_ssl with a certificate which doesn't match the defined server names as long as you have a default ssl host defined and the common name on the certificate matches the host name used by clients to connect.

The latter does not appear to be true in your case. As Jacob says, you need to specify the correct host name as the common name (or an alias) when you create a CSR.

To see what name(s) are currently on the certificate:

openssl s_client -showcerts -connect ${HOSTNAME}:443

If there are multiple certificates installed on the machine and served on the same IP address, then:

openssl s_client -showcerts -connect ${HOSTIP}:443 -servername ${HOSTNAME}

(where the ${...} values are placeholders you should replace with the relevant values).

Solution 5

I found a solution that work for me SSL ON CENTOS 8

1. open nano /etc/httpd/conf.d/ssl.conf
2. Add your ssl in the ssl.conf file
3. DONE

SSLCertificateFile /etc/letsencrypt/live/radiolatina.ru/fullchain.pem 

SSLCertificateKeyFile /etc/letsencrypt/live/radiolatina.ru/privkey.pem 

View more solutions

Comments

[Admin]

Were you using Apache 2.2 or 2.4? I upgraded from 2.2 to 2.4 and getting this error. In my case it's not a public server, it's an internal one, so I'm guessing self-signed certificate will do.

[pixelmusic]

I was using Apache 2.2 on my public server (Debian 8) when I got this error. After switching to Let's Encript the error was gone so I guess it was the self-signed certificate that caused the error.

[Robert]

i totally forget to make Apache listen to 443 it was only listening to 80 thanks

[dave_thompson_085]

(1) you should put server name in CommonName in CSR, but whether it is actually needed (whether CA checks and/or copies it) depends on the CA (2) openssl s_client shows subject and issuer for the leaf cert, which is the only one you need here, without -showcerts, but for real-CA certs since about 2010 (and DIY certs by competent people) what you need to look at is not subject but SubjectAltName (SAN) extension and for that you need openssl s_client -connect h:p [-servername h] | openssl x509 -noout -text

[chrishollinworth]

Note that from mid 2018, you need to specify the DNS name in the subject alternate names too if you want your certificate to be validated correctly in modern browsers.

[dave_thompson_085]

I don't know of any change in 2018; Chrome has required SAN (for either DNS or IP, though the latter is rarely used) since early 2017, and Firefox and IE (which I still consider modern) don't require it today -- although as I previously said public CAs have provided it much longer.

[lewis4u]

This can't be used for localhost (virtual machine on local network), I mean you need to buy a domain to use let's encrypt right?

[pixelmusic]

yes, your webserver has to be accessible through a registered domain for let's encrypt to work.

[TonyG]

The information here was helpful in a scenario where I have many virtual hosts and the warning was about the localhost hostname, which is not a FQDN. Getting the self-signed cert. There is now a different warning that the .crt file is a CA cert, but I feel more comfortable with that warning than the the original.