Update lets encrypt certificates

[Bruno]

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.

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 shows certificate for staging.example.com.

on top of that I cannot install my staging site with ssl because staging.example.com is already registered…

Any hint?

Thanks in advance!

[fullyint]

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 to just example.com). This will be addressed in roots/trellis#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.

[Bruno]

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

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.

[Bruno]

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!

[Bruno]

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.

[fullyint]

@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:

@fullyint

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 header for the domain. If you return to http [vs https] … you’ll need to clear the HSTS header using something like this.

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.