Certbot-auto certonly -d ... does not renew

Issuance Tech
1

Hello,
I generate my own CSR, with SAN (3 domains now)
There might pop new subdomain once a month or two. Which will update the CSR and regenerate NEW certificate - which is correct.

But, if I use the same CSR - (still 3 same domains), it always issues a new certificate instead of checking for renewal and possibly renew when its close to expiration

Command:
certbot-auto certonly -n --keep --expand --webroot -w /var/www/ -d domain1.com,domain2.com,domain3.com --csr /etc/apache2/cert/csr.csr --fullchain-path /etc/apache2/cert/cert.pem

After few repeated runs, due to the limits it outputs: "Too many certificates already issued…"¨

I would expect something like: “Certificate already issued, nothing has changed, no need for renewal or new certificate”

According to certbot docu, it should for the same subset of domains check for renewal, instead of foruce issuing…

What am I doing wrong? Do I need to include previous certificate for the certbot app to check it?

Thanks,
FidLi

2

to check existing certs, and renew those which need it, just use

certbot renew

by telling it you want to "expand" the existing certificate etc you are in effect telling it to create a new cert.

See User Guide — Certbot 2.7.0.dev0 documentation

3

Well,
I will see about that in 60 days…

But I am not sure, it sees the certificate, since I output certificate in my own file…

The log with result “no renewals attemted”:

2016-12-13 19:29:18,738:DEBUG:certbot.main:Root logging level set at 20
2016-12-13 19:29:18,738:INFO:certbot.main:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2016-12-13 19:29:18,738:DEBUG:certbot.main:certbot version: 0.9.3
2016-12-13 19:29:18,738:DEBUG:certbot.main:Arguments: ['-n']
2016-12-13 19:29:18,738:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#standalone,PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#webroot,PluginEntryPoint#apache,PluginEntryPoint#null)
2016-12-13 19:29:18,739:DEBUG:certbot.renewal:no renewal failures

Also, in the link you provided also mentioned
All of the domains covered by the certificate must be specified in this case in order to renew and replace the old certificate rather than obtaining a new one; don’t forget any www. domains! Specifying a subset of the domains creates a new, separate certificate containing only those domains, rather than replacing the original certificate.) When run with a set of domains corresponding to an existing certificate, the certonly command attempts to renew that one individual certificate.

And:

--keep-until-expiring, --keep, --reinstall
                        If the requested cert matches an existing cert, always
                        keep the existing one until it is due for renewal (for
                        the 'run' subcommand this means reinstall the existing
                        cert) (default: False)
  --expand              If an existing cert covers some subset of the
                        requested names, always expand and replace it with the
                        additional names. (default: False)

which means, it should not issue a new certificate just now (-keep), and --expand should work only on change, unless they call subset also the set itself…

Nevertheless, --keep without --expand did not work either…

4

Does this work when using a CSR? Does using a CSR even generate a renewal configuration? Does certbot even know where the certificates are stored? (Hint: not in the /live/ directory ;))

@fidli: using the --csr is actually quite "bare" in regard of features: many of the features certbot has, aren't usable when using a separate CSR. As I'm not a certbot programmer, I can't tell you which features are and which aren't usable, but as far as I can remember, running the certbot command a second time with the --csr switch will get you a new certificate, period. This, because certbot doesn't "store" information about the issuing as it normally would do.

1 Like
5

@Osiris, your recollection is correct.

@fidli, when you use a CSR, Certbot doesn’t store the certificate in its own database (and might not possess the private key!), so it doesn’t know how or when to renew it. None of the documentation referring to using certonly for renewal contemplates using --csr and indeed that path bypasses all of the renewal-related checking and always issues a new cert.

I think we have to find a way to make this clearer in the documentation (and perhaps in Certbot’s own output – for example, it should possibly be an error to combine --csr with --keep, --expand, or --force-renew at all, as those are all supposed to relate to existing certificate lineages that Certbot knows about, while --csr doesn’t!).

6

So the only way to renew with CSR is to run it “manually” once a 60 days?

7

That’s correct. We should definitely find a way to make this clearer.

(However, you can make your own script or cron job to run it for you if you’re comfortable with shell scripting.)

8

Thanks for pointing me at this thread, and thanks for the clarification. I am running a project to encourage people to adopt DNSSEC+DANE on their E-mail servers, possibly using LE certificates, and this not good news - it makes thing relatively complex, though one can script the renewal process and run it just once every 30-60 days.

Would it be so hard to implement a “managed CSR” or “stable key” mode in Certbot? In a “managed CSR” mode, you would supply the private key and CSR at the first creation of the LE certificate for that name; in a “stable key” mode, you would create certificates as usual, but Certbot would “take a note” not to recreate the private key when renewing. In both modes, Certbot would store everything (including the CSR) in the usual directories, and manage renewals directly with the usual logic, except for starting from the existing CSR / not recreating the private key. So these could just be --options in the creation/renewal command.

And even if you couldn’t do this, just an --option to overwrite existing certificates, rather than writing new files with new names, would already be helpful, avoiding the need to update a symlink or even manually update the configuration in Postfix/whatever server uses the certs.

9

You could use one of the alternate clients many of which allow you to use the existing key ( I know GetSSL, which I wrote, does this by default).

I’m sure certbot will improve in this area though over time :slight_smile:

10

We have a ticket to add a --reuse-key in Certbot. I was going to do this but we have an outside contributor working on the task now; I’ll try to check in on it when I get back from my trip.

You can follow progress on this or add comments at

Thanks to @serverco for the suggestion of software that already provides this feature. I’ll try to mention this myself in #3788.

1 Like
11

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