Can't renew Certificate - zerossl, sslforfree, gethttpsforfree and other browser based clients may not work

Help
21

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.

1 Like
22

No, there haven't been any intentional changes to the CORS policy. We'll investigate. Thanks,

4 Likes
23

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.

3 Likes
24

Ah, thanks. Never checked that.

1 Like
25

Thank you... I've tried everything today. But always blocked by this issue.

26

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!

6 Likes
27

Thanks :slight_smile: 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.

2 Likes
28

Amazing! Let us know when is back please. And thanks!

3 Likes
29

Hi @mhughe29

I’ve edited your title. So users with the same problem are able to find this topic.

6 Likes
30

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.

7 Likes
31

Yup :sweat: 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.

3 Likes
32

The fix is in staging now.

3 Likes
33

sslforfree is working

cert renewed perfectly

Thank you Admin for the quick turnaround. I’ve worked in IT and something like this often would have been postponed by management until maintenance hours. My site cert would have expired by then.

And Thank you to Let’s Encrypt for your site. I appreciate your work.

2 Likes
34

https://gethttpsforfree.com/ is working now too! Great job @cpu

2 Likes
35

The fix is now deployed to both production and staging.

Thanks for the confirmations & your patience while we fixed our regression. :tada:

4 Likes
36

same problem with safari and internet explorer, I tried all except firefox

37

the same here. Also tried to contact through zerossl contact form but no replies yet

38

Hi @Lore,

I think @JuergenAuer's suggestions to try different browsers was from before we realized there was a problem on the Let's Encrypt side. That problem is now fixed and you should be able to use ZeroSSL
again now without errors. Can you retry and let us know if you have a different error?

3 Likes
39

I believe the problem is now resolved - ZeroSSL.com can now retrieve the directory again. But it would be good if the original poster could confirm indeed.

4 Likes
40

Thanks a lot!!! I will be around to know when it is fixed. Many thanks to all!!!