None of the common names in the certificate match the name that was entered

My domain is:

I ran this command:
sudo certbot --apache -d www.gd.com -d gd.com

My web server is (include version):
Apache
The operating system my web server runs on is (include version):
Cent OS 7

The version of my client is
certbot 1.11.0

https://www.sslshopper.com/ssl-checker.html#hostname=http://gd.com

1 Like

What was the output of certbot? If you don't have that any longer, please post the output of /var/log/letsencrypt/letsencrypt.log. Please put three backticks (```) above and below the output, like this:

```
log contents
```
2 Likes

After that I tried certbot --force-renewal
content-length: 658```

1 Like

That doesn't seem to be the entire contents of the log, is that correct? It should be way more lengthy.

Also, please don't use --force-renewal: this wasn't a problem with certificate issuance, but with certificate installation. If you look at crt.sh | godzonestudy.com you can see there were two certificates issued: the first one probably on your first attempt, the second one when you used --force-renewal. You can check if the certificate was issued and saved properly by running certbot certificates. If the problem is with installation of an already issued certificate, then it's no use to force issuance of a second one: that won't fix the installation issue.

Unfortunately, without the rest of the log contents, it's very hard to pin down what went wrong. If you're somehow not able to post the entire log here on the Community, please use a site such as https://pastebin.com/ to paste the entire content to that site and put the URL to that paste here.

3 Likes

when I run certbot certificates it shows the certificate details

'''Certificate Name: www.gd.com
Serial Number: 4b99b65b6caffd584e7c740241a1c6f3430
Key Type: RSA
Domains: www.gd.com gd.com
Expiry Date: 2021-10-15 11:15:35+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/www.gd.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/www.gd.com/privkey.pem
'''

1 Like

I expected as much. So issuance and saving of the issued certificate wasn't a problem, but the installation part into Apache is.

If you don't have more contents of the log you can show us, you could try installing it again with:

sudo certbot --apache -d www.godzonestudy.com -d godzonestudy.com --reinstall -vv

This would try to reinstall the existing certificate. It'll probably fail again, but please paste the output to this thread, so we can determine why it fails.

2 Likes

Information

Well, that is weird.. Because that's not actually the case.

Could you show the output of the command:

sudo apachectl -S

Please don't forget the three backticks (```) above and below (on a single line) for better readability of the output. You can find the "backtick" on most international keyboards just below the Escape key and just left of the "1" key :wink:

1 Like

informations

Ah yes, I see what's going on. Allmost all of your other HTTPS virtualhosts on port 443 are configured as follows, with the IP address set in the <VirtualHost> directive:

However, all of your HTTP virtualhosts on port 80 are using a wildcard (*) in stead of an IP address:

Therefore, when certbot used the HTTP port 80 virtualhost file (/etc/httpd/sites-enabled/godzonestudy.com.conf), it did not know of the fact that all HTTPS virtualhosts used the IP address. It just used the wildcard, as that was also used in the HTTP virtualhost. And thus you ended up having a *:443 set of virtualhosts too:

But: Apache prefers the IP:port combination above all *:port virtualhosts! Please see the following part of the Apache virtualhost documentation:

If multiple virtual hosts contain the best matching IP address and port, the server selects from these virtual hosts the best match based on the requested hostname. If no matching name-based virtual host is found, then the first listed virtual host that matched the IP address will be used. As a consequence, the first listed virtual host for a given IP address and port combination is the default virtual host for that IP and port combination.

That means that Apache does not even consider using your "port 443 namevhost www.godzonestudy.com"! Because it has matching IP:port virtualhosts! It does not matter in that case that it can't find a virtualhost with ServerName "www.godzonestudy.com". Because it can match the IP address and port to the 159.89.173.97:443 NameVirtualHost, but not find the actual hostname, it will use the default server of the 159.89.173.97:443 NameVirtualHost. In this case your Apache sends an expired certificate for adoxglobal.com, not sure why that's the case, but for the hostname currently at issue, the above is the explanation.

Now for the solution(s), there are three:

Either change all <VirtualHost 159.89.173.97:443> to <VirtualHost *:443> or
Change all <VirtualHost *:80> to <VirtualHost 159.89.173.97:80> (but only if those virtualhosts actually use that IP address of course) and try to install the certificate again with the command I just gave you. You'll probably need to delete the file generated by certbot /etc/httpd/sites-available/godzonestudy.com-le-ssl.conf before you try to install it again.

My preference for servers with just a single IP address: just use *:80 and *:443. Using IP:port is only usefull if you have multiple IP addresses and are using those IP address to select virtualhosts.

The third option is to manually edit the configuration file generated by certbot /etc/httpd/sites-available/godzonestudy.com-le-ssl.conf and change <VirtualHost *:443> to <VirtualHost 159.89.173.97:443>. But if you only change that file, you'll run into the same issue again if you try to get a certificate for a different hostname with certbot.

3 Likes

Issue solved after deleting conf file in sites-available

and created file in /etc/httpd/conf.d/
because existing conf are available in that folder.
Thanks, bro.
Thank you very much for your invaluable help.

2 Likes

Oh, that was it? :rofl: Didn't even see that one!

So.. It wasn't actually the whole IP:port thingy? Darn it, I was pretty sure it was!

I've marked your own post as the solution, as apparently the directory was the actual issue and not the IP:port thing I was actually refering to in my post.

2 Likes

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