getssl: ACME server returned error: 400: "detail": "Error finalizing order :: signature algorithm not supported"

[workdvdh]

Hello,

We use getssl to manage our letsencrypt. It's been working fine up until recently where we get the following error

getssl -u -w /root/.getssl/ ourdomain.org

Registering account
Verify each domain
Verifying scripts.iucr.org
scripts.iucr.org is already validated
Verification completed, obtaining certificate.
Requesting Finalize Link
getssl: ACME server returned error: 400: "detail": "Error finalizing order :: signature algorithm not supported"

I'm currently baffled by this.

This happens with oth V2.46 and V2.45 of getssl

When I turn on DEBUG I see at the failure point

responseHeaders HTTP/1.1 100 Continue^M
^M
HTTP/1.1 400 Bad Request^M
Server: nginx^M
Date: Sat, 24 Sep 2022 13:13:29 GMT^M
Content-Type: application/problem+json^M
Content-Length: 141^M
Connection: keep-alive^M
Boulder-Requester: 6077801^M
Cache-Control: public, max-age=0, no-cache^M
Link: https://acme-v02.api.letsencrypt.org/directory;rel="index"^M
Replay-Nonce: 0101qdasVpiefMlaz78GTG7fdo_rEjbUjDBB5wapJ_TxjXI^M
^M

response { "type": "urn:ietf:params:acme:error:badCSR", "detail": "Error finalizing order :: signature algorithm not supported", "status": 400}

[githubRover]

There was a recent change by Let's Encrypt which no longer supports SHA-1. See this post:
https://community.letsencrypt.org/t/rejecting-sha-1-csrs-and-validation-using-tls-1-0-1-1-urls/175144

If that is not enough for you to resolve this you will probably get better answer if you post about this on that community forum in the Help section

[workdvdh]

Thank you very much for this information. I will look into it.

[jeffsco]

I'm having the problem reported above, as of a few minutes ago. The last time I ran getssl was 2 months ago, and it worked well. Today it's failing exactly as above. I suspect that somebody will need to rewrite getssl to obey the new restrictions at Let's Encrypt. I don't see any configuration parameters that allow me to work around the restrictions. (Granted these things are pretty complicated.)

If anybody knows how to make getssl work against the latest Let's Encrypt, please post here!

[githubRover]

I use getssl v2.41 and got a fresh Let's Encrypt cert today. So, there must be something different about your system. I haven't studied the getssl code to know why it might not work but I encourage you to post on the Let's Encrypt community forum. I am sure they will want to know what oper sys you use, it's version, your version of openssl, and so on.

I doubt very much something since v2.41 changed to break this

[jeffsco]

Thanks, it's very useful to know that getssl is working for you today. I'll have to keep looking.

[githubRover]

I looked at the getssl code a little. I did not follow all the twists and turns.

But, one difference might be that I use
REUSE_PRIVATE_KEY="false"

This causes a fresh private key and a fresh CSR to be created each time

If you use different settings such that you use your own CSR (or reuse a very old one) perhaps that is why your cert request fails. If this is the case, make sure to update the CSR with a newer signature as described by the Let's Encrypt post I linked earlier.

[jeffsco]

Thanks very much for the suggestion. I already tried removing my CSR and regenerating it, but I don't really know how it all works. So maybe I didn't remove quite enough files. I'll try setting REUSE_PRIVATE_KEY=false. Currently this line is commented out in my config file (don't know what the default is). I appreciate the help.

[workdvdh]

Thanks very much for all the replies guys. And thanks githubRover, I put REUSE_PRIVATE_KEY="false" in my main getssl.cfg and the certifcates renewed.

jeffsco I hope this works for you too.

[jeffsco]

I'm still working through my problem.

Could you give the version of your openssl? Here's what mine says:

$ openssl version
OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

(One possibility is that this openssl is too old. It's from only 14 years ago, but still....)

[githubRover]

I am running an RHEL based distro but a later one than yours. My openssl is still receiving security updates even though its version is 1.0.2k-fips Jan 2017

It's a good chance your ancient openssl does not properly handle sha256 signature

Upgrading your openssl is best approach. If not possible, you could maybe create a CSR on a newer system and copy that to the old system and have getssl use that. I'm not sure of mechanics of all that - it is just an idea.

[jeffsco]

Awesome, thanks! My first idea is to build a new openssl on my ancient system. I've done this before, but I don't remember if it actually worked all the way to the end. If that fails I'll try something like what you suggest.

[timkimber]

@githubRover thanks for your help with this - I've just got back from vacation and so have only just been able to respond to this thread.
@jeffsco please let us know if it works, or any error messages that you're getting and I'll try and help

[workdvdh]

hI jeffsco,

I think we had this problem because our letsencrypt stuff was previously done on an old RHEL system so like you our key which was used was using an old algo. We moved it to ubuntu 18 last year but of course the key was still old.

One thing you could try if you have a more modern linux system avaliable (and we had success with before we moved to ubuntu 18) was to NFS mount the old RHEL machine web server "DocumentRoot" on to your newer machine. Then run getssl on your newer machine (with REUSE_PRIVATE_KEY="false" and updated ACL if necessary). It will then generate a new key with a modern algo and write the challenge file back to your legacy machine DocumentRoot. letsencrypt will query you legacy machine as usual and it should work.

[jeffsco]

It's a good idea to run getssl on a more up-to-date system that can remotely access my server. I'm not sure NFS will work for me but there might be other ways to manipulate it remotely. Thanks.

[jeffsco]

Followup: I got a newer OpenSSL installed on my ancient system:

$ openssl version
OpenSSL 1.0.1u  22 Sep 2016

With this newer OpenSSL (and REUSE_PRIVATE_KEY="false"), I was able to renew my certificate!

Thanks everybody for all the help.

[karstenBriksoft]

(temporarily) disabling REUSE_PRIVATE_KEY does indeed resolve the issue. It is not really obvious given the response from the server, that the private keys contain information about the algorithms to use. Some of my websites did update their certificates, others didn't.

Maybe a commandline option could be added to getssl to have a one-time refresh of the private key, so it's not necessary to disable this option, do an update and revert, just to get a fresh key.

[tlhackque]

Actually, if we get that error, getssl should automagically rotate the key.

Funnily enough, there's a pending PR #841) that adds '--new-account-key', which will rotate the key.

It would be interesting to know whether LE accepts the old key for signature required to switch keys...
If it does,, all getssl would have to do is notice the error and re-run itself with that option..