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: 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: 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!

  • 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.
    – user39865
    Commented Oct 26, 2017 at 18:49
  • 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.
    – pixelmusik
    Commented Nov 1, 2017 at 7:24

9 Answers 9


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.


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
    . . .

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


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

  • 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?
    – lewis4u
    Commented Jun 3, 2019 at 9:17
  • 2
    yes, your webserver has to be accessible through a registered domain for let's encrypt to work.
    – pixelmusik
    Commented Jun 26, 2019 at 20:08
  • Downvoted. This is not an answer to the question. It is a way to get a certificate. People who like me come up with it's own way to configure ssl or are even a little bit off the beaten trail will not find anything useful to this problem in your answer.
    – Lothar
    Commented Feb 20 at 2:50

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 /home/mydomain.com/public_html>
        Options -Indexes +FollowSymLinks +MultiViews
        AllowOverride All
        Order allow,deny
        allow from all

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

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

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.

  • 1
    i totally forget to make Apache listen to 443 it was only listening to 80 thanks
    – Robert
    Commented Apr 2, 2018 at 21:21

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).

  • 1
    (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 Commented Dec 21, 2018 at 8:33
  • 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.
    – symcbean
    Commented May 6, 2019 at 20:05
  • 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. Commented May 10, 2019 at 4:55

I ran into this problem recently, when my self-signed certificate expired. I googled and just copied the command for creating a new certificate from one web site.

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/apache2/ssl/apache.crt

In my apache config file: /etc/apache2/sites-available/default-ssl.conf. The certificate file & key file refer to the following filename.

    SSLCertificateFile  /etc/apache2/ssl/apache.crt
    SSLCertificateKeyFile /etc/apache2/ssl/apache.key

Hence, the error seen here in my case was easier fix, just by providing the correct location of the certificate key file when creating the ssl certificate.

So, here is the command that I should have used & typed correctly.

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
  • 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.
    – TonyG
    Commented Apr 13, 2020 at 19:09

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 

We had to add the ServerName and ServerAlias to the default-ssl file, not just the conf file for the specific domain.
This got rid of the pesky error for us.


For me the reason why this error appeared was that I accidentally moved the htdocs folder to another location. Hope I helped.


For me the problem was when i did the following command. The www subdomain is an alias to the domain both in the same directory. But the ACME challenge root picked just for one and failed on the other.

Don't know exactly what it happened but it went away when i did the certbot calls sequenzial for each domain name

sudo certbot certonly -v -n --webroot -d filesqueezer.com,www.filesqueezer.com --webroot-path /var/www/websites/filesqueezer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .