# Update lets encrypt certificates

**URL:** https://discourse.roots.io/t/update-lets-encrypt-certificates/7982
**Category:** trellis
**Created:** 2016-10-28T13:38:03Z
**Posts:** 6
**Showing post:** 6 of 6

## Post 6 by @fullyint — 2016-11-01T17:20:26Z

> [@Bruno](#):
>
> I had ssl false in my wordpress\_sites when provisioning the second time but in some strange way the server was still certified.

You mentioned that “http redirects automatically to the secured version.” It was probably an HSTS issue:

> [@Failure to establish connection when provisioning via ansible-playbook server.yml](https://discourse.roots.io/t/failure-to-establish-connection-when-provisioning-via-ansible-playbook-server-yml/6518/28):
>
> Note that if you end up choosing to set ssl `enabled: false` … your browser’s exposure to the letsencrypt setup for that domain will likely have an associated [HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) header for the domain. If you return to http [vs https] … you’ll need to clear the HSTS header using something [like this](http://classically.me/blogs/how-clear-hsts-settings-major-browsers).
> 
> The HSTS header instructs your browser to remember to automatically load your site as https only for some period of time. If your site moves back to http only, the browser obediently won’t load that http version till the original HSTS header has expired, or till it is cleared manually. This is designed to prevent man-in-the-middle attacks that could try to “downgrade” a user’s connection from https to http.

In other words, Trellis and your server were probably obeying your command to turn off LE SSL (when you had ssl `enabled: false` in `wordpress_sites`), but your personal browser never got the message to discontinue the HSTS handling, to stop forwarding http to https. A different browser that never visited the site would not have the HSTS header set and would not have the issue.

---

_[View the full topic](https://discourse.roots.io/t/update-lets-encrypt-certificates/7982)._