How to update from ACMEv1 to ACMEv2

#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. https://crt.sh/?q=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: glidos.net

I ran this command: /usr/bin/certbot renew

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/intranet.glidos.net.conf

Cert is due for renewal, auto-renewingā€¦
Non-interactive renewal: random delay of 82 seconds
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for imap.glidos.net
http-01 challenge for intranet.glidos.net
http-01 challenge for smtp.glidos.net
Using the webroot path /srv/www/htdocs for all unmatched domains.
Waiting for verificationā€¦
Cleaning up challenges
Running deploy-hook command: /etc/letsencrypt/renewal-hooks/deploy/restart-all
Error output from deploy-hook command restart-all:
AH00558: httpd-prefork: Could not reliably determine the serverā€™s fully qualified domain name, using 10.0.0.5. Set the ā€˜ServerNameā€™ directive globally to suppress this message

new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/intranet.glidos.net/fullchain.pem

Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/intranet.glidos.net/fullchain.pem (success)

My web server is (include version): Apache 2.4.33

The operating system my web server runs on is (include version): Opensuse Leap 15.1

My hosting provider, if applicable, is: N/A

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. Using the command line.
The version of my client is (e.g. output of certbot --version or certbot-auto --version if youā€™re using Certbot): Using a package called python2-certbot. Version 1.0.0

My question:
I thought Iā€™d successfully reconfigured to use ACMEv2, but Iā€™ve just received an automated notice that I recently renewed using ACMEv1.

Files /etc/letsencrypt/cli.ini and /etc/letsencrypt/renew/intranent.glidos.net.conf both contain the line
server = https://acme-v02.api.letsencrypt.org/directory

On the other hand. /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory is a soft link to /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory, and the regr.json below that references uriā€™s beginning https://acme-v01.api

Iā€™m confused. Iā€™m not sure what is configuration and what is automatically generated, and hence what Iā€™m allowed to edit. Possibly some of this is config from an old version and is no longer used.

1 Like
Certbot Client update - ACMEv2
#2

Please show the corresponding renewal file.
/etc/letsencrypt/renewal/ā€¦.conf

2 Likes
I don't know if sudo certbot renew --dry-run uses ACMEv2 API, if it complies with your company's standards, how can I confirm that ACMEv2 API is used
#3

Thanks for the help. Here it is:

renew_before_expiry = 30 days

version = 0.36.0
archive_dir = /etc/letsencrypt/archive/intranet.glidos.net
cert = /etc/letsencrypt/live/intranet.glidos.net/cert.pem
privkey = /etc/letsencrypt/live/intranet.glidos.net/privkey.pem
chain = /etc/letsencrypt/live/intranet.glidos.net/chain.pem
fullchain = /etc/letsencrypt/live/intranet.glidos.net/fullchain.pem

Options used in the renewal process

[renewalparams]
account = 2d90801b4000f9ccf2ecfc7ee2335148
server = https://acme-v02.api.letsencrypt.org/directory
authenticator = webroot
rsa_key_size = 4096
webroot_path = /srv/www/htdocs,
[[webroot_map]]
imap.glidos.net = /srv/www/htdocs
intranet.glidos.net = /srv/www/htdocs
smtp.glidos.net = /srv/www/htdocs

1 Like
#4

That seems to indicate the use of ACMEv2.

Perhaps you could test it with --dry-run
and check the logs for actual v01 or v02 connections.

Note the difference between:

nslookup acme-v01.api.letsencrypt.org
nslookup acme-v02.api.letsencrypt.org

[none - as far as DNS is concerned they are the same location - focus more on the client usage]

2 Likes
#5

Okay, that makes sense. I just tried it, but Iā€™m not sure what Iā€™m looking for. Thereā€™s not a single occurrence of the string ā€œv01ā€. There are many occurrences of ā€œv02ā€, but every one within a uri. Some of those look to be within server replies, which is encouraging, but I know nothing of the differences between the two versions of the protocol, so for me thereā€™s nothing conclusive there. I could post the results here if nothing within them are sensitve (there is an email address, but I could edit that out). Better, is there any indicator of version I can look for?

1 Like
#6

Hi @Glidos

check that log.

If there are v02-orders, all is good.

One v01 - see https://acme-v01.api.letsencrypt.org/directory - then check that domain name.

3 Likes
#7

Okay thanks. It looks like Iā€™m okay.

4 Likes
#8

I eventually found out why I was receiving warnings. I have two servers, only one in operation at any time, the other for installing new versions of the OS and then eventually to become the operational one. I have use for the secondary one at times. If it is left on then it also renews certificates, and it is currently set up to use v1. I just needed to update cron on the secondary server to disable renewal.

4 Likes
#9

hello,
In order to support the ACMEv2 API, I updated cerbot to 0.31.0 and running sudo certbot renew --dry-run results in normal.

The sudo certbot renew --dry-run output:
root@test-A:/# sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/test-oamng.yuanruiteam.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1): acme-staging-v02.api.letsencrypt.org
Renewing an existing certificate

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/test-oamng.yuanruiteam.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

**** DRY RUN: simulating ā€˜certbot renewā€™ close to cert expiry**
**** (The test certificates below have not been saved.)**

Congratulations, all renewals succeeded. The following certs have been renewed:
**** /etc/letsencrypt/live/test-oamng.yuanruiteam.com/fullchain.pem (success)****
****** DRY RUN: simulating ā€˜certbot renewā€™ close to cert expiry****
****** (The test certificates above have not been saved.)****
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The certbot ā€“ version output:
root@test-A:/# certbot --version
certbot 0.31.0

The the corresponding renewal fileļ¼š
root@test-A:/# cat /etc/letsencrypt/renewal/test-oamng.yuanruiteam.com.conf

renew_before_expiry = 30 days

version = 0.22.2
archive_dir = /etc/letsencrypt/archive/test-oamng.yuanruiteam.com
cert = /etc/letsencrypt/live/test-oamng.yuanruiteam.com/cert.pem
privkey = /etc/letsencrypt/live/test-oamng.yuanruiteam.com/privkey.pem
chain = /etc/letsencrypt/live/test-oamng.yuanruiteam.com/chain.pem
fullchain = /etc/letsencrypt/live/test-oamng.yuanruiteam.com/fullchain.pem

# Options used in the renewal process
[renewalparams]
installer = nginx
account = 0c461c24f0639286f5b696e7dfc4ee41
authenticator = nginx

My question is:
I donā€™t know if sudo certbot renew --dry-run uses ACMEv2 API, if it complies with your companyā€™s standards, how can I confirm that ACMEv2 API is used. Thank you very much

1 Like
#10

The answer is:

[--dry-run uses the staging environment which only supports v2]

1 Like
#11

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