AH01909: www.example.com:443:0 server certificate does NOT include an ID which matches the server name

Getting this error in my /var/log/apache2/error.log:

AH01909: www.example.com:443:0 server certificate does NOT include an ID which matches the server name

In Chrome, I get this error:
www.example.com sent an invalid response.

The website doesn't even work anymore.

ServerName localhost  // /etc/apache2/apache2.conf

<VirtualHost *:80>
  ServerName www.example.com
  ServerAlias example.com
  RewriteEngine on
  RewriteCond %{SERVER_NAME} =example.com [OR]
  RewriteCond %{SERVER_NAME} =www.example.com
  RewriteRule ^ https://www.example.com%{REQUEST_URI} [END,NE,R=permanent]

<VirtualHost *:443>
  ServerName www.example.com
  ServerAlias example.com
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

Ran these in order:

sudo certbot delete --cert-name www.example.com
sudo certbot delete --cert-name example.com
sudo certbot --authenticator webroot --webroot-path /home/example/example.com --installer apache -n -d example.com
sudo certbot --authenticator webroot --webroot-path /home/example/example.com --installer apache -n -d www.example.com

Restarted apache, rebooted server, etc.

Went to fix a small error with LetsEncrypt not auto-renewing - has now turned into a huge project where all of my website are now completely down and not working.

@peppers Welcome to this community for your first post!

The certificate should include all of the domain names in a single VirtualHost. You have both your apex domain and www name in the same VHost so your cert needs both names.

To combine both names on the same cert, do something like:

sudo certbot --authenticator webroot --webroot-path /home/example/example.com --installer apache -n -d example.com -d www.example.com

You only need one certbot command for this - not one for each domain name.

That said, it is much easier to assist when you complete the answers to the form you were shown when starting a post in the Help topic. Hopefully this is enough to resolve your situation. If not, it would be helpful if you provided at least the actual domain names. Thanks


This did not work. I'm still getting ERR_SSL_PROTOCOL_ERROR in the browser.

I am not seeing the "AH01909: www.example.com:443:0 server certificate does NOT include an ID which matches the server name" in the apache logs though.

Ubuntu 20.04

apache2 -v
Server version: Apache/2.4.41 (Ubuntu)
Server built:   2021-10-14T16:24:43

sudo certbot --version
certbot 0.40.0

Can login on root shell: yes. Have about 30 websites in VirtualHost

Good. Progress.

I cannot help further without your actual domains. And, I'm about to be offline for the night soon anyway. Maybe another volunteer will take over.

Until then, you could check your site with these websites for clues. That way you do not have to share your domain name. You could also search this forum for that error message.

Update: And, this one:

I also question your need for the --installer Apache. From your sample config it looks like you already have SSL configured. You do not need to do it again. Also, after certbot installs (configures) your apache it marks lines as "managed by certbot". You do not show those so I have to guess you updated your conf manually. If this is the case, you could change your certbot command to this - although I do not think this will resolve your protocol error.

sudo certbot certonly --webroot --webroot-path /home/example/example.com -n -d example.com -d www.example.com --deploy-hook "(command to reload apache)"

Update: Corrected webroot to be --webroot


Hi @peppers and welcome to the LE community forum :slight_smile:

I hope you are mature enough to retract your initial statement once we get to the root of the problem and it wasn't caused by LE:

[or did I read that wrong?]

Anywho... to your problem: Please show the output of
sudo apachectl -t -D DUMP_VHOSTS

sudo apachectl -t -D DUMP_VHOSTS
VirtualHost configuration:
*:80                   is a NameVirtualHost
         default server localhost (/etc/apache2/sites-enabled/000-default.conf:2)
         port 80 namevhost localhost (/etc/apache2/sites-enabled/000-default.conf:2)
         port 80 namevhost www.someotherwebsite.com (/etc/apache2/sites-enabled/someotherwebsite.com.conf:1)
                 alias someotherwebsite.com
         [ .... 30+ other websites with same setup ]
         port 80 namevhost www.example.com (/etc/apache2/sites-enabled/example.com.conf:10)
                 alias example.com
*:443                  is a NameVirtualHost
         default server www.someothersite.com (/etc/apache2/sites-enabled/someothersite.com.conf:11)
         port 443 namevhost www.someothersite.com (/etc/apache2/sites-enabled/someothersite.com.conf:11)
         [ .... 30+ other websites with same setup ]
         port 443 namevhost www.example.com (/etc/apache2/sites-enabled/example.conf:20)
                 alias example.com

Wow! You aren't even willing to put the effort into hiding the names individually.
search and replace "RealName1" with "FakeName1"
search and replace "RealName2" with "FakeName2"
search and replace "RealName3" with "FakeName3"
search and replace "RealName30" with "FakeName30"

If there is a problem in there, you have just erased it with:

Let's hope it's not there (as we look elsewhere)...

How about the output of:
certbot certificates
[this output you can reduce to only the cert(s) that have any of the names "example.com" or "www.example.com" - the rest are irrelevant]

1 Like

I am concerned about this line in that file I provided:

*:443 is a NameVirtualHost
default server www.someothersite.com (/etc/apache2/sites-enabled/someothersite.com.conf:11)

The default server is using a specific domain name "www.someothersite.com" and the "comeothersite.com.conf" config file.

Is that normal? I would think it would use "default server localhost" with the 000-default.conf like the *80 port.

Not much to worry about there.
The "default" is what gets served when SNI can't match the requested name.
If a vhost config isn't defined/labeled as "default", then Apache will simple take the first one found.
["first" here being the first such type encountered after including the main config and an alpha-numerically sorted list of included files]

That depends on your definition.
I find very little about Apache "normal".

1 Like

Never mind, the list was sorted alphabetically and LetsEncrypt tucked it in the wrong order:

Certificate Name: example.com
Domains: example.com www.example.com
Expiry Date: 2022-02-11 02:53:38+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/example.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/example.com/privkey.pem

At https://letsdebug.net/www.example.com/ , I am seeing this error:

www.example.com's webserver may be misconfigured.
Web server is serving the wrong protocol on the wrong port: Get "https://www.example.com/.well-known/acme-challenge/letsdebug-test": http: server gave HTTP response to HTTPS client. This may be due to a previous HTTP redirect rather than a webserver misconfiguration.

@0ms: Making a request to http://www.example.com/.well-known/acme-challenge/letsdebug-test (using initial IP ***.***.***.***)
@0ms: Dialing ***.***.***.***
@18ms: Server response: HTTP 301 Moved Permanently
@18ms: Received redirect to https://www.example.com/.well-known/acme-challenge/letsdebug-test
@18ms: Dialing ***.***.***.***
@37ms: Experienced error: tls: first record does not look like a TLS handshake

If I try correcting a different website, such as:

sudo certbot delete --cert-name example2.com
sudo certbot delete --cert-name www.example2.com
sudo certbot certonly --webroot --webroot-path /home/example2/example2.com -n -d example2.com -d www.example2 --deploy-hook "systemctl reload apache2"

I get these type of errors:

Challenge failed for domain example2.com
Challenge failed for domain www.example2.com
http-01 challenge for example2.com
http-01 challenge for www.example2.com
Cleaning up challenges
Some challenges have failed.

 - The following errors were reported by the server:

   Domain: example2.com
   Type:   connection
   Detail: Fetching
   Error getting validation data

   Domain: www.example2.com
   Type:   connection
   Detail: Fetching
   Error getting validation data

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

Everything was working fine earlier today, but LetsEncrypt did something that wrecked the server.


I'm having a hard time following that logic.
Your requests are for certonly
Such requests wouldn't change anything in your Apache config.
But you fail to show the config, so I really can't be sure of anything - more than you don't want to take any part of the "blame" (you seem to be throwing around).

Take a good look.
Four eyes are usually better than two...
But with your hands over mine, we're back with only two eyes - the same two that missed the mistake.
How is your HTTP vhost config handling the challenge requests?
How/why are they being redirected?
How are they being handled after the redirection?

1 Like

Ok, so I got it working by adding this to the inside of the mod_ssl modeule in: /etc/apache2/mods-available/ssl.conf, so it's like this:

<IfModule mod_ssl.c>
            <VirtualHost _default_:443>
                    ServerAdmin webmaster@localhost
                    DocumentRoot /var/www/html
                    ErrorLog ${APACHE_LOG_DIR}/error.log
                    CustomLog ${APACHE_LOG_DIR}/access.log combined
                    SSLEngine on
                    SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
                    SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

                    <FilesMatch "\.(cgi|shtml|phtml|php)$">
                                    SSLOptions +StdEnvVars
                    <Directory /usr/lib/cgi-bin>
                                    SSLOptions +StdEnvVars
  ... (more stuff here)

That seems to have gotten everything working again. Not sure why everything worked fine for months, and then everything breaks trying to fix the auto-renewal. One thing is for sure, I've never messed around with the ssl.conf file before. Most likely, it was probably some kind of error I made, LetsEncrypt allowed it to work for months, and then when LetsEncrypt made some slight changes on their end, everything broke.

I greatly appreciate your help Rudy and Mike for taking the time to work with me.

God Bless and stay safe.

1 Like

But, won't these changes get overwritten the next time you update Apache?

I am also puzzled why adding a default VHost would resolve it but given you are unwilling to share your config or domain names there is not much more that we can do.


It's like an intended unintentional mishap that just happens to get Apache to do what was "expected".
"This" will eventually resurface.

Changing the "default" means it is missing a SNI match and being forced to serve "it" via "default".

Apache is notorious for running at all costs.

Don't get me wrong, I do use Apache.
But I set my bar very low and expect things to go off track with it, so I build a very sturdy track even it can't derail. And I get my desired result.
If you set a very high bar and expect it to do things (right) for you by building a very flimsy track, it will go anywhere it wants and may sometimes end up where you wanted it to - but that is called "sheer luck".


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.