Skip to main content

Automated Certificate Management

Automatic TLS certificate provisioning and renewal for Kubernetes workloads. Zero manual intervention, predictable URL patterns, and built-in Let's Encrypt integration make HTTPS the default for every deployment.

Interactive CLI

The Codiac CLI guides you through each command interactively. You don't need to memorize flags, just run the command and the CLI prompts you for what it needs.

The Problem: Manual Certificate Hell​

Traditional Kubernetes certificate management:

  • Manual cert-manager configuration for each service
  • Writing Certificate YAML manifests
  • Debugging ACME challenge failures
  • Certificate expiration monitoring
  • Renewal coordination across teams
  • Secret management sprawl

Result: Teams avoid HTTPS in dev/staging, SSL expiration incidents in production, and certificate management becomes a specialized skill.

How Codiac Solves It​

1. Automatic Certificate Provisioning​

Zero configuration required. When you deploy an asset with ingress enabled, Codiac automatically:

  • Creates cert-manager Certificate resources
  • Configures Let's Encrypt issuers (staging or production)
  • Sets up HTTP-01 ACME challenges
  • Provisions TLS secrets
  • Annotates ingress rules for cert-manager
  • Renews certificates before expiration
# Deploy application - HTTPS configured automatically
codiac asset deploy
# The CLI prompts you to select asset, version, and cabinet

# Map hostname - certificate provisioned within 60 seconds
codiac host map
# The CLI prompts you for hostname and target asset

What happens behind the scenes:

  1. Codiac creates Kubernetes Ingress with cert-manager annotations
  2. cert-manager detects new ingress, requests certificate from Let's Encrypt
  3. Let's Encrypt validates domain ownership via HTTP-01 challenge
  4. Certificate issued and stored in Kubernetes Secret
  5. Ingress controller serves TLS using the certificate
  6. cert-manager auto-renews 30 days before expiration

Time to HTTPS: ~60 seconds from hostname mapping to live certificate.

2. Pattern-Based URL Strategy​

Codiac's unique approach: Predictable, deterministic URL patterns eliminate ingress configuration guesswork.

Instead of manually writing Ingress YAML with host rules and paths, you choose a URL strategy that automatically generates URLs for all your assets:

URL Strategy Options​

Service-Dot-Cabinet-Dot-Domain

Pattern: <service>.<cabinet>.<domain>
Example: api.prod-backend.mycompany.com
         web.prod-backend.mycompany.com

Cabinet-Dot-Domain-Slash-Service

Pattern: <cabinet>.<domain>/<service>
Example: prod-backend.mycompany.com/api
         prod-backend.mycompany.com/web

Service-Dot-Domain (simple, custom domains)

Pattern: <service>.<domain>
Example: api.mycompany.com
         app.mycompany.com

Multi-Cluster Strategy

Pattern: <cabinet>.<cluster>.<domain>/<service>
Example: prod.us-east.mycompany.com/api
         prod.eu-west.mycompany.com/api

Globally Shared Domain (for multi-tenant or highly organized setups)

Pattern: <cabinet>.<enterprise>.<tenant>.<cluster>.<domain>/<service>
Example: prod.payments.acme.us-west.shared.com/api

Why Patterns Matter for Certificates​

Consistent patterns = reliable certificates:

  • Predictable hostnames mean cert-manager knows exactly what to request
  • One certificate per asset+domain prevents certificate collisions
  • Automatic wildcard support for cabinet-level certificates when using dot-based strategies
  • No manual cert configuration - the pattern defines the certificate scope

Example:

Configure your URL strategy in the Codiac web UI at app.codiac.io, then deploy:

# Deploy services - each gets its own cert automatically
codiac asset deploy
# Select api → api.prod.mycompany.com (cert provisioned)

codiac asset deploy
# Select web → web.prod.mycompany.com (cert provisioned)

codiac asset deploy
# Select jobs → jobs.prod.mycompany.com (cert provisioned)

Certificate details automatically created:

  • Secret name: tls-{tenant}-{enterprise}-{cabinet}-{asset}--host--{domain-with-dashes}
  • Common Name: <asset>.<cabinet>.<domain>
  • Issuer: letsencrypt-prod (or letsencrypt-staging for non-prod)
  • Challenge: HTTP-01 (automatic via ingress)

3. Cluster-Level TLS Termination​

Codiac terminates TLS at the cluster ingress controller, not at a cloud load balancer or gateway. This approach provides:

Advantages:

  • Certificate reusability across clouds - same cert works on AWS, Azure, GCP, on-prem
  • No cloud vendor lock-in - not tied to AWS ACM, Azure Key Vault, or GCP Certificate Manager
  • Unified certificate management - one system for all environments
  • Faster certificate issuance - HTTP-01 challenge validation at cluster level
  • Lower cost - no cloud load balancer certificate fees

When to use gateway/load balancer termination instead:

  • Regulatory compliance requiring hardware security modules (HSMs)
  • Extremely high traffic requiring offloading TLS from application layer
  • Legacy systems that don't support cluster-level cert-manager

Codiac's default (cluster-level termination) works for 95% of use cases and simplifies operations.

4. Environment-Aware Issuer Selection​

Automatic Let's Encrypt environment selection:

Environment TypeDefault IssuerRate LimitsBest For
Productionletsencrypt-prod50 certs/weekStable, public-facing services
Non-Productionletsencrypt-stagingUnlimitedDev, staging, testing

Override for specific cabinets:

Configure certificate issuer settings in the Codiac web UI at app.codiac.io. You can set staging issuers for testing environments and production issuers for customer-facing environments.

Why staging matters:

  • Let's Encrypt production has rate limits
  • Staging environment = unlimited cert requests (perfect for CI/CD)
  • Staging certs are not trusted by browsers (intentional - prevents accidental use)

5. Built-in Certificate Monitoring​

Codiac tracks certificate status automatically in the web UI at app.codiac.io:

  • Certificate validity period
  • Days until expiration
  • Renewal status
  • ACME challenge status
  • Any errors or warnings

Automatic renewal:

  • cert-manager renews 30 days before expiration
  • Codiac doesn't need to do anything - it's fully automated
  • Alerts if renewal fails (via Codiac monitoring integration)

Comparison: Codiac vs Manual cert-manager​

TaskManual cert-managerCodiac
Initial setupInstall cert-manager, configure ClusterIssuers, write Certificate YAMLAutomatic (built into cluster initialization)
Per-service certWrite Certificate manifest, reference in Ingress, debug ACMEcodiac host map (CLI prompts for domain and asset)
Certificate renewalAutomatic (cert-manager handles)Automatic (cert-manager handles)
URL consistencyManual Ingress host configuration per servicePattern-based, deterministic URLs
Cert collisionsPossible if multiple Certificates request same hostnameImpossible - one cert per asset+domain
MonitoringExternal tools (Prometheus, custom alerts)Built into cod cabinet status
Multi-clusterSeparate cert-manager per cluster, manual syncUnified management, automatic replication
Configuration reuseReconfigure Certificate + Ingress YAML for each new service/environmentSet URL strategy once, auto-applied to all future deployments
Configuration overheadSeparate Certificate manifests per serviceZero - pattern generates certs automatically
Configuration Once, Applied Everywhere

Traditional approach: 15 minutes per service × 50 services × 3 environments = 37.5 hours of repeated Certificate + Ingress configuration work.

Codiac approach: 5 minutes one-time URL strategy setup. Future services get HTTPS automatically. Save 37+ hours and eliminate configuration drift.

With Codiac, you set your certificate and ingress strategy once per cabinet/environment. Every new service inherits this configuration automatically - no repeated YAML writing, no duplicated configuration, no documentation debt.

Common Use Cases​

Use Case 1: New Application Deployment​

Goal: Deploy application with HTTPS in dev, staging, and production.

Steps:

  1. Create cabinets for each environment:

    codiac cabinet create
    # Create dev, staging, and prod cabinets

  2. Deploy your asset to each cabinet:

    codiac asset deploy
    # Select asset and target cabinet

  3. Map hostnames for each environment:

    codiac host map
    # Map api.dev.mycompany.com → dev cabinet
    # Map api.staging.mycompany.com → staging cabinet
    # Map api.mycompany.com → prod cabinet

Certificates are provisioned automatically within ~30 seconds of hostname mapping.

Result: HTTPS everywhere, zero manual certificate configuration.

Use Case 2: Multi-Region Deployment​

Goal: Same application in US and EU regions with separate certificates.

Steps:

  1. Capture or create clusters in each region:

    codiac cluster capture
    # Capture US cluster, then EU cluster

  2. Create cabinets in each cluster:

    codiac cabinet create
    # Create api cabinet in US cluster
    # Create api cabinet in EU cluster

  3. Map hostnames for each region:

    codiac host map
    # Map api.us.mycompany.com → US cabinet
    # Map api.eu.mycompany.com → EU cabinet

Result: Two separate certificates, one per region. Users routed to nearest region.

Use Case 3: Certificate Rotation After Compromise​

Goal: Force immediate certificate reissuance.

Steps:

  1. Delete existing certificate secret via kubectl:

    kubectl delete secret tls-{tenant}-{ent}-production--host--mycompany-com -n <namespace>

  2. Redeploy the asset to trigger certificate reissuance:

    codiac asset deploy
    # Select the affected asset and cabinet

  3. Monitor in the web UI - new certificate issued within 60 seconds

DNS Configuration (User Responsibility)​

IMPORTANT: Codiac manages ingress routing and TLS certificates inside the cluster. You must configure DNS separately.

What Codiac does:

  • Creates Kubernetes Ingress resources
  • Configures TLS termination
  • Provisions certificates via Let's Encrypt
  • Routes traffic inside the cluster based on hostname/path

What you must do:

  • Point DNS A records to your cluster's ingress IP address
  • Configure DNS in your domain registrar or DNS provider

Example DNS configuration:

  1. Get your cluster's ingress IP from the web UI at app.codiac.io or from your cloud provider console

  2. In your DNS provider (Cloudflare, Route53, etc.), create records:

    A record: api.mycompany.com → 52.200.192.116
    A record: *.prod.mycompany.com → 52.200.192.116

The Codiac web UI shows the required DNS records for all domains mapped to your cabinets.

Troubleshooting​

Certificate Not Issuing​

Symptoms: Certificate shows pending in web UI for >5 minutes.

Common causes:

  1. DNS not pointing to cluster - Verify A record points to ingress IP
  2. Firewall blocking port 80 - HTTP-01 challenge requires port 80 open
  3. Rate limit hit - Switch to staging issuer temporarily
  4. Domain not owned - Let's Encrypt validates domain ownership

Debug steps:

# Check cert-manager logs
kubectl logs -n cert-manager -l app=cert-manager

# Check certificate resource status
kubectl describe certificate -n <namespace>

# Verify DNS resolution
dig api.mycompany.com
# Should return your cluster's ingress IP

Certificate Expiring Soon​

Symptoms: Certificate shows less than 7 days until expiration.

Codiac behavior:

  • cert-manager attempts renewal 30 days before expiration
  • If renewal fails, cert-manager retries automatically
  • Codiac alerts if renewal blocked

Manual renewal:

Redeploy the asset to trigger certificate reissuance:

codiac asset deploy
# Select the affected asset and cabinet

Mixed Content Warnings (HTTP resources on HTTPS page)​

Symptoms: Browser shows "not secure" despite valid certificate.

Cause: Frontend loading HTTP resources (images, scripts, CSS) on HTTPS page.

Solution: Configure SSL redirect in your ingress annotations or update your application to use HTTPS URLs for all resources.

Advanced: Custom Certificate Authorities​

Use case: Internal CA for private services (not public Let's Encrypt).

Codiac integrates with cert-manager's Issuer and ClusterIssuer resources. You can configure custom issuers by:

  1. Creating your Issuer or ClusterIssuer resource in Kubernetes
  2. Configuring your cabinet to use the custom issuer via the web UI

See cert-manager documentation for setting up custom issuers.

FAQ​

Q: Do I need to renew certificates manually?

A: No. cert-manager automatically renews certificates 30 days before expiration. Codiac monitors the renewal process.

Q: Can I use wildcard certificates?

A: Yes, but only for DNS-01 challenge type (requires DNS provider API integration). Most users don't need wildcards - pattern-based URLs make individual certs easy.

Q: What happens if Let's Encrypt is down?

A: Existing certificates continue working. New certificate requests queue and retry automatically when Let's Encrypt recovers.

Q: Can I bring my own certificates?

A: Yes. Create a Kubernetes TLS secret manually and reference it in your ingress configuration. Codiac won't overwrite manually-created secrets.

Q: Does Codiac support mTLS (mutual TLS)?

A: Yes, via service mesh integration (Istio, Linkerd). This is separate from ingress TLS and configured at the service level.

Start securing your applications: Deploy your first HTTPS service