Caddy vs inotify — 3

Help
1

This is a continuation of my previous topics on this matter: Caddy vs inotify and Caddy vs inotify — 2

I’m using Caddy for obtaining certificates for all domains I use, and I’m monitoring /var/lib/caddy/certificates/acme-v02.api.letsencrypt.org-directory/example.com/example.com.json file via the systemd.path mechanism to trigger actions on a domain certificate renewal for non-Caddy daemons:

# /etc/systemd/system/tls@.path
[Unit]
Description=Caddy TLS hook - %i
Before=caddy.service

[Path]
PathChanged=/var/lib/caddy/certificates/acme-v02.api.letsencrypt.org-directory/%i/%i.json

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/tls@.service
[Unit]
Description=Caddy TLS hook - %i
AssertPathExists=/var/lib/caddy/certificates/acme-v02.api.letsencrypt.org-directory/%i/%i.crt
AssertPathExists=/var/lib/caddy/certificates/acme-v02.api.letsencrypt.org-directory/%i/%i.key

[Service]
Type=oneshot
Environment="TLS_DOMAIN=%i" "TLS_CERT=/var/lib/caddy/certificates/acme-v02.api.letsencrypt.org-directory/%i/%i.crt" "TLS_KEY=/var/lib/caddy/certificates/acme-v02.api.letsencrypt.org-directory/%i/%i.key"
ExecStart=/var/lib/caddy/tls-hooks/%i

After a recent Caddy upgrade, 2.7.6-1 -> 2.8.4-1, I’ve noticed that the .json file is updated every day (?) because there’s new piece of info in it, renewal_info, which is, as I think, a consequence of this change.

This means the .path unit is now triggered much more often than it should be. So I have to watch either .crt or .key file instead.

The question is which one? Is it .crt that gets updated after .key, or it is .key that gets updated after .crt? Is .key updated each time .crt is updated or only on some occasions? It is not clear from the file timestamps as they seem to be identical, and I was unable to find this information in the code.

Thank you.

2

A better approach would be to use events to follow when certificate renewal happens:

I think the key is refreshed on every renewal to avoid the footgun that is key pinning. But I’m not sure which one is written first between the two, so it would be a race if you followed the wrong one.

According to this bit of code, the key is written, then the cert, then the JSON file (meta). So in theory following the cert should be correct (and the already-written key should match it).

But like I said, I recommend using events instead.

1 Like
3

Thank you for your reply. I’ll go with .crt then.

The events module looks nice, but ATM it still requires that external exec piece which is not something I’d like to deal with now.

4

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