Certificate renewal: using the same private key

Help
1

I have web-server (nginx) with LE-certificate up & running, but now I'd like to switch to using the same private key when renewing certificate. Certbot has "--reuse-key" option, so this should be probably used when renewing certificate.

I checked /etc/cron.d/certbot expecting to find there command being run for renewing certificate, but there is note saying:
"This cronjob will NOT be executed if you are running systemd as your init system"

I'm running Debian with systemd, so checked "systemctl show certbot.timer", but it does not show command being run. I also checked /etc/systemd/system/timers.target.wants/certbot.timer, but even there is nothing about command being run.

"systemctl list-timers" shows certbot.timer active (running twice a day) and "systemctl status certbot.service" does not report any problem.

So my question is:

How can I force certbot (from now on) to use the same private key when renewing certificate?

1 Like
2

Hi @Jarry and welcome to the LE community forum :slight_smile:

I think it can be accomplished by putting the setting in the "/etc/letsencrypt/cli.ini" file.

I'm guessing here, add:
reuse-key = True

2 Likes
3

Unless you're using DANE (should you?), why would you reuse the keypair?

(That setting is in cli.ini and in each renewal.conf for each certificate.)

4 Likes
4

Yes, I want to use DANE.

2 Likes
5

You do know that no browser actually supports it and it's only useful for server-to-server smtp over tls, right?

3 Likes
6

AFAIK, there is dane/dnssec validator addon for FF, but I want to use it mainly for mail-server. It is running on the same host as web-server, so I'd like to use the same certificate...

1 Like
7

You can use the same certificate. Or you can use different ones.

The hostname is not the same, usually. (It's the content of the MX record on @)

So you can have a zone that looks like this

@ in A 10.10.10.10
@ in MX 5 mail
www in A 10.10.10.10
mail in A 10.10.10.10
mail in TLSA "etc etc etc"

And you'll have one certificate for example.com and www.example.com used by nginx and without DANE, and one for mail.example.com used by smtp and with DANE.

2 Likes
8

Be aware that reusing certificates across multiple services (protocols) can make you vulnerable to ALPACA-style attacks: https://alpaca-attack.com/

The industry best-practice is to use different hostnames wherever you can (that doesn't mean that you have to use distinct machines for services, just different names).

6 Likes
9

shouldn't underscores be used in cli.ini instead of dashes?

3 Likes
10

@rg305's suggestion is correct, /etc/letsencrypt/cli.ini parameters appear exactly as they do on the command line.

The per-certificate renewal parameters in /etc/letsencrypt/renewal/*.conf feature different syntax and options. The confusion is easy because there is an overlap. A certificate can have reuse_key set in its renewal parameters, but this is different to globally setting --reuse-key in cli.ini.

5 Likes
11

Thanks for the correction, I can't remember the cli.ini conventions I guess :roll_eyes:

I am pretty sure though that -- shouldn't be used in cli.ini?

3 Likes
12

That's one of the reasons I never used cli.ini and I think the renewal config should always be edited with a command like

certbot renew --keep --cert-name ${CERT} [add your options here]

edit: read below, this command doesn't work.

2 Likes
13

But this will work only if certificate expires in less than 30 days, right?

14

No, it will work regardless. It either uses the option immediately or it just saves it for next time.

15

I'm afraid that's not true..

(venv) osiris@erazer certbot $ certbot_test certonly --webroot -w /tmp/ -d example.com

(...)

Successfully received certificate.
Certificate is saved at: /home/osiris/github/certbot/.certbot_test_workspace/conf/live/example.com/fullchain.pem
Key is saved at:         /home/osiris/github/certbot/.certbot_test_workspace/conf/live/example.com/privkey.pem
This certificate expires on 2027-03-13.
These files will be updated when the certificate renews.

(...)

(venv) osiris@erazer certbot $ sha256sum .certbot_test_workspace/conf/renewal/example.com.conf 
896d72107654f74614f4fdadfde555552ad66a66caedbb697f1843628e96f4e0  .certbot_test_workspace/conf/renewal/example.com.conf
(venv) osiris@erazer certbot $ certbot_test renew --keep --cert-name example.com --must-staple

(...)

Processing
/home/osiris/github/certbot/.certbot_test_workspace/conf/renewal/example.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate not yet due for renewal

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The following certificates are not due for renewal yet:
  /home/osiris/github/certbot/.certbot_test_workspace/conf/live/example.com/fullchain.pem expires on 2027-03-13 (skipped)
No renewals were attempted.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(venv) osiris@erazer certbot $ sha256sum .certbot_test_workspace/conf/renewal/example.com.conf 
896d72107654f74614f4fdadfde555552ad66a66caedbb697f1843628e96f4e0  .certbot_test_workspace/conf/renewal/example.com.conf
(venv) osiris@erazer certbot $ grep must_staple .certbot_test_workspace/conf/renewal/example.com.conf 
(venv) osiris@erazer certbot $

No must_staple option added to the renewal configuration file. Only when using --force-renewal as stated in the documentation: User Guide — Certbot 1.24.0 documentation

3 Likes
16

Strange. Maybe --dry-run will work too.

2 Likes
17

I can confirm --force-renewal is required to amend the renewal configuration, if the certificate is not yet due for renewal. The part of documentation that Osiris linked to goes into some detail about this.

6 Likes
18

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