You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 7, 2022. It is now read-only.
blush testing a different client and running into exactly the same issue of staging not working but prod working... I debugged a bit more on my side and found that it was all my fault.
We run some kind of firewall side blocking which, among other things, is not too happy about requests coming in from certain cloud providers, and it turns out that the letsencrypt staging and production endpoints use totally different providers for their checking - and we blocked the staging ones.
This was a bit weird to see because even when using the staging endpoint I did/do see challenge requests (webroot mode) coming in from the same IPs as production - but obviously there are more requests than that, and the other ones blocked, so bang...
Anyway... case closed for me, and I need to switch to DNS-01 (and a different client apparently) anyway for acmev2/wildcard reasons
I've been using the acme client for several rounds of cert renewals, over the last 9 months, without any issues. I'm using HTTP challenge
Now I notice that I can no longer renew against the staging environment, but the production environment still works as usual.
The error I get, is
(MYDOMAIN): acme: identifier authorization failed
I still see the HTTP challenge in the web server logs, replied to with a 200 status, so that part is working still.
TOS acceptance is fine (checked with whoami, even updated once although it said "yes").
Can anybody reproduce that / sees the same issues? Maybe something changed in letsencrypt staging that the acme client needs to learn?
The text was updated successfully, but these errors were encountered: