Certbot upgrade to support ACMEv2

Editing the config files comes with a warning :slight_smile:


Modifying any files in /etc/letsencrypt can damage them so Certbot can no longer properly manage its certificates, and we do not recommend doing so.

Looks like it is hitting v2 server.

https://acme-staging-v02.api.letsencrypt.org:443 "GET /acme/authz-v3/33098456 HTTP/1.1" 405 103
Received response:
HTTP 405

Looks like fullchain.pem (failure)

What needs to happen to renew my pem files?

First: Stick with --dry-run until you get it all figured out or you may hit some limits.
Second: Provide as much detail on the command line used and the error message received.
[see tail of /var/log/letsencrypt/letsencrypt.log file - or wherever the LE log file may reside]

Understand --dry-run will do absolutely nothing:

  • nothing when it passes
  • nothing when it fails

The only good you can get from it is found in the logs (and it shouldn’t trip any limits)

root# /usr/bin/certbot --dry-run -v
Tons of data:
One error shown:
Link: https://acme-staging-v02.api.letsencrypt.org/directory;rel=“index”

“type”: “urn:ietf:params:acme:error:malformed”,
“detail”: “Method not allowed”,
“status”: 405
Exiting abnormally:
Traceback (most recent call last):
File “/usr/bin/certbot”, line 11, in
load_entry_point(‘certbot==0.28.0’, ‘console_scripts’, ‘certbot’)()
File “/usr/lib/python3/dist-packages/certbot/main.py”, line 1340, in main
return config.func(config, plugins)
File “/usr/lib/python3/dist-packages/certbot/main.py”, line 1247, in renew
File “/usr/lib/python3/dist-packages/certbot/renewal.py”, line 455, in handle_renewal_request
len(renew_failures), len(parse_failures)))
certbot.errors.Error: 2 renew failure(s), 0 parse failure(s)
2 renew failure(s), 0 parse failure(s)

acme.messages.Error: urn:ietf:params:acme:error:malformed :: The request message was malformed :: Method not allowed

Let me invite some to have a look, that may be more familiar with this error:
@schoen @_az

In the meantime, maybe delete the LE log file (or move it) and create a new one.
Then post that new one here (or a link to it).

Thank You…

Here is a post which mentions this and also mentions staging server and dry run.

Following that thread, can you post all the package files and their version installed?

You need to upgrade Certbot – or, more precisely, one of its component libraries.

I think the current version in stretch-updates works.

Are all of your packages up-to-date?

What does “dpkg -l python3-acme” show?

What does “apt list --upgradeable” show?

1 Like

root@instance-1:/etc/letsencrypt# apt list --upgradeable
Listing… Done
linux-image-amd64/oldstable 4.9+80+deb9u9 amd64 [upgradable from: 4.9+80+deb9u6]
python-acme/oldstable 0.28.0-1~deb9u1 all [upgradable from: 0.10.2-1]
root@instance-1:/etc/letsencrypt# dpkg -l python3-acme” show
dpkg-query: no packages found matching python3-acme”
dpkg-query: no packages found matching show

I did apt-get update earlier to get to version 28. Do I also need to do a apt-get upgrade as well?

So python-acme is definitely out-of-date. But the current certbot package shouldn’t be using it. Older versions might have.

(python-* packages are for Python 2 and python3-* packages are for Python 3. Recent Certbot packages run with Python 3. Older ones probably use Python 2.)

Run it again without the ” show at the end. Just:

dpkg -l python3-acme

apt-get update doesn’t upgrade your packages. It just downloads the new list of packages.

1 Like
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                                        Version                            Architecture                       Description
ii  python3-acme                                                0.28.0-1~deb9u1                    all                                ACME protocol library for Python 3


You need to upgrade to the current version, 0.28.0-1~deb9u2, to resolve the “Method not allowed” issue. (I think.)

It’s in stretch-updates. If the repository is enabled, running apt update and apt upgrade should take care of it.

Unfortunately apt update and apt upgrade did not solve the issue for me. The – dry-run still errors the same. There was some mention that this only affects the dry-run and staging server, but live updates should work. Is that true?

I was trying to keep this GCE instance totally pristine, only using packages from configured repos. Is that an impossible thing to try to do? certbot has been working fine since 2017 …

Did you get any change in:
dpkg -l python3-acme

ii python3-acme 0.28.0-1~deb9u1 all ACME protocol library for Python 3


It sounds like you don’t have stretch-updates enabled.

/etc/apt/sources.list should usually include:

deb http://deb.debian.org/debian stretch-updates main
1 Like

For Information, GCE instance is using these sources.

Will all GCE users be required to update? This is an older instance, so not sure what a new one looks like.

root@instance-1:~# grep ^[^#] /etc/apt/sources.list /etc/apt/sources.list.d/*
/etc/apt/sources.list:deb http://http.debian.net/debian stretch main
/etc/apt/sources.list:deb-src http://http.debian.net/debian stretch main
/etc/apt/sources.list:deb http://security.debian.org/ stretch/updates main
/etc/apt/sources.list:deb-src http://security.debian.org/ stretch/updates main
/etc/apt/sources.list:deb http://ftp.debian.org/debian stretch-backports main
/etc/apt/sources.list.d/google-cloud.list:deb http://packages.cloud.google.com/apt google-compute-engine-stretch-stable main
/etc/apt/sources.list.d/google-cloud.list:deb http://packages.cloud.google.com/apt google-cloud-packages-archive-keyring-stretch main

You are indeed missing stretch-updates.

stretch/updates from Debian Security is not the same.