Certificate Provisioning and Deployment

Certificate provisioning is delivering a signed certificate and its private key to the system that needs it. Certificate deployment is activating that certificate so it actually serves traffic. These are two distinct steps, and the gap between them is where most certificate-related outages occur. A certificate can be successfully provisioned (file written to disk, secret updated in vault) but never deployed (service not reloaded, configuration not updated, binding not refreshed).

Why it matters

• Issuance ≠ deployment — a certificate sitting in a CA’s download queue or a secrets manager isn’t protecting anything. It must reach the TLS termination point and be loaded into memory by the serving process.
• Multi-target complexity — one certificate may need to be deployed to 20 load balancer instances, 5 CDN edge configurations, and a disaster recovery site. Missing one target means inconsistent behavior.
• Format compatibility — different systems need different formats: PEM for Nginx, PFX/PKCS#12 for IIS and Java, DER for some embedded systems. Provisioning must handle format conversion.
• Atomic deployment — replacing a certificate on a live system must be atomic. If the key file is updated before the cert file (or vice versa), the service may briefly serve a mismatched key/cert pair and fail all connections.
• Rollback capability — if a new certificate causes issues (wrong SANs, incomplete chain), you need to revert to the previous certificate quickly. Provisioning systems must retain the previous version.

How it works

1. Certificate issued — CA signs the certificate and makes it available (ACME download, API response, email, portal)
2. Format conversion — convert to the format required by the target (PEM, PFX, JKS, DER)
3. Chain assembly — combine end-entity certificate with intermediate CA certificates in the correct order
4. Transport to target — deliver via: file copy (SCP/SFTP), secrets manager API (Vault, AWS Secrets Manager), cloud service API (ACM, Azure Key Vault), or Kubernetes Secret update
5. Configuration update — update the service configuration to reference the new certificate path/version (if paths changed)
6. Service reload — trigger the TLS-terminating service to load the new certificate: nginx -s reload, systemctl reload apache2, Kubernetes Secret rotation, or API call to cloud service
7. Verification — connect to the endpoint and confirm the new certificate is being served (check serial number, expiry date, or fingerprint)

In real systems

Nginx (file-based provisioning + reload):

# Provisioning: copy cert and key to target
scp fullchain.pem server:/etc/ssl/certs/example.com.pem
scp privkey.pem server:/etc/ssl/private/example.com.key

# Deployment: reload Nginx to pick up new cert
ssh server "nginx -t && nginx -s reload"

# Verification: confirm new cert is served
echo | openssl s_client -connect server:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -serial -enddate

AWS ACM + ALB (cloud-native, zero-touch):

# Certificate imported or issued in ACM
# ALB listener references the ACM ARN — no file management
# When ACM renews the cert, ALB picks it up automatically
# No reload, no file copy, no deployment step

aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:... \
  --certificates CertificateArn=arn:aws:acm:us-east-1:123:certificate/new-cert

HashiCorp Vault (secrets-based provisioning):

# Vault issues certificate via PKI secrets engine
vault write pki/issue/web-server \
  common_name="api.example.com" \
  alt_names="api-internal.example.com" \
  ttl="720h"

# Application reads cert from Vault at startup or via agent
# Vault Agent can template certs to files and trigger reload:
template {
  source      = "/etc/vault/templates/cert.tpl"
  destination = "/etc/ssl/certs/api.pem"
  command     = "systemctl reload nginx"
}

Kubernetes cert-manager (fully automated):

# cert-manager provisions directly into a Secret
# Ingress controller watches the Secret and hot-reloads
# No manual provisioning or deployment step exists
apiVersion: cert-manager.io/v1
kind: Certificate
spec:
  secretName: api-tls  # cert-manager creates/updates this Secret
  issuerRef:
    name: letsencrypt-prod

The ingress controller (nginx-ingress, Traefik) watches for Secret changes and reloads TLS configuration automatically. Zero human involvement from issuance through deployment.

Where it breaks

Certificate renewed but service not reloaded — ACME client renews the certificate and writes new files to disk. Nginx continues serving the old certificate from memory. The files on disk show a valid cert (monitoring passes), but clients see the expired cert still in memory. This is the most common deployment failure. Fix: every renewal must trigger a reload. Certbot uses --deploy-hook "systemctl reload nginx". Without this hook, renewal is incomplete.

Multi-target inconsistency — a wildcard certificate is deployed to 8 servers behind a load balancer. The deployment script succeeds on 6 but fails on 2 (SSH timeout, disk full, permission error). The load balancer round-robins between servers — some requests get the new cert, others get the old (or expired) cert. Users see intermittent TLS errors. Deployment must verify all targets and alert on partial failure.

PFX password mismatch — a certificate is exported as PFX with a password for deployment to IIS. The deployment automation uses a different password than what was set during export. IIS can’t import the certificate. The error is logged but not alerted on. The old certificate continues serving until it expires. Format conversion and credential management must be part of the provisioning pipeline, not manual side-steps.

Operational insight

The safest deployment pattern is “deploy then verify then cutover” — not “replace in place.” Instead of overwriting the active certificate file, deploy the new certificate to a staging path, verify it’s valid and complete (correct SANs, full chain, matching key), then atomically swap the symlink or configuration reference and reload. This prevents serving a half-written or corrupted certificate during the replacement window. In Kubernetes, this happens naturally (Secret update is atomic), but in file-based systems, you must design for it explicitly.

Related topics

• Certificate Enrollment
• Certificate Lifecycle Stages
• Certificate Renewal and Revocation
• TLS Termination
• Certificate Automation at Scale