See the README section "Avoiding client HTTPS errors"
@_az What version of Certbot were you using? Was there anything special about the repro? Our own internal blackbox monitoring using Certbot to issue for wildcard names (with a random domain component to avoid authz reuse) against staging didn't catch this but I was able to repro using Lego.
You probably caught the status page chatter but we've identified the problem and fixed it. Based on my own repro experience I suspect accounts that created buggy orders during the outage period will continue to see some 500's if they submit new order requests for matching names with the same ACME account. I recommend rotating the staging ACME account or waiting 7d for the pending orders to expire.
Apologies for the disruption. We'll be digging deeper into the root cause over the next few days.
3 Likes
Just certbot-auto 0.35.1. Nothing remarkable about it, other than I was using --manual in the absence of any authenticator.
One such order was https://acme-staging-v02.api.letsencrypt.org/acme/order/7926433/37752694 , which is currently giving an HTTP 500.
Thanks for the extra detail @_az.
I figured out why our own Certbot blackbox monitoring missed this: the bug that was causing this stuck authorization status behaviour was specific to failed DNS-01 challenges. There was a bug in the RPC that recorded the invalid status with the explanatory error. Our blackbox testing was successfully completing DNS-01 authorizations in staging and didn't tickle the conditions of the bug.
1 Like
Okay, it has been restored from 06-20, and I have been able to launch DNS-01 Challenge normally. Thank you for your timely solution. And related information. The whole process went fairly smoothly.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.