2

I am trying to use Certbot to allow for semi-automated certificate updates. I don't want fully-automated updates to avoid automatic certificate replacements that could interrupt business and ensure that a sentient administrator is available when the update is actually done to handle potentially negative consequences. Therefore I need to be able to find out if a certificate is due for renewal in a separate step from issuing the actual renewal.

How can I find out, quickly and without side-effects, if a named certificate managed by Certbot is due for renewal without triggering the renewal itself?

When I issue the renew command, the actual renewal is instantly triggered.

When I use the renew command with the --dry-run flag, the renewal is not triggered, but my authentication plugin is triggered whether the certificate is due or not because it is simulating the authentication. As I use DNS for authentication, actual updates are issued through dynamic DNS and apart of once again tempering with a live system when there might be no administrator on call, this also takes quite a long time on each check because of the slow update propagation speed that is expected of DNS.

As another option I could imagine using the renew command with the -a and the --dry-run flag to select some kind of no-op authentication plugin that doesn't mess with DNS and doesn't take multiple minutes before I get an answer. Sadly Certbot comes with a no-op installer plugin but not with a no-op authentication plugin. Developing such a no-op authentication plugin seems not to be trivial because the interface for authentication plugins seems to require actual Challenge and ChallengeResponse objects to be returned by the plugin of which I currently have insufficient knowledge.

Are there other ways I missed that could solve my problem? Or is there maybe a no-op authentication plugin available somewhere?

aef
  • 1,745
  • 4
  • 25
  • 43
  • 3
    Why don't you look at the current certificate expiry date with `openssl x509 -noout -enddate -in /path/to/certificate/file.pem`? You could even script it to email you when it gets to a certain point. – garethTheRed Jun 02 '21 at 19:25
  • Certbot doesn't restart the server, it just creates a new certificate when required. Why do you think / when have you found your server restarts? – Tim Jun 02 '21 at 19:32
  • 1
    Restarting the web server isn't needed anyway, unless you have something very unusual. Normal web servers merely need a reload, and unless something is horribly wrong with your overall setup, it is safe to automate this. – Michael Hampton Jun 02 '21 at 19:35
  • I'm aware that it is not automatically restarted by Certbot. But if the certificate is changed, and then something else restarts the service that uses the certificate, the new certificate is suddenly used. That might be even more confusing because it is then even harder to correlate that problems might have been caused by a past certificate update. On the other hand, when the administrator chooses that the time is right, everything most probably should happen automatically, even the service restart, I'd say. – aef Jun 02 '21 at 21:02
  • I changed the wording accordingly. – aef Jun 02 '21 at 21:03
  • If you are that afraid of this minor automation, you probably should not be using certbot, and should also be fixing whatever in the environment would be confused by merely updating a TLS certificate. If such a thing exists, you probably already know what it is. If you don't know, then there likely isn't such a thing and you are worrying over nothing. – Michael Hampton Jun 02 '21 at 21:06
  • What would you recommand instead of Certbot for this approach? Because I sure want to use Let's Encrypt certificates. – aef Jun 02 '21 at 23:02

1 Answers1

1

certbot will renew a certificate if autorenew is enabled in configuration and the cert is revoked, or a certain number of days from expiring. Default 30 days.

Any other certificate monitoring script can also parse revoked and notAfter.

Your attempt at getting certbot to not do its thing seems like a lot of work for little benefit. How else are you going to know if plugins work before doing it for real, if they are never executed?

Consider building your confidence in automation in steps.

  • Script a method to reload services on cert renewal. Could use a graceful reload of a web server in a certbot hook. Could drain load balanced connections off of hosts and restart them.
  • Run certbot interactively on a test domain. Use the same plugins and hooks as you would for real, but on a different zone entirely.
  • Run certbot interactively on a production domain when ops are normally awake. Reserve time on the calendar to fix issues.
  • Run certbot automatically in cron. Consider scheduling for during the day, when ops and their coworkers are awake.

Throughout, you will have the previous certificates saved locally by certbot. Plus the serial numbers saved to public certificate transparency logs.

An advantage to Let's Encrypt is a CA already trusted by many TLS clients. During renew, the subject and the root do not change, only the keys. Making renew a routine operation easy to automate. Unless you do something exotic you have not described, like key pinning, but that is uncommon.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34