I am reaching out to discuss our long-term strategy for certificate lifecycle management. Given the industry shift toward reduced TLS lifespans—specifically the move toward 90-day (and eventually 47-day) durations—we are looking to modernize our infrastructure to ensure seamless automation. Just to give a head's Up, we are currently using Digicert.
Our primary objective is to implement Cert-Manager for automated certificate issuance and rotation. To help us move forward, could you please provide or clarify the following:
1. Technical Documentation for Cert-Manager
Please share the official documentation or a step-by-step guide for integrating Let's Encrypt with Cert-Manager (specifically using the ACME protocol ). We need to ensure our workflow handles automatic requests and renewals without manual intervention.
Also please help us understand how to smoothly transition from DigiCert to Let's Encrypt without ZERO Downtime.
2. Scaling and SAN Limits
We are currently managing 170+ SANs (Subject Alternative Names) and expect this number to grow as we add new services.
Does Let's Encrypt have specific technical limitations regarding the maximum number of SANs per certificate when using automated protocols?
Are there best practices you recommend for managing high-density SAN certificates via Cert-Manager?
3. Pricing and Licensing
Given our current volume and the high number of SANs, could you provide enlightenment on the costing structure for this automated model? We would like to understand:
If there are specific "unit-based" or "subscription-based" models that favor high-SAN environments.
How the cost scales as we continue to add certificates and SANs throughout the year.
We want to ensure our environment is future-proofed well before the stricter lifespan requirements take effect. I look forward to your guidance on these points.
I'm not sure whether you want to implement a new client called cert-manager or use the existing client of cert-manager with Let's Encrypt, assuming you want the latter:
As documented by Let's Encrypt in the Profiles documentation, by default a certificate can have 100 SANs (classic profile) however you can get as many certificates as you want.
Let's Encrypt does not charge, there are very generous rate limits which are documented at Rate Limits - Let's Encrypt.
While it's not uncommon to have multiple SANs in a single Let's Encrypt certificate (and some software might require this) issuing multiple certificates with fewer SANs is typically preferred.
Now the question arises is how to migrate Digicert to Let's encrypt, without any downtime.
Secondly, can you walk me through how we can achieve this and how we can use it for multiple ingress Classes.
Thirdly, for our Fed K8S clusters, we cannot use wildcard SANs and we have to use FQDN, in case of a new SAN cert, what needed to be done and this number will eventually grows every year.
I'm not familiar with cert-manager so I'm not sure I'll be much more help than the documentation I've linked, however to help myself and others to help you, we need to know:
And, the cert-manager site shown earlier is also a great resource.
All I'd say is handle this migration the same as you would for anything else. Use a small test until you prove the method you develop. And, then roll that out in steps to your others. For larger systems you probably have some test domains for such a purpose anyway.
One quick question, In case I create SAN cert with the same Domain from Let's Encrypt and use it along with DigiCert and once DigiCert SAN cert gets expired, if we remove it, will there be any downtime or this is not a Production level solution.
Just to clarify @Sayantan the responses on this forum are from volunteers who are largely not associated with the cert-manager project. We cannot make informed recommendations regarding your production environment.
If you need commercial support for a certificate management solution you need to speak to a certificate management vendor, or a k8s solution provider with extensive knowledge of cert-manager (which is the most common cert provisioning tool in Kubernetes).
Really, to use cert-manager in production you first need to extensively use it in development and test environments to prove the solution meets your requirements. I would suggest that should be your priority. You shouldn't ask any questions here about cert-manager, you should instead be trawling through the cert-manager documentation and trying it yourself, or getting a consultant to do it for you and document the process.
A "smooth migration" requires that you understand what you have, what you are aiming to move to, and that you have formulated and tested the migration process between the two. It also requires a rollback strategy etc. If you are not in a position to develop, test and implement the migration yourself you need to contract someone who can.
If you have a question specific to Let's Encrypt please let us know.
e.g. Yes, LE certs are limited to 100 SAN names and you should generally try to limit certs to one name or one service (e.g. if a service has 2 names that's ok, if you are stuffing 50 names into a cert it's probably not sustainable and one validation error would prevent the whole cert renewing).
The main challenge for anyone adopting Let's Encrypt etc coming from commercial certs services is that you will need to reliably perform domain validation on each renewal (typically either HTTP domain validation or DNS domain validation).
We want to involve our procurement team to have a discussion with Lets Encrypt sales team as we are having 40 + K8S clusters and we might have to create 1000+ certs real quick as all certs may expire at the same time and we might hit the LE limits as cert renewal will move to 47 day renewal from 2029. It would be really helpful if we can discuss this over a call.
Let's Encrypt doesn't have a "sales team", since there is nothing for sale. If you're looking for handholding and guidance, a commercial CA, or a separate consultant that's familiar with ACME and cert-manager, can probably offer more of what you're looking for. Let's Encrypt can only offer what it's doing at scale for free due to having an extremely small staff and all support handled by a few random volunteers like us who spend time on this forum when we're trying to put off the work we actually need to be doing.
That being said, the rate limits are clearly stated and very generous. Renewals of existing certs don't use the "New Certificates per Registered Domain" limit, and renewals at the time they're recommended to be at through the ARI protocol are specifically exempted from "New Orders per Account" and all other limits. And if you're going to be creating more new certificates for new domains under the "New Certificates per Registered Domain" limit than the 50 per week, you can request a higher limit (though it may take some time to be processed). I doubt you'll need to, even at the kind of volume you're talking about, if you plan your migration to proceed at a reasonable pace, though.
If I were you, I might consider first implementing automation through ACME with your existing CA of DigiCert (or some other commercial CA, if you're leaving them because there's something specifically about DigiCert that you're trying to get away from). They offer plenty of automation tools and support, and that's in theory what you're paying them for. Once you have that working, if you want to migrate from DigiCert to a free CA like Let's Encrypt, you'll probably find it much more straightforward.