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!!!