Urgent certbot does not update due DNS issue

Help
1

My domain is:

I ran this command:

certbot renewal
And
dig @8.8.8.8 acme-v1.letsencrypt.org (from several servers)

It produced this output:

Attempting to renew cert (xxxx) from /etc/letsencrypt/renewal/nwh.c
Xxxx.de.conf produced an unexpected error: ("bad handshake: Error([('SSL ro
utines', 'tls_process_server_certificate', 'certificate verify failed')],)",)
. Skipping.

and

<<>> DiG 9.10.3-P4-Debian <<>> @8.8.8.8 acme-v1.api.letsencrypt.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51764
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;acme-v1.api.letsencrypt.org. IN A

;; AUTHORITY SECTION:
letsencrypt.org. 1800 IN SOA owen.ns.cloudflare.com. dns.c
loudflare.com. 2261477481 10000 2400 604800 3600

;; Query time: 8 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Nov 06 08:05:15 CET 2021
;; MSG SIZE rcvd: 118

My web server is (include version): Apache 2 2 .4.25

The operating system my web server runs on is (include version): debian 9.13

My hosting provider, if applicable, is: hetzner

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): no

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

1 Like
2

Welcome to the Let's Encrypt Community :slightly_smiling_face:

Your certbot version is ancient and ACMEv1 is obsolete. You need to update to an ACMEv2 client.

2 Likes
3

Actually...

Should be capable of using ACMEv2 protocol.
See:
Certbot 0.22.0 Release with ACMEv2 and Wildcard Support - Client dev - Let's Encrypt Community Support (letsencrypt.org)

The problem may lie in that it already issued a cert via ACMEv1 and now may need to be instructed to use ACMEv2.

Not to say that I recommend using such an old version.
Quite the opposite; There are many reasons to keep this and all software up to date.

2 Likes
4

Quite true, @rg305.

Simply changing the server line in the renewal configuration file from https://acme-v01.api.letsencrypt.org/directory to https://acme-v02.api.letsencrypt.org/directory might be sufficient.

2 Likes
5

Although the bad handshake seems to imply that OpenSSL may be having issue too...
Not enough of the LE logs are shown to understand what went wrong.

2 Likes
6

Unfortunately not. as I had the https://acme-v02.api.letsencrypt.org/directory already configured.
And i still assume its not an issue of the certbot but more a DNS issue.
I tried several dns resolver all failed to resolve an ip address for acme-v2

1 Like
7

Please show the outputs of:
curl -Iv https://acme-v02.api.letsencrypt.org/
openssl version

But you only showed ACMEv1 DNS requests.

2 Likes
8

Ah...

DST Root CA X3 expiration complications possibly.

2 Likes
9

I would be surprised if this even responds:

acme-v1.api.letsencrypt.org

I always thought it was only this:

acme-v01.api.letsencrypt.org

2 Likes
10

Change that to v02.

2 Likes
11 
*   Trying 172.65.32.248...
* TCP_NODELAY set
* Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: certificate has expired
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html

openssl: OpenSSL 1.1.1i 8 Dec 2020

# dig @8.8.8.8 acme-v2.api.letsencrypt.org

; <<>> DiG 9.10.3-P4-Debian <<>> @8.8.8.8 acme-v2.api.letsencrypt.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48229
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;acme-v2.api.letsencrypt.org.   IN      A

;; AUTHORITY SECTION:
letsencrypt.org.        1800    IN      SOA     owen.ns.cloudflare.com. dns.cloudflare.com. 2261477481 10000 2400 604800 3600

;; Query time: 9 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Nov 06 08:30:58 CET 2021
;; MSG SIZE  rcvd: 118
1 Like
12

OpenSSL looks good enough.
You may need to update your ca-certificates

2 Likes
13

These have no A records:

acme-v1.api.letsencrypt.org
acme-v2.api.letsencrypt.org
acme-v01.api.letsencrypt.org

This does:

acme-v02.api.letsencrypt.org

2 Likes
14

I think the same with DST Root CA X3 expiration.
How can I resolve this?

1 Like
15

That's where @rg305 is headed. He has been the master of solving such here. :grin:

3 Likes
16
2 Likes
17

acme-v02.api.letsencrypt.org is reachable and seem to work.
Anyway I have updated to certbot 1.21. and it just worked well, too

So it seems that certbot 1.21 does not use the cli.ini located in /etc/letsencrypt/ anymore?
UPDATE: certbot 1.21 uses the cli.ini. And during the installation it has corrected the line

2 Likes
18

https://certbot.eff.org/docs/using.html#configuration-file

2 Likes
19

Anywho... this might also be useful:

But in this case, the acme api doesn't use the expired cert.
[fixing tomorrows problems today - LOL]

3 Likes
20

Be very careful if you keep using cli.ini. I've only ever really found it useful for coordinating docker containers.

2 Likes