Closed wteiken closed 10 months ago
I would prefer this to be moved to hook script logic instead of handling it directly inside of dehydrated (especially since this changes behavior which some users might expect). E.g. during your deploy_cert hook launch create your todeploy file and add another function which periodically checks for those files. Ideally the hook script should then also have some error handling logic and not just blindly try redeploying the certificates.
The issue is that at the moment this means that ocsp stapling uses the new cert while the old may still be deployed because from dehydrated’s point of view the new cert is active. So this is not only about the deployment, but also to keep these two aligned. Though admittedly not doing it at all is not necessarily better than doing stapling for the wrong cert.So maybe a clear warning might be in order. Basically don’t put yourself in a position where the deploy_cert can fail itself.On Dec 11, 2023, at 3:05 PM, Lukas Schauer @.***> wrote: I would prefer this to be moved to hook script logic instead of handling it directly inside of dehydrated (especially since this changes behavior which some users might expect). E.g. during your deploy_cert hook launch create your todeploy file and add another function which periodically checks for those files. Ideally the hook script should then also have some error handling logic and not just blindly try redeploying the certificates.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
Move the deploy_cert call hook out of the direct cert generation. This allows a retry of the deploy_cert step if it fails (hook returning non-zero exit code).
Adds a new "todeploy.txt" in the cert dir until cert deployment succeeds.