fszlin / certes

A client implementation for the Automated Certificate Management Environment (ACME) protocol
MIT License
543 stars 119 forks source link

New order error "Method not allowed" using Certes CLI with Let's Encrypt #206

Closed goldingp closed 4 years ago

goldingp commented 4 years ago

Operating System

Windows 10 Pro version 1909 build 18363.535

Certes CLI Version

C:\>certes --help
certes CLI v1.0.3-release-1052
usage: certes <command> [<args>]

    account    Manage ACME accounts.
    az         Deploy certificates to Microsoft Azure.
    cert       Export certificates.
    order      Manage certificate orders.
    server     Manage ACME servers.

Error Messages

C:\>certes order new <my.domain.name>
Fail to load resource from ''.
urn:ietf:params:acme:error:malformed: Method not allowed

Description

TLDR Bug found in Certes CLI utility. The new order command sends a HTTP GET request, instead of a HTTP POST request, to the ACME server. Only the directory and new nonce resources will accept HTTP GET requests (RFC 8555 section 6.3) https://tools.ietf.org/html/rfc8555#section-6.3


While testing the Certes CLI utility on the Let's Encrypt staging server, I received the error message shown above when trying to create a new order after I set a default server and a default account.

After some investigation and assuming that I was not using the command correctly I found this internet post on the Let's Encrypt community website. It describes deprecating unauthenticated GETs and using POST-as-GET instead (RFC 8555 section 6.3). https://community.letsencrypt.org/t/acme-v2-scheduled-deprecation-of-unauthenticated-resource-gets/74380

I tried the same command on the production server and I got an order back from the server. I think it is because the deprecation date for the production server is not until Nov. 1, 2020 while the deprecation date for the staging server was Dec. 4, 2019.

I didn't find exactly where the HTTP request is sent in the code so I'm not entirely sure that the request method being used is GET but that is my guess and the research I did seems to support that train of thought.

iamsunny commented 4 years ago

@goldingp : have you got any fix for this error yet?

goldingp commented 4 years ago

@iamsunny I have not made a fix for this issue. I just researched the error message I was receiving from the Certes CLI tool and posted a possible reason for receiving the error.

I also looked through the code on github but never forked the repository and looked deeper to actually find where this was happening in the code. I'll give it a go and see what else I can find.

goldingp commented 4 years ago

Looks like there is actually a later release for Certes CLI on github than there is on nuget.org. After building the code from source and running it, the error was no longer occurring when I used Let's Encrypt's staging server.

The new version output from the build is as follows.

C:\>dotnet dotnet-certes.dll --help
certes CLI v1.0.4
usage: certes <command> [<args>]

    account    Manage ACME accounts.
    az         Deploy certificates to Microsoft Azure.
    cert       Export certificates.
    order      Manage certificate orders.
    server     Manage ACME servers.

In the github repo, release 2.3.3 contains an asset for version 1.0.4 of the dotnet-certes Nuget package. The Nuget package itself only has up to version 1.0.3.

I believe @fszlin needs to publish version1.0.4 of the dotnet-certes Nuget package to nuget.org and then we would need to run dotnet tool install --global dotnet-certes --version 1.0.4.

iamsunny commented 4 years ago

awesome, thank you so much @goldingp for looking into it. I will await a push for the new version!

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.