Reneal on Serverpilot/Digital Ocean Not Secure


#1

Please fill out the fields below so we can help you better.

My domain is:localdigitools.com

I ran this command: ./letsencrypt-auto certonly -a standalone -d localdigitools.com -d www.localdigitools.com -d app.localdigitools.com -d qrpons.localdigitools.com -d ftla.localdigitools.com --keep --renew-by-default

It produced this output:Congratulations

My operating system is (include version):php 5.5-7.0

My web server is (include version):Apache/Nginx

My hosting provider, if applicable, is:digitalocean / serverpilot

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):serverpilot

So I have ran this renewal before (A few times actually) it is always successful as it was in this case, however this time all my domains are unsecure.


#2

It looks like the new certificates haven’t been loaded. A lot depends on how you added the certificates the first time. If you added directly to the configuration and the new certificates saved in the same directory, just reload the http server so it can read the new certificate files.


#3

If I made a mistake and renewed to a different directory can I just move the new certs to the original install folder?


#4

If you’re using certbot and kept the domain list the same, the updated certificates will be in the same directory under /etc/letsencrypt/live. If your server is configured to read the certificate files there, simply re-loading the web service will pick up the new certificate files.

Basically, it comes down to how you set up the certificate originally.


#5

In my original .conf file the directory is different than were the renewal placed the the ssl chain. I tried changing config file to point to new chain location – no results and moving to that original location had no results either. I did the same steps to renew as I did when setting up originally. I log in as serverpilot then su root – change dir to letsencrypt – stop nginx server – run renew command – restart nginx server.

So I dont know I have done this a few times as I added sub domains never had a problem.


#6

What I do not understand was that i renewed on 2/13 but I kept getting renewal notices, so I renewed again and everything “fell” apart.


#7

hi @tpilant

good news - your certificates were issued correctly

https://crt.sh/?q=localdigitools.com

bad news is that your website doesn’t seem to be responding


#8

Yes I figured that when it told me Congratulations your certs … And you are right the bad news my website is not responding. Perhaps that is why I am seeking help in here.


#9

That means it’s likely either the certificates were moved, or when you “renewed”, the domain name list was different.

That would be because you changed the domain list. This counts as a “new” certificate lineage, so you’ll get renewal notices on the old one until it expires.

Diagnosing nginx configuration issues isn’t really a primary focus in this forum, but we can try to help. The first step is seeing if nginx sees any trouble in the configuration. Try running “nginx -t” and post if there are any issues. If it’s good, you’ll just see two lines saying things are okay/successful.


#10

Hi @tpilant,

Is it possible that Serverpilot makes a copy of the certificates when you import or configure them? In that case, that copy wouldn’t be updated by a Certbot renewal, because Certbot will simply update /etc/letsencrypt, not Serverpilot’s copy.

In any case, an important question here would be: when you originally obtained the certificate, what did you do to install or import it? The certonly command wouldn’t have done that for you, so there must have been some other step, whether editing a web server configuration file, or doing something in Serverpilot, or something along those lines. (And potentially an equivalent step will have to be repeated now.)


#11

Thank you for the input. The nginx -t had showed ok. This is probably a serverpilot issue had a different server lose my domains a month ago. And I understand the thinking about the chain however I just added a subdomain to a different domain recently and the certs were placed in the original directory not the chained directory as was done on this domain.

It would be cool if there were a way to just remove and reinstall, I guess I will just tear it down and rebuild.


#12

The certs are being installed to /etc/letsencrypt/live/$domain and then since serverpilot will overwrite the default .conf files I create a file domain.ssl.conf this is placed in the /etc/nginx-sp/vhosts.d and this domain.ssl.conf points to the cert path.


#13

So, I would think the renewal process would have updated the live version and then that would be OK. Do you have a copy of the “Congratulations” output from your certonly --renew-by-default command above indicating where it said the new certificate is located? Is it still the same as your original domain.ssl.conf?


#14

This was the command line to produce the certs ./letsencrypt-auto certonly --standalone -d domain.com


#15

Yes it placed them into a doman directory ftla.localdigitools.com which has been the last domain in the renewal chain.


#16

And when I renew I just add this to the end --keep --renew-by-default


#17

Sorry the original and the path in my localdigitools.ssl.conf points to the /etc/letsencrypt/live/localdigitools.com. I tried changing to point to the ftla.localdigitools.com but that provided no positive results.


#18

I have been using this procedure on this domain since October 2016 without a hitch. So not sure why this does this now.


#19

So my support options are limited with serverpilot since I am on a free accont. I just can not justify spending $120 a year for an SSL cert that is free.


#20

So, if you did your “renewal” omitting any -d for a domain that was covered by the previous certificate (include a www.something), you will get a separate certificate which will be saved to a separate location, not replacing the previous one. Perhaps that’s what’s happened here; now maybe you have two certificate lineages with slightly different coverage and which are located in different places. (You can try ls /etc/letsencrypt/live to see for sure.)

To check the individual domain name coverage and expiry of each certificate, you try something like

for lineage in /etc/letsencrypt/live/*; do
  echo Information for $lineage:
  openssl x509 -in $lineage/cert.pem
  echo
done```