Updating my e-mail address with certbot

gauthier · February 3, 2018, 10:12am

I ran:
sudo certbot --nginx -d MY.WEBSITE.COM

I entered an email address.
I agreed to the Terms of Service.
Then, I wanted to exit (I tapped y because I was about to say yes, but instead of pressing enter, I pressed control + C) when I had to answer Yes or No to the question Would you be willing to share your email address with the Electronic Frontier Foundation because I wanted to enter another email address instead of the one I entered.

I thought I could exist and redo that without any complication, but it’s not the case.
What could I do to reset all that?
As I just installed certbot (with sudo apt-get install python-certbot-nginx), I can reinstall it if that makes everything more simple. But I don’t know how to do that and if it will be useful.

Here is what I have in the terminal:

When I first entered this:
ubuntu@ip-XXX-XXX-XXX-XXX:~$ sudo certbot --nginx -d MY.WEBSITE.COM

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): MY.EMAIL@WEBSITE.COM

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel: A

-------------------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
-------------------------------------------------------------------------------
(Y)es/(N)o: Y^CExiting abnormally:
Traceback (most recent call last):
  File "/usr/bin/certbot", line 11, in <module>
    load_entry_point('certbot==0.19.0', 'console_scripts', 'certbot')()
  File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 861, in main
    return config.func(config, plugins)
  File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 690, in run
    le_client = _init_le_client(config, authenticator, installer)
  File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 479, in _init_le_client
    acc, acme = _determine_account(config)
  File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 378, in _determine_account
    config, account_storage, tos_cb=_tos_cb)
  File "/usr/lib/python2.7/dist-packages/certbot/client.py", line 178, in register
    eff.handle_subscription(config)
  File "/usr/lib/python2.7/dist-packages/certbot/eff.py", line 28, in handle_subscription
    config.eff_email = _want_subscription()
  File "/usr/lib/python2.7/dist-packages/certbot/eff.py", line 47, in _want_subscription
    return display.yesno(prompt, default=False)
  File "/usr/lib/python2.7/dist-packages/certbot/display/util.py", line 220, in yesno
    no=_parens_around_char(no_label)))
  File "/usr/lib/python2.7/dist-packages/certbot/display/util.py", line 79, in input_with_timeout
    rlist, _, _ = select.select([sys.stdin], [], [], timeout)
KeyboardInterrupt
Please see the logfiles in /var/log/letsencrypt for more details.

IMPORTANT NOTES:
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

Then when I enter this again:
ubuntu@ip-XXX-XXX-XXX-XXX:~$ sudo certbot --nginx -d MY.WEBSITE.COM
I’ve got this:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.

_az · February 3, 2018, 10:34am

Please fully read IMPORTANT: What you need to know about TLS-SNI validation issues

It contains advice specific to your error message and Certbot version (you are on 0.19 based on your logs).

gauthier · February 3, 2018, 11:08am

It seems like I have the latest version (certbot 0.19.0). I can’t upgrade to version 0.21.
Do you think my problem is related to that?

I just did that again:
ubuntu@ip-XXX-XXX-XXX-XXX:~$ sudo apt-get update

Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease [102 kB]
Hit:2 http://ppa.launchpad.net/certbot/certbot/ubuntu xenial InRelease                                                                              
Hit:3 http://eu-west-3.ec2.archive.ubuntu.com/ubuntu xenial InRelease                                                                               
Hit:4 http://eu-west-3.ec2.archive.ubuntu.com/ubuntu xenial-updates InRelease       
Hit:5 http://eu-west-3.ec2.archive.ubuntu.com/ubuntu xenial-backports InRelease     
Fetched 102 kB in 0s (301 kB/s)                    
Reading package lists... Done

And that too, right after:
ubuntu@ip-XXX-XXX-XXX-XXX:~$ sudo apt-get install python-certbot-nginx

Reading package lists... Done
Building dependency tree       
Reading state information... Done
python-certbot-nginx is already the newest version (0.19.0-1+ubuntu16.04.1+certbot+1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

And, of course, I still have the same issue when I run sudo certbot --nginx -d MY.WEBSITE.COM again. After this:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx

I would like to have this again in order to enter another email address:
Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel):

Instead of:
Obtaining a new certificate

I’m frustrated to have manually exited the initial process with control + C. That turned upside down the installation.

sahsanu · February 3, 2018, 12:11pm

Hi @gauthier

The email address is tied to your account (which was created the first time you issued your first cert). All the certificates issued with that account will use the same email address, so you can't have different email addresses for different certificates, well, you could but you will need to create a new account and it is possible but it requires several manual steps to create a new account, modify your existing renewal confs, etc. so I won't recommend it.

Maybe you don't want this and you only want to change the email address for your account (it will affect to all the certificates issued using this account) so you can use this certbot command:

sudo certbot register --update-registration --email thenew@email.address

Cheers,
sahsanu

gauthier · February 3, 2018, 6:06pm

Thanks. That is one of the things I wanted. So after running this command, I had this (which seems to be fine — I even received an email by Electronic Frontier Foundation to confirm my email address, and of course I confirmed it):

Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
-------------------------------------------------------------------------------
(Y)es/(N)o: y

IMPORTANT NOTES:
 - Your e-mail address was updated to MY.NEW@EMAIL.ADRRESS.

So then, I re-run this:
ubuntu@ip-XXX-XXX-XXX-XXX:~$ sudo certbot --nginx -d MY.WEBSITE.COM
And I still have this:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.

Is that normal? I mean, this log is not due to the fact I exited "abnormally" (when I run that command for the 1st time), but for another reason?

If it's due to another reason, I've got an idea. Let me explain:

My domain name (let's keep calling it WEBSITE.COM to make it simple) is registered at a cloud computing company (which is not AWS, it's OVH if you want to know). This domain name has no SSL certificate, but I made a visible redirection (for WEBSITE.COM and www.WEBSITE.COM) to another domain name (let's call it OTHERWEBSITE.COM) which has a SSL certificate and which is linked to a web hosting on that cloud computing company.

I created the subdomain MY.WEBSITE.COM of my domain WEBSITE.COM. This subdomain is linked to an AWS EC2 instance (I set that with the Address Mapping records "A"). So up to now, I was calling http://MY.WEBSITE.COM in my browser to see (and it is working fine), but now I want to be able to call https://MY.WEBSITE.COM and redirect the HTTP URL to this HTTPS one with the SSL certificate I would like to generate.

Is the log error I have (Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA) is due to the fact my main domain has a redirection?

If it's the case, I anticipated your answer by removing this redirection to OTHERWEBSITE.COM (because I don't really care actually) and I set the Address Mapping records "A" of WEBSITE.COM and www.WEBSITE.COM to my AWS EC2 instance (like MY.WEBSITE.COM already does). And then I run:

ubuntu@ip-XXX-XXX-XXX-XXX:~$ sudo certbot --nginx -d WEBSITE.COM -d www.WEBSITE.COM -d MY.WEBSITE.COM

But I still have:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.

So it seems like what I did was useless. Maybe it's due to the fact the DNS propagation is not effective yet.
Here is the complete log file I have in /var/log/letsencrypt/letsencrypt.log
(WEBSITE.COM is actually proj9ct.fr, in case you're wondering)
https://proj9ct.com/letsencrypt.log

Do you have an idea of what's wrong?

sahsanu · February 3, 2018, 8:06pm

No, the error is explained in the link @_az post in the second comment of this thread.

As a resume, Let's Encrypt uses 3 types of challenges, dns, http and tls, the last one, tls (TLS-SNI-01) has been deprecated due a security bug in shared environments. The certbot plugins (apache and nginx) like the one you are using in your command use only the TLS challenge in versions prior to certbot 0.21.0, from this version these plugins use http challenge instead of deprecated tls.

With your current version 0.19.0 you should use this command instead to have the same results:

sudo certbot --authenticator webroot --installer nginx -w /path/to//root/of/your/domain/ -d MY.WEBSITE.COM

I hope this helps.

Cheers,
sahsanu

gauthier · February 4, 2018, 4:31am

Thanks a lot. That helped.
Your explanation made everything more clear to me. And your command made me go more in the right direction. But I still have a problem.

After using this:
sudo certbot --authenticator webroot --installer nginx -w /home/ubuntu/PATH/ -d MY.WEBSITE.COM

I got this:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer nginx
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for MY.WEBSITE.COM
Using the webroot path /home/ubuntu/PATH for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. MY.WEBSITE.COM (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://MY.WEBSITE.COM/.well-known/acme-challenge/i6-IMnj2nWsg5EFJ-__XNmtlrSHmpJ5lA6cnXDl6jTU: "<!DOCTYPE html>
<html data-n-head-ssr data-n-head="">
  <head>
    <meta data-n-head="true" charset="utf-8"/><meta data-n-head=""

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: MY.WEBSITE.COM
   Type:   unauthorized
   Detail: Invalid response from
   http://proj9ct.fr/.well-known/acme-challenge/i6-IMnj2nWsg5EFJ-__XNmtlrSHmpJ5lA6cnXDl6jTU:
   "<!DOCTYPE html>
   <html data-n-head-ssr data-n-head="">
     <head>
       <meta data-n-head="true" charset="utf-8"/><meta data-n-head=""

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.

I edited the default configuration file using:
sudo nano /etc/nginx/sites-available/default

in order to have this:

server {
    listen 80;
    server_name MY.WEBSITE.COM;
    location / {
        proxy_pass http://127.0.0.1:3030;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_redirect off;
    }
    location ~ /.well-known {
        allow all;
    }
}

(my application uses the port 3030, I put all the other lines because I saw that on a page, but not sure they are really useful — if you have any recommandation about what to keep/modify, don’t hesitate to tell me — I’m not very familiar with all that, but I make my best to understand)

I tried a lot of things until I had this:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer nginx
Obtaining a new certificate
An unexpected error occurred:
There were too many requests of a given type :: Error creating new authz :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/
Please see the logfiles in /var/log/letsencrypt for more details.

It’s no big deal, I can use another domain name I have to keep testing that and finally succeed at some point.
I just realized I didn’t reload Nginx (with sudo systemctl reload nginx) after I add this: location ~ /.well-known { allow all; } to the file, in order to integrate the change. So, I’m waiting for the DNS propagation to be done with the new domain name to test that again.

Do you think I’m on the right way?
or you see something wrong I didn’t consider?

Anyway, I let you know once I’m done with new tests (with the new domain name I set for my app).
And thanks again for your help. I really appreciate.

sahsanu · February 4, 2018, 9:13am

Hi @gauthier,

This error lasts only for 1 hour.

To avoid this error, before trying to issue the certificate you should test that the challenge file can be retrieved from internet using your browser or better, curl command:

Create a test file in your web root, for example:

mkdir -p /home/ubuntu/PATH/.well-known/acme-challenge/
echo "This is a test file" > /home/ubuntu/PATH/.well-known/acme-challenge/test

Now try to reach this file:

curl -ikL http://MY.WEBSITE.COM/.well-known/acme-challenge/test

Till you can't see the right output "This is a test file" you should not try to issue your cert.

An advice, as you are using proxy_pass I will recommend to use another root only for your Let's Encrypt challenges, for example /home/ubuntu/letsencrypt/ so your server block will look like this:

server {
    listen 80;
    server_name MY.WEBSITE.COM;
    location / {
        proxy_pass http://127.0.0.1:3030;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_redirect off;
    }
    location ~ /.well-known {
        allow all;
        default_type "text/plain";
        root /home/ubuntu/letsencrypt;
    }
}

So all requests to MY.WEBSITE.COM, MY.WEBSITE.COM/whatever will follow your proxy_pass rules but all MY.WEBSITE.COM/.well-known/* requests will try to find the files in /home/ubuntu/letsencrypt/.

Once the conf file is modified and nginx restarted/reloaded you should test it:

mkdir -p /home/ubuntu/letsencrypt/.well-known/acme-challenge/
echo "Test using nginx location directive" > /home/ubuntu/letsencrypt/.well-known/acme-challenge/test

curl -ikL http://MY.WEBSITE.COM/.well-known/acme-challenge/test

If you get the right file saying "Test using nginx location directive" you are ready to try to issue the certificate but this time, the webroot to be used must be /home/ubuntu/letsencrypt/ (keep in mind that this is just an example, use the dir you want):

Before the location directive change:

sudo certbot --authenticator webroot --installer nginx -w /home/ubuntu/PATH/ -d MY.WEBSITE.COM

After the location directive change you must change the webroot:

sudo certbot --authenticator webroot --installer nginx -w /home/ubuntu/letsencrypt/ -d MY.WEBSITE.COM

I hope this helps.

Note: there is no need to hide your domain, you already posted the real domain name when pasting the logs

Cheers,
sahsanu

gauthier · February 5, 2018, 4:06am

Oh wow, this is exactly what I needed. I can now use HTTPS with SSL for my domain.

I just want to say a massive thank you! Your help was more than useful. You saved me a lot of time.

At first, I tried to make it with your first method. But as I'm using 2 frameworks in my Node.js app (Feathers as the main one and Nuxt.js as a middleware because I wanted my app to be an universal (or isomorphic) Vue.js app), I realized it wasn't that simple to define the root directory for my domain as we can't curl plain text files from my app. The requests are restricted to HTML and JSON type. I tried to extend that to plain text, but I failed, and anyway it wasn't clean to do that just for my Let’s Encrypt challenges.

Actually, I didn't read your reply entirely at that time. As I'm used to do things step by step (yeah, I can be a bit too "robotic" sometimes), I wanted to validate your 1st method before going forward.

So, after few hours trying to figure that out without finding the solution, I read your recommendation about using another root only for my Let’s Encrypt challenges, and I was like "why I didn't read that before?!". I was dreaming of a such clean solution, in order to extract my Let’s Encrypt challenges from my app. You took such a good initiative to tell me about that. I don't know if I would have figured out by myself that it was possible to do a such thing (as I don't have a lot of experience with Linux and stuff yet)... at least not quickly.

(if you're curious, I used the port 3030 because my app mainly uses sockets, that's why I had to use a proxy_pass rule)

After all that, I just did:

sudo crontab -e

and I pasted this line inside the file to renew my certifiate:
0 */12 * * * perl -e 'sleep int(rand(3600))' && /usr/bin/certbot -q renew

I've read that it's better than this for loading reasons:
15 3 * * * /usr/bin/certbot renew --quiet

Maybe 2 last questions (for my info), if you don't mind:

Is that necessary to put /usr/bin/certbot instead of just certbot as until now I called this command in the terminal with no path?
I also tried if I can call /usr/bin/certbot in the terminal to see if it also works, and it does. Actually I wasn't curious enough to know if there was a specific path for that. Now I know. So I assume it's better to put /usr/bin/certbot in the file in order to avoid any mistake?
I've seen many times online that people renew their SSL certificate every 24h (or less) whereas Let's Encrypt seems to deliver 90-day lifetimes for certificates. So, I assume it would be better to renew it just once a month (like at 3am the 1st of each month, with some randomness during 1 hour) using a such line:
0 3 1 * * * perl -e 'sleep int(rand(3600))' && /usr/bin/certbot -q renew
Don't you think?

Oh, yes, I know but my domain name is a bit weird. I didn't want it to be a bit hard to remember each time. And I like to use capital letters for things we've got to replace, that makes things more visible and easier I think (for example, at the beginning, I was wondering if I had to replace webroot by something else in this line you gave me at some point: sudo certbot --authenticator webroot --installer nginx -w /path/to//root/of/your/domain/ -d MY.WEBSITE.COM because I wasn't familiar yet with certbot), and also more understandable for those who will maybe see this thread in the future because they come across the same kind of issues I had.

sahsanu · February 5, 2018, 6:58pm

Hi @gauthier,

Sorry for the delay, bit busy today.

You installed certbot using the package distributed by Ubuntu so, as far as I know you already have a cron entry, indeed you should have a cron and a timer.

Check if you have this file /etc/cron.d/certbot:

# ls -l /etc/cron.d/certbot
-rw-r--r-- 1 root root 484 Jan 31 03:02 /etc/cron.d/certbot

# cat /etc/cron.d/certbot
# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

This entry only works if you are not using systemd, if you are, then you already have a timer (something similar to cron jobs but for systemd):

# systemctl list-timers
NEXT                         LEFT          LAST                         PASSED    UNIT                         ACTIVATES
Tue 2018-02-06 00:03:28 CET  4h 31min left Mon 2018-02-05 18:57:39 CET  34min ago snapd.refresh.timer          snapd.refresh.service
Tue 2018-02-06 00:04:02 CET  4h 32min left n/a                          n/a       certbot.timer                certbot.service
Tue 2018-02-06 06:15:25 CET  10h left      Mon 2018-02-05 18:57:40 CET  33min ago apt-daily-upgrade.timer      apt-daily-upgrade.service
Tue 2018-02-06 15:38:32 CET  20h left      Mon 2018-02-05 18:57:40 CET  33min ago apt-daily.timer              apt-daily.service
Tue 2018-02-06 19:22:43 CET  23h left      Mon 2018-02-05 19:22:43 CET  8min ago  systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

And you will see the certbot timer which will run twice a day.

I mean, you already have a cron job/systemd timer in your system so, remove the entry you added manually.

Keep in mind that a cron job is not the same as running something using the terminal, the PATH variable could not be the same as the one you are using in your terminal. So, you have two options to be bullet proof, add a PATH variable to your cron job with the right paths to find the executables, or simply use the full path to your executable so writing /usr/bin/certbot could save you some headaches ;).

Trying to renew your certs every 24 hours or twice a day is the right way, keep in mind that certbot renew command only checks if your certs will expire soon (by default in 30 days) so if they are not close to expire (30 days or less) it does absolutely nothing so it is correct to run it twice a day.

Also, right now, when certbot renew your certs you will need to reload your nginx manually, you can add a simple option to your renewal conf file so this reload would be performed by certbot only when it renews your cert.

Edit this file /etc/letsencrypt/renewal/MY.WEBSITE.COM.conf and you will see something like this:

# renew_before_expiry = 30 days
cert = /etc/letsencrypt/live/MY.WEBSITE.COM/cert.pem
privkey = /etc/letsencrypt/live/MY.WEBSITE.COM/privkey.pem
chain = /etc/letsencrypt/live/MY.WEBSITE.COM/chain.pem
fullchain = /etc/letsencrypt/live/MY.WEBSITE.COM/fullchain.pem
version = 0.19.0
archive_dir = /etc/letsencrypt/archive/MY.WEBSITE.COM

# Options and defaults used in the renewal process
[renewalparams]
installer = nginx
authenticator = webroot
rsa_key_size = 2048
account = aaaaaaaaaaaaaaaaaaaaaaaaaaa
post_hook = systemctl reload nginx
[[webroot_map]]
MY.WEBSITE.COM = /home/uibuntu/letsencrypt

Pay attention to post_hook, if it does not exist, create it and add the command to reload nginx, in this case I've put systemctl reload nginx but maybe you want to use service nginx reload, save the conf file and you are done.

If you don't want to modify the conf file manually, next time you want to issue a certificate add the --post-hook 'systemctl reload nginx' option to your certbot command:

sudo certbot --authenticator webroot --installer nginx -w /path/to//root/of/your/domain/ -d MY.WEBSITE.COM --post-hook 'systemctl reload nginx'

There are another option like use your own script and copy it to /etc/letsencrypt/renewal-hooks/post/and this script will be executed automatically when a certificate is renewed... there are a lot of options ;).

I hope this helps.

Cordialement,
sahsanu

gauthier · February 5, 2018, 10:50pm

Hola @sahsanu,
Cool to hear from you again!
Don't worry, it's totally fine. There's no emergency

Yes, I've got this file with the same content.

Yes, when I connected for the 1st time to my AWS EC2 instance, I did this:

sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install nginx -y
sudo systemctl start nginx
sudo systemctl enable nginx

So I'm using systemd like you, and also, each time I reload Nginx, I run:
sudo systemctl reload nginx.

And yes I've got this (it's similar to yours, which is reassuring):

# systemctl list-timers

NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES
Tue 2018-02-06 00:56:08 UTC  5h 1min left  Mon 2018-02-05 12:33:41 UTC  7h ago       certbot.timer                certbot.service
Tue 2018-02-06 01:38:29 UTC  5h 44min left Mon 2018-02-05 15:18:31 UTC  4h 35min ago apt-daily.timer              apt-daily.service
Tue 2018-02-06 06:22:05 UTC  10h left      Mon 2018-02-05 06:22:31 UTC  13h ago      apt-daily-upgrade.timer      apt-daily-upgrade.service
Tue 2018-02-06 10:59:06 UTC  15h left      Mon 2018-02-05 10:59:06 UTC  8h ago       systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2018-02-12 04:40:10 UTC  6 days left   Mon 2018-02-05 02:12:41 UTC  17h ago      snapd.refresh.timer          snapd.refresh.service

5 timers listed.

OK, I just did it running again
sudo crontab -e
and adding a # at the beginning of the line:
0 */12 * * * perl -e ‘sleep int(rand(3600))’ && /usr/bin/certbot -q renew
to comment it (It can be a good reminder for the future to keep it that way, I think).
Is it something to do after the 1st time we see the line with certbot.service appear in this list of timers (in order to execute it once and add it automatically to the timers)?

And what if I want to delete an existing timer? Should I remove the related line in the /etc/cron.d/certbot file? or it's somewhere else that the timer (related to systemd) is defined?

I assume it's better to edit directly the /etc/cron.d/certbot file than running sudo crontab -e if we are using systemd. I got it right?

Yes, I keep it like that. It's no big deal. Hehe

In this case, it's better to just check it once a day at like 3am in order not to disturb any (European) user navigating at the moment Nginx reloads (if it's in the middle of the day, like at noon). I noticed that Nginx reloads very fast, but maybe it can have a negative impact on the navigation as my app doesn't load any other page after the 1st access to the site (everything is made with Javascript and sockets then). Don't you think?

I have the same thing for the 1st part, but the 2nd one (for the options) is a bit different, I've got this:

# Options used in the renewal process
[renewalparams]
authenticator = webroot
installer = nginx
account = 1234567890ABCDEFGHIJKLMNOPQRSTUV
webroot_path = /home/ubuntu/letsencrypt,
[[webroot_map]]
MY.WEBSITE.COM = /home/ubuntu/letsencrypt

So I have this:
webroot_path = /home/ubuntu/letsencrypt,

but not these 2 lines:
rsa_key_size = 2048
post_hook = systemctl reload nginx

I assume I should just add
post_hook = systemctl reload nginx
after
account = 1234567890ABCDEFGHIJKLMNOPQRSTUV
(is the order important? I'm wondering because there's a , at the end of the webroot_path line),
and keep things like it was, without having:

to remove webroot_path = /home/ubuntu/letsencrypt,
and to add rsa_key_size = 2048 (this line seems to be useless as ssllabs website already reports for my app an A+ overall rating, mentioning "Certificate #1: RSA 2048 bits (SHA256withRSA)": SSL Server Test: app.proj6ct.com (Powered by Qualys SSL Labs))

And thanks for the other options. I think this one (above) is fine, but for another AWS EC2 instance (if I have to create another one someday), I'll use this command you mentioned:

sudo certbot --authenticator webroot --installer nginx -w /path/to//root/of/your/domain/ -d MY.WEBSITE.COM --post-hook 'systemctl reload nginx'

And thanks again for the explanations you gave me.

Amicalement

PS: "Cordialement" in french is like "Regards" in english, so more formal than "Cheers". I would translate "Cheers" more like "Amicalement" in french.

sahsanu · February 5, 2018, 11:38pm

Hi @gauthier,

You don't have to do anything, the timer is working fine but maybe I don't get what yout mean.

I wrote a post regarding this some time ago Cerbot cron job? - #5 by sahsanu if you want to stop the timer take a look to this post Can't renew cert cause of rateLimited - #7 by sahsanu

In your case, /etc/cron.d/certbot is executed but does nothing because you are using systemd. I explain this in the first link I posted above.

You shouldn't have issues https://stackoverflow.com/questions/43088363/how-nginx-reload-work-why-it-is-zero-downtime but it is worth to check it by yourself.

It was just an example, you don't need the rsa_key_size nor remove anything, just add

post_hook = systemctl reload nginx

after the account and you will be good ;).

As I said, you don't need to remove anything nor add anything else but the post_hook.

I've taken note of this, merci.

Amicalement,
sahsanu

gauthier · February 6, 2018, 3:30pm

Actually, I wasn't talking about my own case (because obviously, the certbot.service already executed once), but more in a general way, like for a certificate about another domain. Anyway, I assume you say everything about that in the posts you mentioned. I'm going to read them, I'm sure that I'll learn things.

Yeah, the best would be to check. But maybe I won't be available at the moment Nginx reload. And anyway, it will be for very rare cases. I assume that if people notice something wrong (because they were on my app few seconds before the reload), they will just refresh the page thinking it was just a browser issue. Moreover, my app is not supposed to be seen by a lot of people.

Also, I was thinking about something else:
I think that if I want to make sure to avoid any issue, I'd do things in a different way, like: having 2 identical instances of the app and each of them point to the same database instance (in order not to have 2 databases). So just 1 instance of my app is used, but when I have to renew my certificate for it, I just renew the certificate of the other instance and then I change the DNS of my domain to this other instance. So the certificate of the 1st instance stays valid during the transition. So if the DNS propagation is effective for a user during the time he is using the app, it's no big deal. But maybe renewing the certificate of the 2nd instance disables the certificate of the 1st one as they are sharing the same domain, so the problem might stay the same in the end...
Do you get the idea? Have you something to say about that?
I think I won't enter into such complicated processes for so little improvement of the user experience (maybe no user will experience that simply because nobody will use the app at that moment), but it's always interesting to wonder how to do things in order to make each transition transparent for users. We were talking about certificate renewal, but we can also consider any application update (as we talk more and more about continuous deployment nowadays).

But thinking about that made me think about something else. Instead of calling certbot -q renew in the /etc/cron.d/certbot file through this line:
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew
Can we just call that without expecting Let's Encrypt to renew the certificate if it's time to do it, but just make the system send us an email or something (like at least writing something in a plain text file in the directory /home/ubuntu/letsencrypt/.well-known — let's call this file NOTIFICATION so we can check it regularly in a browser directly with the URL https://MY.WEBSITE.COM/.well-known/NOTIFICATION) in order to be noticed about that and make the renewal manually or something?
(I think I won't go for that, but I'm curious to know if we can do a such thing through the certbot command)

Yep. That's what I thought. I asked just in case.

I don't know if I should say thanks all the time, but it's cool to deal with somebody like you. I learn a lot. It's more efficient than the official documentation.

sahsanu · February 6, 2018, 5:01pm

Hi @gauthier,

certbot renew will renew all the certs you issued not just one.... and it will renew the cert if it os close to expire, I mean, you have 4 certificates issed for different domains and 1 expires in less than 30 days but the other 3 will expire in 70 days, certbot renew will check if the cetificates and going to expire and in this case it will only will try to renew 1 of them. So, there is no need to create a new cron job/systemd time for every new issued cert.

There is no need to wait till certbot tries to renew of your cert ;), you can reload nginx when you want and check yourself if you have any issue when connected to your app, but as I said, you should notice nothing, it should be a transparent process to your users.

gauthier:

Also, I was thinking about something else:

I think that if I want to make sure to avoid any issue, I’d do things in a different way, like: having 2 identical instances of the app and each of them point to the same database instance (in order not to have 2 databases). So just 1 instance of my app is used, but when I have to renew my certificate for it, I just renew the certificate of the other instance and then I change the DNS of my domain to this other instance. So the certificate of the 1st instance stays valid during the transition. So if the DNS propagation is effective for a user during the time he is using the app, it’s no big deal. But maybe renewing the certificate of the 2nd instance disables the certificate of the 1st one as they are sharing the same domain, so the problem might stay the same in the end…

Do you get the idea? Have you something to say about that?

Yes, don't do that, keep things simple ;).

You could use your own script to check if one of your certs is close to expire, no need to use certbot, indeed certbot doesn't have that option, at least not as you want but you can use a free service like https://letsmonitor.org/, you add your domains and it will check if the certs will expire soon and will send you an email, an sms.... take a look because maybe it is interesting to you.

There is no need to say Thank you in every post but Thank YOU for your kind words ;).

Amicalement,
sahsanu

gauthier · February 6, 2018, 5:43pm

You’re welcome!
I think I have no more question.
I just had a quick look at https://letsmonitor.org/. Interesting service. I’ll certainly try it later. I think I now need to focus more on my app itself (like adding features, content and stuff) as I already have a good setting of my server environment, thanks to you.

So, one last thank for all your help!

Amicalement,
Gauthier

system · March 8, 2018, 5:43pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Certbot created certificate with wrong common name Help	16	4986	March 27, 2018
None of the preferred challenges are supported by the selected plugin Help	3	3303	October 14, 2021
Site not responding after adding certbot Help	23	2409	August 5, 2021
Certbot - Failed authorization procedure Help	2	630	June 12, 2022
Update my email address, effect? Help	5	2869	August 3, 2017

Updating my e-mail address with certbot

Related topics