The operating system my web server runs on is (include version):
Ubuntu 14.04
My hosting provider, if applicable, is:
Digital Ocean
I can login to a root shell on my machine (yes or no, or I don’t know):
Yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
No
I had a certificate running on this server before following an online guide for using Certbot with Gitlab. I’m looking at this one right now. I tried doing that and I deleted everything in the live, archive, and renew directories under /etc/letsencrypt and started over completely. I can’t figure out what the problem is.
Your web server is simply not using them. Can you look at what web server you’re using and where it’s getting its certificate configuration from? Remember that “renewal” doesn’t change the validity of the existing certificate at all, but issues a new replacement certificate.
Our intended design for renewal with Certbot is that your web server should be pointed at /etc/letsencrypt/live, and the certificates stored there are updated by the Certbot renewal process. However, if you’ve made a copy of the certificate somewhere else, or incorrectly pointed the web server at /etc/letsencrypt/archive, then renewal won’t automatically change the certificate that the server is serving.
The configuration file for Gitlab is using is to use the certificates in the live directory where there are symlinks to archive. I’ll try looking at any other settings.
The server claims to be nginx in your HTTP Server: header; do you have an nginx reverse proxy or something that’s ultimately where the cert is getting used?
I found this post on Server Fault about the same problem. Disabling the redirect from HTTP to HTTPS, re-configuring Gitlab, then enabling it again fixed the problem. That user says it has to do with HSTS. Is there a way to configure that so getting a new certificate doesn’t need the extra steps? It should be easy to fix with a script if not.
This is a bit of a puzzle because the person who made that suggestion on Server Fault argued as follows:
You're redirecting automatically to https if connecting via http.
This redirect applies to Let's Encrypt as well, so they'll get your invalid, due to the date, cert.
At this point the connection won't be successful, leading to the error shown to you.
Also, you're making use of HSTS. I'm not sure if Let's Encrypt does respect this header, if they've once seen it.
Although this is a technically plausible set of guesses, they happen to be mistaken: the validator does follow the redirect, but it ignores certificate errors when doing so, so the connection would not be unsuccessful for this reason. The validator also ignores HSTS.
Because of that, I don't think the rationale that this person offered for solution actually makes sense. Lots of other people who have HTTP → HTTPS redirects (and/or HSTS) succeed in renewing successfully with --webroot, even with already-expired certificates.
So, I don't immediately know how to account for why this solution worked for each of you.