mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-13 23:23:32 +01:00
Feature Request: Revoke superseded certificate #179
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @CRCinAU on GitHub (Jan 2, 2017).
It would be a nice idea that if the hook runs and cert gets renewed, that the old certificate that was replaced is revoked.
This would mean if you do the renewal with 30 days left, the previously active cert would be revoked once replaced.
I guess this would be best implemented as either a config option or a --revoke type option.
@lukas2511 commented on GitHub (Jan 9, 2017):
This would result in more load on the Let's Encrypt servers and I don't think it would really do anything good for you. Your certificates and keys should be stored in a secure location anyway, so it wouldn't make much of a difference.
If you really want this you could easily create a hook-script that revokes old certificate files, but I don't think it would be a good idea as a main feature of dehydrated.
Closing this for now, if there are more people out there who want this feel free to comment here, and I may reconsider it.
@throw1008a commented on GitHub (Jan 15, 2020):
Ran across this request. You write "easily create a hook-script that revokes old certificate files".
None of the standard hook.sh routines have the file name of the old certificate, just the newly issued one. So it would be necessary to walk the tree of the certdir... which is basically just re-creating all the code in command_cleanup() routine.
So instead of doing a copy-paste of all that code, why not simply have it that if both AUTO_CLEANUP and (a new) AUTO_REVOKE are both set to "yes", then there is revocation? The code could be dropped in around the 'mv' perhaps?
@txr13 commented on GitHub (Jan 16, 2020):
It's a bad idea in general to do automatic certificate revocation, for several reasons.
1. Delays in deploying the newly-requested certificate. If the new certificate doesn't deploy properly, or if a service cannot be restarted to immediately activate the new certificate, the old certificate is no longer valid. This could cause interruptions in service, and would further prevent users from simply falling back to the old certificate while they troubleshoot the issue.
2. Additional load on the CA's resources and other users. Not only does the CA have to process the revocation request, but the revoked certificate has to be added to the CRL which needs to be made available to all users.
3. The certificate has a limited lifetime anyway. For Let's Encrypt at least, the short lifetime of an automatically-issued certificate is specifically designed to reduce the window of vulnerability. Unless you suspect that your server has been compromised during that certificate's lifetime, you should not need to revoke it. (And if you think your server has been compromised, you probably have lots of other work to do, such as ensuring other certificates haven't been issued in the meantime.)
Dehydrated has the capability for users to write in whatever functionality they want, but it's not a good idea (in my opinion) to supply functionality within the script itself which has an overall negative effect and simply does not have a use case which should be encouraged.
@throw1008a commented on GitHub (Jan 20, 2020):
That's nice, and? I'm fine with the risk of running into that scenario. Auto-revoke would be default-off, so the behaviour for most people would not change.
The main CA for ACME is Let's Encrypt, and they only use OCSP, so there would be no growth of a CRL. Further, per your point (3), any CA that does use a CRL would have it trimmed as certs expire. However, if the load is too great, the CA can rate limit.
You are making assumptions about the risk profiles that people need to worry about. Saying "it's short already, so you shouldn't have to worry" may not meet everyone's needs.
Yes, this functionality can be easily written: but it would basically be a copy-and-paste of the existing command_cleanup() function. Seems kind of redundant IMHO.