# 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 ## Post 1 by @Bruno — 2016-10-28T13:38:03Z Hi! I’m just deploying one production website and got a certificate issue. My staging version had a valid certificate and all went smooth, now I moved my staging version to another server and deployed my production version on the server where staging was before. I ran into an issue with letsencrypt challenge but could easily resolve it with [this thread](https://discourse.roots.io/t/letsencrypt-acme-challenge-error/6295/23). Now my site is live but i get a broken certificate warning in the browser because the certificate the browser sees ist from staging. example: [example.com](http://example.com) shows certificate for [staging.example.com](http://staging.example.com). on top of that I cannot install my staging site with ssl because [staging.example.com](http://staging.example.com) is already registered… Any hint? Thanks in advance! --- ## Post 2 by @fullyint — 2016-10-28T18:14:32Z **Production** Trellis Let’s Encrypt does not yet handle changes to the domains in the certs (e.g., changing a cert from [staging.example.com](http://staging.example.com) to just [example.com](http://example.com)). This will be addressed in [roots/trellis#630](https://github.com/roots/trellis/pull/630) or some variant. In the meantime, you could SSH in to the remote and - delete the CSRs in `/var/lib/letsencrypt/csrs` - delete the certs in `/etc/nginx/ssl/letsencrypt` - run `ansible-playbook server.yml -e env=production --tags letsencrypt` (or you could rebuild the production server completely to wipe out the files above) **Staging** After completing the steps above for production (hopefully they work), try the staging again. If this new server for staging already had some Trellis Let’s Encrypt stuff on it, you may need to delete the certs and CRS on this server too. You’ve changed the server and IP for your staging site, so be sure you’ve updated DNS with the new IP. If trouble continues, please share some verbose log output of the problem by using `-vvvv`: ``` ansible-playbook server.yml -e env=staging --tags letsencrypt -vvvv ``` * * * > [@Bruno](#): > > My staging version had a valid certificate and all went smooth, now I moved my staging version to another server and deployed my production version on the server where staging was before It’s great that you’re using a staging site to test. As a process comment, once staging looks good, I would generally create the production site on a new server, rather than transform the staging server into production. I think of staging not as testing/proving a server, but testing/proving my configs, Trellis playbooks, project code, etc. So, it’s not this particular server (staging) that I trust and must stick with, but the configs and code. So, I’d much prefer a new fresh untampered with server to host my tested and proven code for production. Maybe you usually put your production sites on fresh servers but this current project required a different approach. --- ## Post 3 by @Bruno — 2016-10-28T20:08:48Z Hi @fullyint! Thanks for your response! I ended up just nuking my production server and installing everything new. The problem with staging was a bad ip address, so thats going to be under control soon :wink: Usually I use the the same (separate) servers for staging and production from the beginning, but this time I didn’t got the staging machine on time and started developing staging on the production maschine. Not to repeat ever again! Thanks again. --- ## Post 4 by @Bruno — 2016-11-01T08:06:59Z I’ll follow up here since it’s related to the first issue. my staging site is provisioned and deployed but I cant access it with https and http redirects automatically to the secured version. connection refused. After talking to the DO support it seems that my port 443 is closed for some weird reason and I don’t know how to oepn it. Any ideas? Help is more than appreciated! --- ## Post 5 by @Bruno — 2016-11-01T09:55:18Z Ok problem found. The door was closed because I had ssl false in my wordpress\_sites when provisioning the second time but in some strange way the server was still certified. Provisioning the site again wth ssl true made it work again. --- ## 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.