Certbot renew error, hostname doesn´t match

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
chat01.segurosdelmagisterio.com

I ran this command:
certbot renew
certbot --force-renewal -d chat01.segurosdelmagisterio.com

It produced this output:
[root@serverXXX letsencrypt]# certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/chat01.segurosdelmagisterio.com.conf

Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Attempting to renew cert (chat01.segurosdelmagisterio.com) from /etc/letsencrypt/renewal/chat01.segurosdelmagisterio.com.conf produced an unexpected error: hostname 'acme-v02.api.letsencrypt.org' doesn't match either of '*.sociedaddesegurosdevida.cr', 'sociedaddesegurosdevida.cr'. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/chat01.segurosdelmagisterio.com/fullchain.pem (failure)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/chat01.segurosdelmagisterio.com/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)

My web server is (include version):
Server version: Apache/2.4.6 (CentOS)
Server built: Nov 5 2018 01:47:09

The operating system my web server runs on is (include version):
CentOS Linux release 7.6.1810 (Core)

My hosting provider, if applicable, is:
N/A, its a local Web Server

I can login to a root shell on my machine (yes or no, or I don't know):
Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
Apache, CentOS, Command Line

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 0.31.0

2

Please never use that option unless you use it correctly. If there is a problem from the Let's Encrypt server side, using --force-renewal won't magically have that problem disappear: Let's Encrypt requires a valid authorization, with or without --force-renewal. This option only has a few fringe uses, and this is not one of them.

That said, could you share the contents of /etc/letsencrypt/renewal/chat01.segurosdelmagisterio.com.conf with us?

And also the contents of certbot certificates?

1 Like
3

Hi Osiris! thanks fir the advise regarding the --force-renewal option!
Here is the /etc/letsencrypt/renewal/chat01.segurosdelmagisterio.com.conf content

renew_before_expiry = 30 days

version = 0.31.0
archive_dir = /etc/letsencrypt/archive/chat01.segurosdelmagisterio.com
cert = /etc/letsencrypt/live/chat01.segurosdelmagisterio.com/cert.pem
privkey = /etc/letsencrypt/live/chat01.segurosdelmagisterio.com/privkey.pem
chain = /etc/letsencrypt/live/chat01.segurosdelmagisterio.com/chain.pem
fullchain = /etc/letsencrypt/live/chat01.segurosdelmagisterio.com/fullchain.pem

Options used in the renewal process

[renewalparams]
authenticator = apache
installer = apache
account = 3d85e81af856809f3c109503291a5de0
server = https://acme-v02.api.letsencrypt.org/directory

its also important to mention, that this server has 2 certificates in place, so it works as:
chat01.segurosdelmagisterio.com and webchat.sociedaddesegurosdevida.cr

also what you mean with " And also the contents of certbot certificates ?"

Thanks in advance
ACH

4

Most users on this Community use the text with the slightly different text font and grey background as a way of saying that you should read that text as a command you should run in a terminal window. I agree it would have been more clear if I'd said:

Please run the following command in a terminal window:

sudo certbot certificates

This way it's more clear :slight_smile:

That said, I don't see anything strange with your renewal configuration file. After reading the error produced by certbot for a third time, I think I understand what's going on: when certbot tries to connect to the hostname acme-v02.api.letsencrypt.org, it connects to a webserver which is presenting an erroneous certificate. Instead of a certificate containing the correct hostname acme-v02.api.letsencrypt.org, it finds a certificate containing *.sociedaddesegurosdevida.cr and sociedaddesegurosdevida.cr. Which is obviously incorrect.

What does the following command show when entered in a terminal window?:

host acme-v02.api.letsencrypt.org
2 Likes
5

Thanks again for the clarifications :slight_smile:

And you are correct, that server has 2 different certificates installed on it, one for
'chat01.segurosdelmagisterio.com' and one for 'webchat.sociedaddesegurosdevida.cr' notice the two diffent domains.

The 2 certificates were working fine! the issue is that the certificate for chat01.segurosdelmagisterio.com expired, and when we tried to renew it, got that conflict error with the certificate containing *.sociedaddesegurosdevida.cr and sociedaddesegurosdevida.cr

Here is the requested info:

[root@xxxxxxx renewal]# sudo certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
OCSP check failed for /etc/letsencrypt/live/chat01.segurosdelmagisterio.com/cert.pem (are we offline?)

Found the following certs:
Certificate Name: chat01.segurosdelmagisterio.com
Domains: chat01.segurosdelmagisterio.com
Expiry Date: 2021-04-04 13:19:51+00:00 (INVALID: EXPIRED)
Certificate Path: /etc/letsencrypt/live/chat01.segurosdelmagisterio.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/chat01.segurosdelmagisterio.com/privkey.pem

[root@xxxxxxxx renewal]# host acme-v02.api.letsencrypt.org
acme-v02.api.letsencrypt.org is an alias for prod.api.letsencrypt.org.
prod.api.letsencrypt.org is an alias for ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com.
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com has address 172.65.32.248
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com has IPv6 address 2606:4700:60:0:f53d:5624:85c7:3a2c

6

Hm, so DNS seems to work correctly, that's not it.. What is the output of:

curl -v https://acme-v02.api.letsencrypt.org/directory
7

[root@xxxxxxx conf]# curl -v https://acme-v02.api.letsencrypt.org/directory

  • About to connect() to acme-v02.api.letsencrypt.org port 443 (#0)
  • Trying 172.65.32.248...
  • Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443 (#0)
  • Initializing NSS with certpath: sql:/etc/pki/nssdb
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt
    CApath: none
  • Server certificate:
  •   subject: CN=*.sociedaddesegurosdevida.cr,OU=Domain Control Validated

  •   start date: Dec 03 13:21:22 2020 GMT

  •   expire date: Jan 04 13:21:22 2022 GMT

  •   common name: *.sociedaddesegurosdevida.cr

  •   issuer: CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O="GoDaddy.com, Inc.",L=Scottsdale,ST=Arizona,C=US
  • NSS error -12276 (SSL_ERROR_BAD_CERT_DOMAIN)
  • Unable to communicate securely with peer: requested domain name does not match the server's certificate.
  • Closing connection 0
    curl: (51) Unable to communicate securely with peer: requested domain name does not match the server's certificate.
8

Now why would a connection to the Let's Encrypt validation servers IP address end up at your own server? That's the certificate behind the hostname sociedaddesegurosdevida.cr..

Do you have some kind of strange routing rules in place that could redirect 172.65.32.248 to a different address?

9

My guess would be some sort of corporate firewall-type thing which tries to intercept outgoing requests (maybe to require accepting some sort of terms & conditions, or giving a warning that it's outside the allowed whitelist of corporate-approved sites, or something like that). But it does seem that your server doesn't actually have access to see the Let's Encrypt servers.

How about running this?

curl --insecure https://acme-v02.api.letsencrypt.org/directory

Which should allow curl to connect and see the body of the page returned by whatever system's blocking it, even though it isn't actually connecting to Let's Encrypt.

10

Hi Petter!
That command: curl --insecure https://acme-v02.api.letsencrypt.org/directory
Didn't show anything

11

What kind of network is this server hosted on? Is there a reason that someone running the network could be blocking or restricting outgoing connections?

1 Like
12

Can you instead run:

curl -v --insecure https://acme-v02.api.letsencrypt.org/directory

That'll expose any redirects or other oddness that might be happening.

1 Like
13

Hi Supermathie

here is the result:

  • About to connect() to acme-v02.api.letsencrypt.org port 443 (#0)
  • Trying 172.65.32.248...
  • Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443 (#0)
  • Initializing NSS with certpath: sql:/etc/pki/nssdb
  • skipping SSL peer certificate verification
  • SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • Server certificate:
  •   subject: CN=*.sociedaddesegurosdevida.cr,OU=Domain Control Validated

  •   start date: Dec 03 13:21:22 2020 GMT

  •   expire date: Jan 04 13:21:22 2022 GMT

  •   common name: *.sociedaddesegurosdevida.cr

  •   issuer: CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O="GoDaddy.com, Inc.",L=Scottsdale,ST=Arizona,C=US

GET /directory HTTP/1.1
User-Agent: curl/7.29.0
Host: acme-v02.api.letsencrypt.org
Accept: /

< HTTP/1.1 302 Moved Temporarily
< Date: Mon, 05 Apr 2021 20:07:53 GMT
< Transfer-Encoding: chunked
< Connection: close
< Pragma: no-cache
< Expires: Fri, 01 Jan 1971 00:00:00 GMT
< Cache-Control: no-cache, must-revalidate
< Server: lighttpd
< Location: https://10.133.0.254:4100/fw_user_login.html?redirect=https://acme-v02.api.letsencrypt.org/directory
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Strict-Transport-Security: max-age=31536000
< Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self'; font-src 'self'; object-src 'self'; media-src 'self'; child-src 'self'
< X-Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self'; font-src 'self'; object-src 'self'; media-src 'self'; child-src 'self'
< X-Webkit-CSP: default-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self'; font-src 'self'; object-src 'self'; media-src 'self'; child-src 'self'
<

  • Closing connection 0
14

Something on your network (a Watchguard firewall?) is intercepting outbound SSL connections and forcing users to sign in.

3 Likes
15

Hi supermathie.

You were right, there was a firewall blocking SSL connections! I guess that was the issue but and the end, we got and installed a new certificate!

Thanks to everyone for all the support!

2 Likes
16

To be fair:

I only identified it :smiley:

2 Likes
17

Yes, everyone's comments and inputs were helpful

Regards

1 Like
18

So, did you disable your firewall (at least for that server or for connecting to Let's Encrypt)? Since otherwise you'll probably run into the same problem in a couple months when it's time to renew.

1 Like
19

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