How to ensure a smooth transition to Let's Encrypt SSL Cert?


#1

Hello!
I’ve got LAMP running on Ubuntu 14.04 and almost a year ago I installed SSL (TLS 1.2) certificate for my web server, so my site would only run under HTTPS protocol. On October 8 the certificate expires. And from now on I want to install and use Let’s Encrypt. How to get rid of the old cert? I mean, it’s
probably NOT a good idea to use two of them side by side. So what’s the correct order of things? First, to delete the old files? I placed .crt and root_bundle.crt files in /etc/ssl/certs directory and a .key file in /etc/ssl/private directory. Other than physically deleting those files, do I have to run any specific command in the terminal or something? And then to install Let’s Encrypt? New cert from what I understood shouldn’t be put like a file, it’s somehow automatically works. Not the way it was with the old one…
Also in a file /etc/apache2/sites-available/000-default.conf there’re 3 references to my old cert’s files:

SSLCertificateFile /etc/ssl/certs/my_domain.com.crt
SSLCertificateKeyFile /etc/ssl/private/my_domain.com.key
SSLCertificateChainFile /etc/ssl/certs/root_bundle.crt

So what to do with those links? To comment out them? Or update with a new files that would be created by Let’s Encrypt etc.?

In short, too many things are not clear. There’re plenty of tutorials of how to install and use Let’s Encrypt, but I haven’t found even a single one in which in details described how to transition from an old regular cert to Let’s Encrypt cert.


#2

I would start by obtaining a new certificate from Let’s Encrypt (since you say “There’re plenty of tutorials of how to install and use Let’s Encrypt,” I’m not going to repeat the details here … let us know if you want specific info though )

Once you have a new certificate (if you used certbot, running as root, your new certs will be in /etc/letsencrypt/my_domain/live )

  • Backup your /etc/apache2/sites-available/000-default.conf file
  • edit the /etc/apache2/sites-available/000-default.conf file to change

SSLCertificateFile /etc/ssl/certs/my_domain.com.crt
SSLCertificateKeyFile /etc/ssl/private/my_domain.com.key
SSLCertificateChainFile /etc/ssl/certs/root_bundle.crt

to the new cert files …

SSLCertificateFile /etc/letsencrypt/live/my_domain.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/my_domain.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/my_domain.com/chain.pem

  • reload apache

service apache2 reload

  • Test the new cert in your browser.

Any problems, you can go back to your backup of the /etc/apache2/sites-available/000-default.conf file and reload apache


#3

Thanks for your reply!

  1. So physically I don’t have to delete the files that belong to the old cert?
  2. I just disregard that I even already have now a certificate installed and I proceed with a regular procedure to obtain Let’s Encrypt cert AS IF I don’t have anything already installed?
  3. Once I finished with all the Let’s Encrypt instructions, I should be having all the Let’s Encrypt cert files which are necessary in this folder /etc/letsencrypt/my_domain/live
  4. Here it’s not clear to me:
    You wrote in the beginning about this path to the new cert:
    /etc/letsencrypt/my_domain/live

And below you wrote this path:
/etc/letsencrypt/live/my_domain.com/

  1. In any case, I have to replace the old paths (those 3 references) with the new cert files’ paths in the /etc/apache2/sites-available/000-default.conf file. Correct?

Then reload the Apache and test the new cert in my browser.


#4

Correct

My mistake, the 'live" should be first ( I don’t use certbot myself, I use one of the other clients, hence I got the location wrong first time).


#5

You definitely don’t need to delete these old files, although you are free to do so, particularly once you’re happy that Let’s Encrypt is working fine for you.

Certificates are (signed) public documents, you don’t need to keep old copies if you don’t want to, but they can’t do any harm. In fact copies may be retained by anybody, forever, and it needn’t worry you at all. The private key file /etc/ssl/private/my_domain.com.key (and the new private keys for Let’s Encrypt) must never be shown to anyone else though, so you might want to delete old ones once you’re sure you don’t need them.


#6

So what about my question No. 5? And “my_domain.com” in the paths should be in a form of “mydomain.com”? (without an underscore sign)?


#7

It’s whatever your domain name is.

You said in your original post

and so I simply used the same “domain name” that you had. If you provide your real domain name then I can tell you the exact line. I have no idea what the format of your domain name is though.


#8

Thanks a lot!

Actually, everything worked smoothly. I successfully installed Let’s Encrypt cert. Tested it etc. Everything is OK. I deleted my old cert. I don’t think I’m gonna need it.

Now my only question is about automatic renewal. My certbot-auto file belongs to root. So when I created a cronjob in terminal I used this command:

sudo crontab -e

From what I understood (correct me if I’m wrong), I can set a daily cronjob at certain time. Once a day is enough? Let’s say 1:59am, so I typed this:

59 1 * * * /home/myusername/Downloads/cert/certbot-auto renew --quiet --no-self-upgrade

My certbot-auto file is in “cert” folder that I created in my Downloads directory.

And in /var/spool/cron/crontabs/root
it’s where the cronjob was saved.

Then I checked this file

/var/log/cron.log

There I found this line:

Oct 4 01:59:01 myservername CRON[11739]: (root) CMD (/home/myusername/Downloads/cert/certbot-auto renew --quiet --no-self-upgrade)

So that’s it? Everything is fine? If yes, then now what?
Should I do nothing, unless I see any problems with my site being accessed under HTTPS?


#9

Others may have more to suggest, but a key thought is - once certbot does renew what needs to happen? You have an Apache setup. It may be that certbot is taking care of everything. But if you were responsible for changing config files and reloading the apache service the first time, you will need to arrange to do a reload (causing the software to notice the updated certificate file) on future occasions when the renewal happens since certbot isn’t doing that during the renewal. There should be options named hooks where you can add a command to reload apache if you need one.

For peace of mind take a look at the site certificate in a browserwhen the original certificate should only have say 4 weeks left on it. It should have been replaced with the renewed cert by then as certbot aims to give you 30 days breathing room. If you still see the old expiry date you’ve got a couple of weeks still to troubleshoot and us to help you.


#10

Yeah, this is a confusing part. My Let’s Encrypt cert is set to expire on Jan 1, 2017. So when exactly certbot will be renewing it for another 3 months? I mean, theoretically it can be done on Dec. 31, 2016 and it would be valid till around March 31, 2017 OR it can be done on Dec. 15, 2016 and it would be valid till around March 15, 2017. In other words, okay, the cert is valid for 3 months, but after how much time it’s being renewed?

Another concern is a missed cronjob (let’s say if for whatever reason the server is off at the exactly the time when cronjob starts). I set it daily, so my logic says that it’s not a big deal, since it can be done the next day. Right?


#11

If you’re using Certbot, it will try to renew 30 days before expiration and won’t attempt before. You can easily run the certbot renew command on a daily cronjob. This gives you a 30 day buffer in the case that there are network, server, or other issues.

For my needs, I made a little shell script that runs the renew command and then gracefully reloads the services that use the certs so they can pick up any updated ones. It runs every day, and works great.


#12

Thanks for your reply!

Frankly, I still miss the point. If Certbot itself does the renewing 30 days before certificate expiration date, then why do we need cron? OR Certbot doesn’t renew automatically and we (or the cron) have to “trigger” it to do that?

Last, but not least, I still don’t understand the advantage of setting a cronjob on a daily basis. Like why not once a month?


#13

Certbot is the client running on your server. So you need to run it for it to check., and renew the certificate. If you don’t run the client on the server the the certificate can not update itself. (and the cron is what runs (or “triggers” ) certbot )

If you only run the cron once per month, an it fails for some reason ( there is a network error and it can’t reach Let’s Encrypt for example) then your certificate may expire before it tries again. Running it every day, it checks to see if it’s within 30 day’s of renewal and tries to renew it. If successful, then everything is perfect. If it’s not successful it will at least try again the following day, when there are still 29 days left.


#14

Okay, thanks for your explanation!

One more thing though… Let’s say that everything works as it should. Like I said before, my cert expires on Jan 1, 2017. So before Dec 1, 2016 or so Certbot won’t even try to renew. And past that date (sometime in early December 2016) it will try to renew (cron will trigger it). Let’s say, it renews the certificate on Dec 2, 2016. So then the new cert would be valid till around March 1, 2017 So if I check the cert in the browser after Dec 2, 2016, then I should see the new validity dates then? And if I see the old ones, it means that something went wrong? Here I assume that cron will do its job (computer will be on when cronjob is scheduled etc.) to simplify the matters.


#15

Assuming your configuration is correct and reloads apache ( or whatever webserver you are using) then yes, that’s correct.

If you see the old cert, it’s either …
because there was an issue renewing the cert ( the certbot log or cron output should tell you)
or …
the cert has been renewed but your webserver isn’t using it for some reason ( it hasn’t reloaded the config and latest cert )


#16

I checked the certbot log. Seems to be fine. It says:

2016-10-04 17:48:02,862:INFO:certbot.renewal:Cert not yet due for renewal
2016-10-04 17:48:02,862:DEBUG:certbot.renewal:no renewal failures

Couple of questions:

  1. For some reason, the times in the log file seem to be GMT (3 hrs. earlier than here. Here it’s GMT +3)

  2. You mentioned reloading of the webserver after the cert renewal. Does Apache know what to do (to reload itself or whatever is needed to continue functioning under HTTPS with the new cert)?
    In other words, there’s no need for me to reload manually Apache? Or to do that ONLY in case I don’t see a new cert when it should be present?


#17

You’ll need to restart the service, as Apache doesn’t check for updated cert files once it’s running. You can “gracefully” restart it to ensure no major interruptions in connections. For my server, my script just does that unconditionally after running certbot renew.


#18

More specifically, systems tend to distinguish between “reload” and “restart”. What you want here is “reload”, which does not cause the service to stop, even briefly, just there’s an instantaneous switch from the old configuration (in your case, old certificate) to the new one.

You can tell certbot that you want it to run a particular command, such as a reload only when it successfully renews something, by adding a --post-hook parameter to your running of certbot. The command in my example is… just an example, figure out the command you should run to reload the service for yourself first.

--post-hook "/usr/sbin/service apache reload"

“restart” involves stopping and then, re-starting, for a few seconds the service becomes unavailable - but this is the right choice when you have a new version of the software to run instead, it’s basically “turning it off and then on again” but for a single service rather than the whole computer.


#19

I also have this very strange problem. After I successfully installed Let’s Encrypt certificate, I decided to get rid of my old certificate that expires in three days from now. But after I physically removed files that belonged to the old cert, I started to have an issue with receiving mail in Thunderbird Mail. Normally after I open the application, I get a login box. And after the old cert files removal, I stopped getting the login and also stopped receiving mail. Sending was fine. Also the SMTP server was working, since in a web mail access everything worked as usual. Only after I put back files that belonged to the old cert, Thunderbird Mail started to work as usual. I don’t understand the connection between my old cert files that I was using for HTTPS and Apache and Thunderbird Mail, its login and receiving mail in it.


#20

Is it possible the old certificate was used for a mail server, on the same system ?

Certificates on the web are for TLS, a secure transport protocol used also for IMAP, POP, SMTP, and a bunch of other things. So the same certificate securing a web site named site.example.com also works for an IMAP server called site.example.com, for example. Do you run mail servers on that machine ?