julydate/acmeDeliver

Improvement: Certificate Revocation and Expiration

Closed this issue · 1 comments

I just got an email from Let's Encrypt regarding their update to certificate revocation status.
I'm thinking, if there's ever a need (on the client side) to parse certificate information (such as, expiration date, current revocation status) and check that everytime the script runs in scheduled tasks (cron or systemd, for example).

If it's close to expiry or revoked, the client would request certificate from the server.

Would this be necessary or might be useful?

I'll probably write another PR to address the reload command... By current design it would trigger anytime it's executed. That's not quite ideal (especially when several instances run on different parts of the same day) - Hopefully I can get that done by this weekend.

The current method is that, each time the client runs through a scheduled task, it gets the timestamp when the certificate was last updated from the server. Then compare the last updated timestamp of the client to determine whether it is necessary to pull the latest certificate from the server. So at present, whether the certificate needs to be updated depends on the server's acme.sh script.

So I don't think it is necessary to check the certificate status on the client side. The client only needs to obtain the certificate update status (the timestamp of the server updating the certificate) from the server through a scheduled task.

Of course, the certificate status can also be detected on the client side if it is to reduce the client-server communications frequency. But it doesn't seem to be able to be implemented on the current client. Because the current client requests the server every time it runs.

If you are writing an another client script or a new branch, I would be happy to merge.