I received the ACMEv1 deprecation email and need to revisit upgrading my certbot client, reconfiguring an existing working configuration to utilize ACMEv2, and test the operation ( without breakage :-).
I am using a GCE instance Debian 4.9.110-3+deb9u6 and certbot --version 0.28.0 after apt-get update from version 0.10.2 that has been successfully working since at least 2018. Github for certbot lists versions as new as 1.1.0 so I am not sure which is the correct one for least problems.
Does anyone have current instruction steps, links to concise documentation or other information that can help me accomplish this upgrade?
I hope this will also help others who received the “dreaded depreciation” email.
Adding this link mentioning using Let’s Encrypt’s new ACMEv2 server:
“For example, if you would like to use Let’s Encrypt’s new ACMEv2 server, you would add --server https://acme-v02.api.letsencrypt.org/directory to the command line.”
But I don’t see where to permanently set the configuration.
Although I don't understand why you would need to specify the acmev2 server, you can make such changes (globally) in the config file: User Guide — Certbot 2.7.0.dev0 documentation
As for the decision between 0.28.0 and 1.1.0 …
I would stick with the apt package files until they no longer work.
And if/when that happens, I would probably try upgrading the O/S first.
If that is NOT an option then ask your question here ("Which version should I go to?").
Unless that is why you asked it now...
Does your 0.28.0 version still work?
What does the "dreaded deprecation" email say exactly (regarding your 0.28.0 version)?
The documentation is out-of-date 
-- recent versions of Certbot use the ACMEv2 server by default. You don't have to configure anything.
There were a few releases of Certbot that had early ACMEv2 support but didn't prefer it by default. Some or all of those versions also had bugs that mean you have to upgrade anyway.
Edit:
That's a Linux kernel version, not a Debian version -- though the "deb9" part probably means it's Debian 9. Can you run something like "lsb_release -a" to confirm what version of Debian you're using?
This is a GCE instance.
lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.11 (stretch)
Release: 9.11
Codename: stretch
2020-01-15 18:17:02,273:DEBUG:certbot.renewal:no renewal failures
2020-01-16 03:18:54,779:DEBUG:certbot.main:certbot version: 0.28.0
I have an entry in crontab which checks for renewal.
Is there an entry which verifies I am configured properly to hit the ACMEv2 server thus complying with the depreciation email 
Linking the email discussion:
I prefer to use whatever version of certbot is supplied in the GCE distribution if possible. As long as they are reasonably up to date..
I am not sure how to tell if certbot is working. Not sure of the command to test.
See: User Guide — Certbot 2.7.0.dev0 documentation
--dry-run Test "renew" or "certonly" without saving any certificates to disk
Editing the config files comes with a warning
Warning
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]
[edit]
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)
OK…
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
renewal.handle_renewal_request(config)
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?
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
root@instance-1:/etc/letsencrypt#
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.
Desired=Unknown/Install/Remove/Purge/Hold
| 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
root@instance-1:/etc/letsencrypt#
Bingo!
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 …