I see that Lets Encrypt renews its certs at 90 days. The company I am working for mandates that certs are renewed at 24 hours -- no exceptions. Can Lets Encrypt do this?
Thanks!
edit: For clarification, certs can only be valid for 24 hours. New day, new cert.
Are you meaning that the validity of the certificates is only 24 hours, or that just you renew them (that is, creating a new certificate) 24 hours after creating them?
I'd be very surprised at a company that would want either of those and yet would want them to be issued by a publicly trusted CA. I think that you may not be conveying exactly what your requirements are (and perhaps the requirements aren't being accurately conveyed to you by your company).
Hi peeps! I just edited the original post. It's not so much that certs can be renewed at 24 hours, they are only valid for 24 hours. New day, new cert. That's not a misunderstanding, the company/client have been very clear about this.
And it must be a public CA? Because those are hard to find.. I only know Google issues certs with a validity of 1 day, as seen in the comparison above.
Must it only be public? Thats a good question, not sure if its public, private, or root.
Anyways, what led me to Lets Encrypt (one of many rabbit holes) is that we are running a kubernetes cluster (service mesh) and when a new daily cert is issued, we have no choice but to restart the pod. Restarting the pod leads to downtime. I read several blogs thats said Lets Encrypt can refresh the pods with no restarts
Let's Encrypt is a Certificate Authority. It has no controle over your "pod" (whatever that may be). Your "pod" should be able to renew a cert independent of the CA.
That said, Let's Encrypt has rate limits limiting your issuance of certs to 5 duplicates per week, so that's 2 short of 1 daily.
That is not possible with LetsEncrypt. Even if you were to revoke a Certificate, it could take up to 10 days for browsers/clients that utilize CRL lists to recognize it.
As others mentioned, a private CA is the easiest option - but you will have to deploy the private root certificates.
If you need to use a publicly trusted root certificate, you will likely need to use a commercial CA for the certificates - however I do not know of any that support this use case specifically. You may likely need to contract with a commercial CA to set up a subordinate CA under your control.
Although Google give the option to issue 24 hour certificates in their public CA, they recommend not doing so:
By default all certificates issued by Google Trust Services are good for up to 90 days; however, ACME allows for clients to request certificates with different validity periods. Using this capability we allow the requestor to get certificates that are good for as little as 1 day, though we would not recommend using anything less than 3 days due to concerns over clock skew and certificate validity overlap.
Anyway, something seems very off about the requirement coming from the client. Kubernetes + cert-manager or whatever does not involve any restarts for certificate renewals or re-issuances, the ingress just seamlessly gets a new certificate.
None of this is about the certificate authority. The CA isn't renewing your certs - you are (your ACME client is). The schedule of renewals and how you apply the new certificate to your services is entirely up to you.
If you can live with getting 90 day certs and just throwing them away after 24 hours...
And you can change the name on the cert [daily]...
You might be able to use LE [or any other FREE public CA].
Otherwise... I don't think there is a right fit for such a need out there [at least not a cheap one].
Why would anyone need to throwaway a perfectly good cert?
hmm...
They don't trust it any longer.
But if they don't trust it now, they shouldn't have been trusting it at all!
Very strange indeed.