Thanks for your reply. Oh I see, I though this zerossl tool was a good option
ACME.v1 is deprecated.
So if such a tool doesn’t update the own ACME-client code, that tool will not longer work.
Ah, thanks, good to know.
PS: But sslforfree supports wildcard certificates. So it must use ACME.v2, that’s required to create a wildcard certificate.
So there is another problem they have to fix.
Looking at this thread and seeing that another web client is failing in the same manner, I believe something might have changed regarding the response or its structure for example. I believe you might want to ask support of apilayer.com in this case (see the announcement I have posted last year).
NB: Please note that ZeroSSL web-cliend uses ACMEv2, not the deprected one (and supports wildcards just fine, practically since they became available).
Thanks for this information. I tried to reach them through contact form in zerossl website but no reply yet. Will contact through apilayer.
Hi all I use this website https://gethttpsforfree.com/ and also is failing.
Actually, this is not about a problem with ZeroSSL or any other web-client specifically. It is that the requests are now denied because of CORS by the look of it:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://acme-v02.api.letsencrypt.org/directory. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing)
@cpu, have there been any changes on the API endpoints side resulting in this block?
Both Zerossl and sslforfree are failing for me as well.
Zerossl gives resource directory error when you click Next
sslforfree gives nonce error and then just spins when renewing or creating a new cert
is this a browser update?
So Chrome / FireFox are checking that now?
Yes! I saw that in the browser console. I don’t know where report it in order to get fixed. I tried to use certbot localy but can’t make it work.
No, there haven’t been any intentional changes to the CORS policy. We’ll investigate. Thanks,
That is always checked by the browsers. Previously that header was in place, with a wildcard as a value, so any origin could pull the API. If that is gone, that effectively disables using the API from the browser.
Ah, thanks. Never checked that.
Thank you… I’ve tried everything today. But always blocked by this issue.
I’ve tracked the problem down to a configuration cleanup that accidentally disabled CORS policy. I’m working on getting a fix deployed now. Apologies for the disruption and thanks for flagging it!
Thanks I have actually even quick-checked boulder repo - that header was still supposed to exist by the look of it (and it’s even included in the tests), so was surprised to see that it is not returned.
Amazing! Let us know when is back please. And thanks!
I’ve edited your title. So users with the same problem are able to find this topic.
We’re working on reverting the problematic change in the staging environment now. That should be done within the next 30 minutes. We’ll do the same in the production environment within the next hour and a half or so. I’ll update this thread as progress happens.
Yup The root cause here was a small configuration tidy-up I made last week: I had spot-checked my work to check the fields weren’t being used but I must have made a mistake and failed to see the
"allowOrigins" configuration was used by the CORS handling code. We also missed this when deploying a matching configuration cleanup change to staging/prod.
We had unit tests for the CORS header behaviour but because the problem was at the level of the web front end process’ configuration and unit tests are performed at a lower layer the regression was missed.
In the process of fixing the example configurations we use for Boulder development/CI I’ve added a small integration test to make sure my fix had the intended effect (and to hopefully guard against the problem in the future).
Thanks again for flagging the problem.
The fix is in staging now.