No I'm not. But I verified that I'm affected.
Also, even after renewing the certificate, the serial number (as seen by the internet) does not change.
There must be something wrong with Teleport, but I still cannot understand what is it.
Sorry for the noise.
It knows: it shows the path in the log when starting up, and it is correct.
I even went as far as rebooting the server (after simply trying to restart the service, obviously), but nothing helps.
... or maybe it's getting its own separate certificate and it has nothing to do with the one you got with certbot. This would also explain why it was revoked in the tls-alpn-01 great revocation of 2022.
If you want to use certbot, use the second one with the right /etc/letsencrypt/live paths and a --deploy-hook "the_reload_command" on your certbot invocation.
Thank you @9peppe!!
I had configured Teleport since so many months that I did forget the command used.
Fortunately, bash still had it in its history, so I could check that I had actually used the first command.
Fixing it was just a matter of going into the yaml config file and changing from acme: enabled: "yes" to acme: enabled: "no".
After restarting teleport, it started using the certbot certificates (which were already in the config file, but they weren't used)!!
@9peppe certbot always worked as expected renewing the certificate, and that hasn't changed.
Only it was previously ignored.
But thank you for the heads-up!
Cris
I'm asking to check the automated renewal process vs. the user-initiated issuance one. There might be some edge cases in which they differ (main of those, you run other commands before and after calling certbot renew).