mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-13 15:13:33 +01:00
certificate renewal fails with urn:acme:error:malformed #248
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @bjmgeek on GitHub (Sep 2, 2017).
I have dehydrated running in a cron script, so I haven't changed my config in a while. However, it recently stopped working. I ran it manually, and got the following error:
@lukas2511 commented on GitHub (Sep 20, 2017):
I don't think I have ever seen that. Have you tried updating dehydrated?
@bjmgeek commented on GitHub (Sep 26, 2017):
Yes, this was from the git master.
@ludeeus commented on GitHub (Nov 5, 2017):
I'm seeing this to :/
Any soulution to it?
@cpu commented on GitHub (Nov 6, 2017):
@ludeeus Can you provide the full output you're seeing? Ideally with the authorization/challenge URL?
The example from @bjmgeek is too old for me to find in the server-side logs for the Let's Encrypt validation authority.
If I had to guess, I'd say this might be related to a recent (Aug 31st) change to recycle pending authorizations.
@lukas2511 Is there any chance that two threads/instances of Dehydrated could be requesting an authorization, get back the same one, and then trip over each other when one instance POSTs the authorization changing the state from pending->[invalid/valid] before the second instance POSTs the same authorization, receiving the error about it being in a non-pending state?
@lukas2511 commented on GitHub (Nov 6, 2017):
@cpu i don't think this is a threading issue, dehydrated should prevent this and in case it doesn't the variance in latencies is so big that probably around the third run one of the instances would just "win" the race condition
@bjmgeek do you by any chance remember if the issue just went away after around 7 days? that would indicate a problem with the recycled authorizations
maybe for some reason dehydrated doesn't notice the verification is already valid and thinks it's still pending, i'll have a look at how that might be possible...
@cpu commented on GitHub (Nov 6, 2017):
That seems like a more plausible explanation than my threading guesses :-)
@ludeeus commented on GitHub (Nov 7, 2017):
@cpu Tried again now, and it worked...
But it looked the same as @bjmgeek
@bjmgeek commented on GitHub (Nov 7, 2017):
Well, let me try again...
@bjmgeek commented on GitHub (Nov 8, 2017):
I'm still seeing an error, but not the malformed one:
@lukas2511 commented on GitHub (Nov 8, 2017):
@bjmgeek this looks like a completely unrelated issue, which seems to be on your side. maybe it's a problem with the expired certificate and your forced ssl redirect
@bjmgeek commented on GitHub (Nov 9, 2017):
Perhaps. In any case, I'm trying with a dns-01 challenge now.
@lukas2511 commented on GitHub (Feb 11, 2018):
Since there were no more reports of this happening (and the relevant code has been restructured anyway) I consider this issue solved.