We need a better solution for managing our SSL certificate lifecycle (issuance, renewal, deployment) automatically.

Yes. I’d move away from treating certificates as manually managed artifacts and make the certificate lifecycle declarative and policy-driven.

Recommended architecture

For a Kubernetes-heavy environment, my default choice would be cert-manager as the lifecycle controller:

                 ┌─────────────────────┐
                 │ Certificate Policy  │
                 │ Git / IaC / GitOps  │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │    cert-manager     │
                 │                     │
                 │ Issue → Renew →     │
                 │ Validate → Deploy   │
                 └───────┬─────┬───────┘
                         │     │
              ┌──────────┘     └──────────┐
              ▼                           ▼
       Public certificates          Private certificates
       ACME / public CA             Vault / private CA
              │                           │
              └──────────┬────────────────┘
                         ▼
                  Kubernetes Secret
                         │
                         ▼
                 Ingress / Service /
                   Application

cert-manager already handles certificate issuance and automatic renewal, and supports both public ACME authorities and private issuers such as Vault.

1. Public-facing certificates

Use ACME for Internet-facing certificates, typically with DNS-01 validation where appropriate.

cert-manager can automatically create the ACME order, complete the HTTP-01 or DNS-01 challenge, obtain the certificate, and renew it before expiration.

This eliminates workflows like:

Engineer notices expiry
        ↓
Generate CSR
        ↓
Submit to CA
        ↓
Download certificate
        ↓
Copy certificate to server
        ↓
Restart/reload service
        ↓
Hope nothing broke

and replaces them with:

Certificate resource exists
        ↓
Controller detects renewal window
        ↓
Certificate automatically reissued
        ↓
Secret updated
        ↓
Workload reload/rollout
        ↓
Monitoring verifies new certificate

cert-manager calculates renewal timing from the certificate lifetime and configured renewal policy; its current documentation recommends percentage-based renewal where appropriate to avoid problems when an issuer returns a different duration than expected.

2. Internal/mTLS certificates

For internal services, I'd strongly consider HashiCorp Vault PKI or another internal CA.

Vault's PKI engine can issue certificates dynamically according to roles/policies, and Vault specifically recommends automating leaf-certificate renewal at scale.

The particularly nice combination is:

cert-manager → Vault PKI

cert-manager becomes the lifecycle controller while Vault remains the CA/secrets authority. cert-manager has a native Vault issuer integration.

Don't stop at issuance and renewal

The commonly missed part is deployment.

I'd define the lifecycle as:

1. Discover — know every certificate, owner, hostname, CA, environment and workload.
2. Policy — define permitted issuers, algorithms, SANs, maximum lifetimes and renewal windows.
3. Issue — automatically request certificates.
4. Store — put private keys in the appropriate secret store.
5. Deploy — automatically make the new certificate available to the workload.
6. Reload — gracefully reload/restart anything that doesn't dynamically notice certificate changes.
7. Validate — verify the deployed certificate, chain, SANs and expiration.
8. Alert — alert on failed automation, rather than routinely alerting humans about upcoming expiration.
9. Audit — retain issuance, renewal, deployment and revocation events.
10. Revoke — have an explicit emergency-revocation procedure.

That distinction is important: "certificate expires in 30 days" shouldn't be an operational task. "Automatic renewal failed" should be.

What I'd implement

For non-Kubernetes workloads, I'd use the same policy → issuance → deployment → validation model, but use an ACME client, Vault Agent, or a dedicated certificate-management platform appropriate to the environment.

The key design principle

Don't build a certificate-renewal cron job. Build a reconciliation system.

The desired state should say:

"api.example.com must have a valid certificate issued by an approved CA and deployed to these endpoints." The automation continuously reconciles reality against that state. That gives you self-healing behavior rather than a collection of scripts that happen to run on schedule.

If you tell me whether your environment is Kubernetes, AWS/Azure/GCP, VMs/bare metal, or a mixture, I can lay out a concrete target architecture and migration plan.

2. Internal/mTLS certificates

For internal services, I'd strongly consider HashiCorp Vault PKI or another internal CA.

Vault's PKI engine can issue certificates dynamically according to roles/policies, and Vault specifically recommends automating leaf-certificate renewal at scale.

The particularly nice combination is:

cert-manager → Vault PKI

cert-manager becomes the lifecycle controller while Vault remains the CA/secrets authority. cert-manager has a native Vault issuer integration.

Don't stop at issuance and renewal

Automating your SSL/TLS certificate lifecycle saves time, eliminates human error, and prevents unexpected outages caused by expired certificates.

Here are the top modern tools and approaches for complete automation across issuance, renewal, and deployment:

• Cert-manager (Kubernetes) : The gold standard if your infrastructure runs on Kubernetes. It automatically integrates with issuers like Let's Encrypt, issues certificates, and injects them directly into your Ingress resources or workloads.
• ACME Clients with Webhooks (Caddy / Traefik) : If you use modern reverse proxies like Caddy (which handles HTTPS completely automatically out-of-the-box) or Traefik , they have built-in ACME clients that request and renew certificates natively without external scripts.
• Certbot with Deploy Hooks : The classic choice for traditional Linux servers. You can automate renewals via cron or systemd timers and configure --deploy-hook scripts to restart Nginx, Apache, or push the certificate to a load balancer.
• Cloudflare / AWS Certificate Manager (ACM) : If your traffic goes through a CDN or cloud provider, offloading management to AWS ACM, Cloudflare SSL/TLS , or Google Certificate Authority Service means they handle both renewal and deployment at the edge automatically.
• Enterprise Lifecycle Platforms (Venafi / Keyfactor) : For complex, hybrid enterprise environments involving internal CAs, non-web certificates (like code signing or internal mTLS), and strict compliance auditing.

If you'd like, tell me:

• What your current infrastructure stack looks like (e.g., Kubernetes, AWS, bare-metal Nginx, hybrid)
• Your preferred Certificate Authority (e.g., Let's Encrypt, ZeroSSL, or an internal enterprise CA)

I can help you design a specific automation pipeline tailored to your environment.

Automating your SSL/TLS certificate lifecycle has never been more critical. With public certificate validity periods dropping significantly (down to 200 days and trending further down toward eventual 47-day requirements), manual tracking or ad-hoc reminders will inevitably lead to costly outages.

A robust automated solution depends heavily on your infrastructure ecosystem (public cloud, on-prem, hybrid, or Kubernetes). Here are the primary routes and tools for end-to-end SSL automation:

• ACME Protocol & Open-Source (Best for Web Apps & Kubernetes):
  • Implementation: Use the ACME (Automated Certificate Management Environment) protocol. Tools like Certbot or native Kubernetes controllers like cert-manager handle complete issuance, automated renewal, and ingress/load balancer deployment natively.
  • CAs: Pair with free/automated CAs like Let's Encrypt or commercial ACME-supported options like ZeroSSL.
• Native Cloud Certificate Managers (Best for Cloud-Native Environments):
  • Implementation: If you are entirely hosted within a specific cloud provider, native tools completely automate the lifecycle for load balancers and internal services.
  • Tools: AWS Certificate Manager (ACM), Google Managed SSL , or Azure App Service Managed Certificates automatically provision, deploy, and renew public/private certificates with zero touch required.
• Enterprise Certificate Lifecycle Management (CLM) Platforms (Best for Hybrid / Multi-CA / Large Scale):
  • Implementation: If you manage hundreds or thousands of certificates across mixed environments (internal KDCs, Apache/Nginx servers, F5 load balancers, multiple CAs), you need a centralized CLM dashboard for discovery, policy enforcement, and auto-deployment.
  • Tools: Options like DigiCert Trust Lifecycle Manager, ManageEngine Key Manager Plus , or AppViewX CERT+ scan your network, track compliance, and integrate directly with web servers and cloud APIs to deploy renewed keys automatically.

To help narrow down the ideal architecture for your team, tell me:

• What does your infrastructure environment look like (AWS/Azure/GCP, Kubernetes, on-prem traditional servers, or a hybrid mix)?
• Are you primarily using publicly trusted certificates (like Let's Encrypt/DigiCert) or private internal CAs (like Microsoft AD CS / HashiCorp Vault)?
• Do you need automated deployment/binding to specific web servers or load balancers?

Yes. The better pattern is to treat certificates as software-managed infrastructure, not as files that humans renew and copy around.

Recommended architecture

Use ACME + an automated certificate controller, with the deployment/reload step built into the same workflow:

                ┌─────────────────────┐
                │ Certificate Policy  │
                │ domains / issuers / │
                │ key algorithms      │
                └──────────┬──────────┘
                           │
                           ▼
                 ┌───────────────────┐
                 │ Certificate       │
                 │ Controller        │
                 │ (e.g. cert-manager│
                 │ / ACME client)    │
                 └────────┬──────────┘
                          │
              ┌───────────┴───────────┐
              ▼                       ▼
        Issue / Renew            Validate
        certificate              DNS-01/HTTP-01
              │
              ▼
       ┌───────────────┐
       │ Secret Store  │
       │ / K8s Secret  │
       └───────┬───────┘
               │
               ▼
       ┌───────────────┐
       │ Deployment    │
       │ controller    │
       └───────┬───────┘
               │
               ▼
       Reload / rolling
       restart / update LB
               │
               ▼
        TLS endpoint

1. Standardize on ACME

ACME is the right abstraction for public certificates because issuance, validation, renewal and revocation can all be performed machine-to-machine.

For example, Let's Encrypt is a natural public CA, while you can also use an enterprise/private CA that exposes ACME.

I'd avoid building your own certificate-renewal service unless you have a very unusual PKI requirement.

2. If you run Kubernetes, use cert-manager

cert-manager is probably the strongest default for Kubernetes.

It can:

• request certificates from ACME, Vault and other issuers
• perform DNS-01/HTTP-01 validation
• automatically renew certificates
• store the resulting certificate/key as Kubernetes Secrets
• expose the lifecycle through declarative Certificate resources
• work with Ingress/Gateway-based deployments.

The important architectural distinction is that renewal should trigger deployment automatically. Don't have cert-manager renew a Secret and then rely on an engineer to remember to restart Nginx, Envoy, an application, etc.

For workloads that cannot automatically notice a changed Secret, add a controlled reload/rollout mechanism.

3. Separate issuance from deployment

I'd make these separate responsibilities:

Certificate controller

• determines when a certificate needs issuing/renewing
• proves domain ownership
• obtains the certificate
• writes it to the approved secret store

Deployment integration

• watches for certificate changes
• validates the new certificate
• updates the TLS endpoint
• performs a graceful reload or rolling deployment
• verifies the endpoint is actually serving the new certificate

That gives you a much safer chain:

renew → validate → deploy → verify → alert if anything fails

rather than simply:

renew → overwrite certificate file

4. Make DNS validation the default where possible

For large environments, DNS-01 is particularly useful because it works for wildcard certificates and doesn't require the application to expose an HTTP challenge endpoint.

But don't give the certificate controller unrestricted DNS credentials. Give it narrowly scoped permissions to modify the _acme-challenge records it actually needs.

5. Centralize visibility and policy

Even if individual applications obtain certificates themselves, maintain a central inventory containing at least:

• certificate/SAN names
• owner/application
• environment
• issuer/CA
• expiration date
• renewal status
• deployment targets
• key algorithm/size
• last successful renewal
• last successful deployment
• validation/monitoring status

This is particularly important because public certificate lifetimes are getting shorter. AWS notes the CA/Browser Forum's planned reduction to 100 days in March 2027 and 47 days in March 2029.

At that point, manual renewal processes become fundamentally incompatible with operating certificates at scale.

If you're primarily on AWS

There is an especially interesting option now: Amazon Web Services's AWS Certificate Manager added managed ACME endpoints in 2026.

That lets standard ACME clients such as cert-manager obtain public certificates while AWS provides centralized domain controls, visibility, CloudTrail logging and CloudWatch metrics.

For AWS-integrated services such as ALB/ELB, CloudFront and API Gateway, however, I'd generally use native ACM-managed certificates rather than ACME certificates. ACM can handle renewal automatically for those services.

For EC2/on-prem/Kubernetes/hybrid infrastructure, ACME is a better fit because the ACME client retains the private key and performs the renewal/deployment on the workload side.

If you already use HashiCorp Vault

Vault is another strong architecture, particularly when you have substantial private PKI requirements.

Vault's PKI engine supports ACME, so ACME-compatible clients can request and renew leaf certificates without bespoke integration.

That gives you:

                 Vault PKI
                    │
             ┌──────┴──────┐
             │ ACME endpoint│
             └──────┬──────┘
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
     K8s          VMs        Services
  cert-manager   ACME       ACME client

I'd choose this when you need centralized internal CA hierarchy, short-lived internal certificates, strong identity/access controls, or private PKI—not simply because Vault can issue certificates.

What I'd implement

For a typical modern organization, my default would be:

The key design principle is don't automate just renewal—automate the entire lifecycle.

A successful renewal that never reaches the load balancer is still an outage waiting to happen. Conversely, a certificate that gets deployed but isn't validated can turn an automated system into an automated outage.

If you tell me your environment (e.g. Kubernetes + AWS, mostly EC2, on-prem, Azure, mixed/hybrid, etc.), I can propose the concrete architecture and rollout path.

• Cert-manager (Kubernetes-native): The gold standard if your workloads run on Kubernetes. It automates issuance and renewal from issuers like Let's Encrypt and integrates directly with ingress controllers. Check out the project documentation on Cert-manager Documentation.
• ACME Clients (Certbot / Acme.sh) : Great for traditional Linux servers and cron-based automation. They handle HTTP-01 or DNS-01 challenges and can trigger reload hooks for web servers like Nginx or Apache.
• HashiCorp Vault : Ideal for centralized certificate management, internal PKI, and automated secrets lifecycle across hybrid or multi-cloud infrastructures. Explore the features on HashiCorp Vault Secrets Management.
• Cloud-Native Managers (AWS Certificate Manager / GCP Certificate Manager) : Best if you are fully locked into a single public cloud provider. They handle automatic renewals and deployment to load balancers natively, though cross-platform or on-prem support is limited.
• Caddy Server : A web server/reverse proxy that completely automates HTTPS by default out-of-the-box, handling issuance and renewal without manual configuration files. Learn more at Caddy Web Server.

To help narrow down the best fit, tell me:

• What is your infrastructure environment (Kubernetes, AWS/GCP, traditional Linux VMs)?
• Are you using public CAs (like Let's Encrypt) or do you need an internal Private CA?
• How are you currently deploying the certificates (Load balancers, reverse proxies, application code)?

Yes. The key is to stop treating certificates as tickets that someone renews and instead make the certificate lifecycle an automated control loop:

discover → issue → validate → deploy → verify → renew → rotate → alert on failure

What I’d recommend

1. Standardize on ACME wherever possible.
ACME is specifically designed for machine-to-machine certificate issuance and renewal, and clients such as cert-manager and Certbot can automate the process end-to-end.

2. Use cert-manager for Kubernetes.
If you run Kubernetes, cert-manager is probably the cleanest starting point. It represents certificates and issuers as Kubernetes resources, automatically renews certificates before expiration, and stores the resulting certificate/key in Secrets for workloads to consume.

It supports ACME as well as other issuers such as Vault and CyberArk, so you aren't necessarily locked into one CA.

3. Let the deployment layer consume the renewed certificate automatically.

For example:

                    ┌───────────────┐
                    │ Certificate   │
                    │ inventory     │
                    └───────┬───────┘
                            │
                     renewal threshold
                            │
                            ▼
┌─────────┐     ┌────────────────────┐
│ ACME CA │◄───►│ Certificate Manager │
└─────────┘     └─────────┬──────────┘
                          │
                    new cert + key
                          │
             ┌────────────┼─────────────┐
             ▼            ▼             ▼
          Ingress       Load balancer   VM/server
             │            │             │
             └────────────┼─────────────┘
                          ▼
                   deployment check
                          │
                          ▼
                    expiry monitoring

The important part is that renewal should trigger deployment automatically, rather than merely producing a new certificate somewhere.

If you're primarily on AWS

AWS Certificate Manager is attractive when your certificates terminate on AWS services such as CloudFront, ALB/ELB, or API Gateway because ACM can provision and deploy certificates directly into those services and provides managed renewal.

There's also a particularly relevant recent development: AWS added ACME support to ACM in August 2026. That lets existing ACME clients—including cert-manager and Certbot—use ACM for public certificate issuance/renewal on AWS, on-premises, or hybrid infrastructure, while certificates are visible in ACM's inventory.

That makes a hybrid architecture considerably more interesting:

cert-manager/ACME as the automation interface + ACM as the AWS certificate inventory/deployment layer.

If you have lots of heterogeneous infrastructure

For an enterprise with VMs + network appliances + Kubernetes + multiple CAs + on-prem, I'd look at a dedicated certificate-management platform rather than building the entire control plane yourself.

For example, DigiCert Trust Lifecycle Manager is designed around centralized certificate inventory and automation. DigiCert's current documentation specifically supports ACME clients, Kubernetes cert-manager, APIs, web servers, load balancers and network appliances. Note that DigiCert says its older Managed Automation service in CertCentral is being retired October 1, 2026, with migration to Trust Lifecycle Manager.

A practical target architecture

I'd establish these policies:

I'd also make "certificate expires in X days" a secondary alert. The more useful alert is:

Renewal/deployment automation failed; certificate currently expires in 23 days.

That gives the team time to fix the automation rather than turning certificate expiry into an annual fire drill.

One especially important reason to invest now: public TLS certificate lifetimes are being shortened. AWS notes that the CA/B Forum's phased changes bring the maximum public-certificate validity down to 100 days in March 2027 and 47 days in March 2029. At large scale, that makes manual renewal fundamentally impractical.

If you tell me your environment (e.g. AWS/Azure/GCP, Kubernetes, Linux/Windows, F5/NGINX/IIS, number of certs, and whether you need public or internal PKI), I can map this into a concrete architecture and recommend the best tooling combination.

A good target is to make certificate management declarative and event-driven, rather than having teams remember expiration dates and manually copy certificates around.

Recommended architecture

If you run Kubernetes, I’d strongly recommend cert-manager as the lifecycle controller.

                 ┌──────────────────┐
                 │ Certificate CA   │
                 │ Let's Encrypt /  │
                 │ internal CA /    │
                 │ Vault / etc.     │
                 └────────┬─────────┘
                          │ ACME / issuer
                          ▼
┌──────────────┐   ┌──────────────────┐
│ Kubernetes   │──▶│ cert-manager     │
│ Ingress/GW   │   │                  │
└──────────────┘   │ issue             │
                   │ renew             │
                   │ rotate keys       │
                   └────────┬─────────┘
                            │
                            ▼
                     Kubernetes Secret
                            │
                   ┌────────┴────────┐
                   ▼                 ▼
                Ingress           Services

cert-manager can obtain certificates from public or private issuers, automatically renew them before expiration, and store the resulting certificate/private key in Kubernetes Secrets.

The lifecycle I'd implement

1. Issuance

   • Define an Issuer/ClusterIssuer.
   • Use ACME for publicly trusted certificates where appropriate.
   • Use your internal CA/Vault for private PKI.
   • DNS-01 is particularly useful for wildcard certificates and services that aren't publicly reachable. cert-manager supports both HTTP-01 and DNS-01 ACME validation.

2. Renewal

   • Let cert-manager calculate and perform renewals automatically.
   • Don't build a cron job that checks expiration dates.
   • Configure an appropriate renewal window and alert well before the point at which renewal could fail. cert-manager supports explicit renewBefore/percentage settings and renewal windows.

3. Private-key rotation

   • Enable/retain rotationPolicy: Always.
   • Current cert-manager versions default to rotating the private key when a certificate is reissued.

4. Deployment

   • Treat the resulting Secret as the source of truth.
   • Configure applications to reload certificates when the Secret changes.
   • For applications that only read TLS material at startup, automate a controlled rollout/restart; cert-manager's documentation specifically calls out this requirement.

5. Monitoring

   • Alert on:
     • certificate renewal failures
     • failed ACME challenges
     • certificates approaching expiration
     • issuer/CA failures
     • workloads still serving an old certificate
   • Importantly, monitor the serving endpoint, not just the Kubernetes Secret.

If you're not entirely Kubernetes-based

I'd use the same conceptual model but choose the automation layer according to where certificates live:

For example, HashiCorp Vault's PKI engine supports ACME for automated certificate issuance and renewal, specifically addressing the operational burden of manually maintaining large numbers of certificates.

One important design principle

Separate certificate issuance from certificate deployment.

The CA should answer:

"Is this workload authorized to receive a certificate?"

The lifecycle controller should answer:

"When should it be renewed and rotated?"

And the deployment mechanism should answer:

"How does the new certificate reach the workload without downtime?"

That separation makes it much easier to change CAs later without rewriting your application deployment process.

If you tell me whether your environment is Kubernetes, AWS/Azure/GCP, VMs, or a mixture, and roughly how many certificates you manage, I can propose a concrete architecture and migration path.

Managing the SSL certificate lifecycle automatically requires tools that handle ACME protocols (like Let's Encrypt), DNS/HTTP challenges, secure storage, and automatic reloading of web servers or load balancers.

Here are the top production-ready solutions categorized by your infrastructure setup:

• Cert-manager (Best for Kubernetes)
  • Integrates natively into Kubernetes clusters.
  • Automates issuance and renewal from Let's Encrypt, HashiCorp Vault, Venafi, or private CAs.
  • Automatically updates Ingress resources, Secrets, and Gateway API objects.
• Caddy Server (Best for simple web servers or reverse proxies)
  • Features automatic, built-in HTTPS by default out of the box.
  • Handles ACME issuance, stapling, and seamless zero-downtime renewals natively without external cron jobs or scripts.
• Traefik (Best for Docker/Microservices environments)
  • A modern HTTP reverse proxy and load balancer with native ACME support.
  • Dynamically requests and renews certificates via Let's Encrypt for routed containers without needing a service restart.
• Certbot + Automation Hooks (Best for traditional Linux/VM setups)
  • The classic EFF client, but requires configuration with post-renewal hook scripts or systemd timers to reload Nginx, Apache, or HAProxy safely.
  • Pair with acme.sh as a lightweight shell-script alternative if you prefer zero dependencies.
• HashiCorp Vault (PKI Secrets Engine) (Best for enterprise internal PKI & multi-cloud)
  • Acts as a private internal Certificate Authority (CA).
  • Automatically issues, revokes, and manages short-lived certificates for internal microservices and external workloads via API.

To help narrow down the best fit, tell me:

• What infrastructure are you running on (Kubernetes, AWS/Cloud load balancers, traditional Linux VMs, Docker)?
• Which web server or proxy are you using (Nginx, Apache, Caddy, HAProxy)?
• Are you using public CAs (Let's Encrypt, ZeroSSL) or an internal enterprise CA?

To completely automate your SSL certificate lifecycle , you want a tool that handles ACME protocol integration (like Let's Encrypt or private CAs), automatic renewals before expiration, and seamless deployment to your web servers, load balancers, or CDNs.

Here are the top modern solutions depending on your infrastructure:

• Cert-manager (Kubernetes-native): The undisputed gold standard if your workloads run on Kubernetes. It integrates directly with Kubernetes clusters, issues certificates from various issuers (Let's Encrypt, HashiCorp Vault, Venafi, etc.), automatically stores them as Secrets, and renews them seamlessly.
• Caddy Server : A web server and reverse proxy that features automatic HTTPS built right into its core. It manages issuance and renewal via ACME out-of-the-box with zero configuration, making it fantastic for microservices or standalone app servers.
• Certbot (Traditional automation): The official client from the Electronic Frontier Foundation (EFF). Best for traditional single-server Linux/Nginx/Apache environments combined with system cron jobs or systemd timers for automatic renewal hooks.
• Traefik : A modern HTTP reverse proxy and load balancer that has native, built-in Let's Encrypt/ACME support. Similar to Caddy, it handles dynamic configuration and certificate generation automatically for containerized or clustered environments.
• HashiCorp Vault (PKI Secrets Engine) : Ideal for enterprise environments requiring internal Certificate Authorities (CAs) and strict governance over automated internal and external certificate issuance and lifecycle management.

To help narrow down the best fit, tell me:

• What does your infrastructure architecture look like (Kubernetes, AWS/Cloud load balancers, traditional Linux VMs)?
• Are you using public CAs (like Let's Encrypt/ZeroSSL) or a private/internal CA?

Yes. The key is to stop treating certificates as files that someone periodically renews and instead treat them as short-lived, continuously reconciled infrastructure.

Recommended architecture

1. Standardize on ACME

• Use ACME as the common issuance interface wherever possible. It automates domain validation, issuance, renewal, and revocation.
• This lets you change CAs without redesigning the deployment system.
• For public certificates, Let's Encrypt is an obvious option; commercial CAs can also expose ACME endpoints.

2. Use the right automation engine for each environment

cert-manager already handles issuance and renewal and integrates with public CAs and private PKI such as Vault. cert-manager.io Vault's PKI engine can itself expose ACME endpoints for certificate issuance and renewal.

The important part: deployment

I'd make the lifecycle:

Certificate policy
       │
       ▼
   ACME / CA
       │
       ▼
 Certificate issued
       │
       ▼
 Secure certificate store
       │
       ▼
 Deployment adapter
 ┌─────┼─────────┬─────────┐
 ▼     ▼         ▼         ▼
Nginx IIS    Load balancer Kubernetes
       │
       ▼
 Reload / restart / API update
       │
       ▼
 Automated validation
       │
       ▼
 Monitoring + audit

The deployment adapter is where many otherwise-good certificate automation projects fail. Getting a new certificate is relatively easy; reliably installing it on every type of endpoint and verifying that the endpoint is actually serving it is the harder problem.

Build in these safeguards

• Renew early, rather than waiting until expiration.
• Generate a new key pair during renewal unless there is a specific reason not to.
• Store private keys in a secrets system rather than Git/fileshares.
• Make deployment idempotent.
• Validate the certificate after deployment from outside the endpoint.
• Automatically reload the service where possible.
• Roll back if post-deployment validation fails.
• Alert on automation failure, not merely certificate expiration.
• Maintain an inventory mapping certificate → domains → owner → endpoint → deployment mechanism.
• Give DNS automation narrowly scoped permissions, particularly for DNS-01 challenges.
• Record issuance, renewal, deployment, and failure events for auditing.

This becomes increasingly important because public certificate lifetimes are being reduced: the industry is moving toward substantially shorter maximum lifetimes, making manual renewal increasingly impractical.

What I'd choose

If you're designing this for a mixed enterprise environment, I'd lean toward:

ACME + centralized PKI/secrets + endpoint-specific deployment automation + independent monitoring.

For example:

• Public TLS: ACME with your chosen public CA
• Internal TLS: Vault PKI
• Kubernetes: cert-manager
• VMs: ACME clients managed through your configuration-management system
• Windows: Windows-native ACME automation
• Network appliances: vendor APIs/native ACME
• Secrets: Vault/KMS-backed storage
• Monitoring: continuously probe the actual endpoints rather than trusting the renewal job
• Orchestration: Ansible/Terraform/API automation where native integrations aren't available

I'd avoid building a giant custom "certificate manager" that owns every aspect of PKI. Use ACME as the protocol and build the missing orchestration/deployment layer around it. That gives you a much cleaner architecture and keeps you from becoming responsible for implementing PKI logic yourself.

If you tell me your environment (e.g. AWS/Azure/GCP, Kubernetes, Windows/IIS, Linux, F5/Citrix/FortiGate, number of certificates, and whether you need public or internal certs), I can propose a concrete architecture and tool stack.