Problem with renew certificates - The request message was malformed :: Method not allowed

Hi @perrfect

please answer all of the following questions:

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., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

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

Your client may be too old, so update your client.

1 Like

Thank you for your reply.
I’ve renewed my certbot and everything is ok.
Very strange because yesterday i was doing the same and didn’t got the error.

I met the same problem. Very strange. Didn’t happen before and I haven’t solved.

I met the same problem too …

@perrfect @superylc @JeanDuhard please post your Certbot versions. You can check using:

certbot --version

(or if you use certbot-auto or letsencrypt-auto, use that instead of certbot).

There were some recent changes to the Let’s Encrypt staging server, which is what’s used when you use --dry-run. If so, it shouldn’t affect your live (non dry-run) certificates.

1 Like

The issue affects --dry-run functionality for all Certbot versions below 0.32.0 .

There are two issues:

You will need to upgrade to Certbot 0.32.0 or higher to be able to use --dry-run again.

See for instructions on upgrading.

This issue doesn’t affect real certificate renewals. It only affects --dry-run.

For Ubuntu users: update your Certbot to 0.31.0-2 from the PPA, which has had the required fixes.

(Post has been edited to reflect that an upgrade to 0.32.0 is required, not 0.29.0 or 0.31.0).


Same error as well in staging environment when trying to get challenge for authorization:

It start failing today.

{“type”:“urn:ietf:params:acme:error:malformed”,“detail”:“Method not allowed”,“status”:405}"

I have certbot 0.31.0.
sudo certbot renew --dry-run returns error Attempting to renew cert ( from /etc/letsencrypt/renewal/ produced an unexpected error: urn:ietf:params:acme:error:malformed :: The request message was malformed :: Method not allowed. Skipping. * domain replaced.

I’m using certbot 0.31.0
Still have a problem with --dry-run.

error: urn:ietf:params:acme:error:malformed :: The request message was malformed :: Method not allowed. Skipping.
1 Like

@rahnas @JeanDuhard If you have the problem with Certbot 0.31.0, could you please post your Linux distribution and version and which instructions you used to install Certbot?

It is possible that you have a package where the acme module was not upgraded along with the other parts of Certbot.

1 Like

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial

I installed following DO article here:

1 Like

Thanks @rahnas.

Ubuntu Xenial should not have this issue, assuming you installed Certbot from the PPA, following the instructions on . (The DigitalOcean tutorial seems to largely match).

Could you please post the versions of your installed Certbot packages? In particular python3-acme.

dpkg-query -l | grep certbot

If it is not at 0.31.0-2, perhaps try to forcefully upgrade it:

apt update && apt install --only-upgrade python3-acme

Yes, looks like I have it 0.31.0-1+ubuntu16.04.1+certbot+1

Os version :

No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.2 LTS
Release:	18.04
Codename:	bionic

Package installed

ii  certbot                           0.31.0-1+ubuntu18.04.1+certbot+1   all          automatically configure HTTPS using Let's Encrypt
ii  python-certbot-apache             0.31.0-1+ubuntu18.04.1+certbot+1   all          transitional dummy package
ii  python3-acme                      0.31.0-1+ubuntu18.04.1+certbot+1   all          ACME protocol library for Python 3
ii  python3-augeas                    0.5.0-1+ubuntu18.04.1+certbot+1    all          Python3 bindings for Augeas
ii  python3-certbot                   0.31.0-1+ubuntu18.04.1+certbot+1   all          main library for certbot
ii  python3-certbot-apache            0.31.0-1+ubuntu18.04.1+certbot+1   all          Apache plugin for Certbot
ii  python3-future                    0.15.2-4+ubuntu18.04.1+certbot+3   all          Clean single-source support for Python 3 and 2 - Python 3.x
ii  python3-josepy                    1.1.0-2+ubuntu18.04.1+certbot+1    all          JOSE implementation for Python 3.x
ii  python3-parsedatetime             2.4-3+ubuntu18.04.1+certbot+3      all          Python 3 module to parse human-readable date/time expressions
ii  python3-requests-toolbelt         0.8.0-1+ubuntu18.04.1+certbot+1    all          Utility belt for advanced users of python3-requests
ii  python3-zope.component            4.3.0-1+ubuntu18.04.1+certbot+3    all          Zope Component Architecture
ii  python3-zope.hookable             4.0.4-4+ubuntu18.04.1+certbot+1    amd64        Hookable object support

Thanks to @rahnas we identified a second issue, where Certbot sending the wrong Content-Type when it downloads the certificate during a --dry-run. This was fixed in Certbot v0.32.0.

In Ubuntu, make sure you upgrade Certbot to 0.31.0-2 from the PPA, which has the fix backported.

This should not affect any live renewals or real certificates. It only affects --dry-run.

(@cpu did EnforceV2ContentType get enabled today as well?)


I’ve had a site running on a digitalocean droplet with LEssl setup for a while. I’m trying to change domain names for the site, and have created a second certificate for the new domain name.

I’ve got two folders in /etc/letsencrypt/live now, one for each domain.

I’ve got two nginx server blocks, one for each domain, and i’ve got /var/www/domain1/html and /var/www/domain2/html

Creating a cert for the second domain was no problem, but when I run the dry run, I get the error mentioned above on this page:

Attempting to renew cert ( from /etc/letsencrypt/renewal/ produced an unexpected error: urn:ietf:params:acme:error:malformed :: The request message was malformed :: Method not allowed. Skipping.

Attempting to renew cert ( from /etc/letsencrypt/renewal/ produced an unexpected error: urn:ietf:params:acme:error:malformed :: The request message was malformed :: Method not allowed. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/ (failure)
/etc/letsencrypt/live/ (failure)

Any advice on how to solve this would be great. I’m only planning on redirecting all pages from domain1 to domain2, so that might be important info too.

Also the system is ubuntu 16.04 running nginx.

I’m running certbot 0.25.0… any other info, just ask. Thank you!

  • EDIT: Does the answer above this one apply to my situation as well, or is this uniquely because I have two certs?
1 Like

Thanks for digging into the root causes here @_az.

Nope, that one has been enabled in prod since the beginning of April 2018. It was the change we announced in this API announcements post: JWS POST Content-Type Header Enforcement

I suspect the breakage was hidden by the fact that Certbot was using GET requests for the certificate fetch until POST-as-GET became mandatory.


Hi there,
I got the same error using a quite old version of cert-manager (0.4.1 - Aug 2018) in a Kubernetes cluster to generate certificates using issuer “letsencrypt-staging”.
Last Transition Time: 2019-12-05T10:24:48Z
Message: Failed to determine authorizations to obtain: acme: urn:ietf:params:acme:error:malformed: Method not allowed
Reason: ValidateError
Status: False
Type: Ready

If it is linked to thoses changes, that means this cert-manager version is now deprecated for staging uses?
I’ll test with the prod issuer.
But it could mean we’ll have at least to updates all K8s clusters using staging with new cert-manager and adapt all deployments configs to use this new version :thinking:

Yes. You’ll need to upgrade. Also note that without an update this version will also not function correctly with the production API after Nov 1st, 2020.

For what it’s worth we frequently block outdated versions of cert-manager. Older versions have bugs that can result in extraordinary amounts of API traffic being sent to Let’s Encrypt. See: Blocking old cert-manager versions


This problem affects you because your version of Certbot is too old. You’ll need to upgrade it. Having two certs isn’t a problem :slight_smile: