Short-lived machine identities require automated certificate management in CI/CD pipelines.

In modern cloud-native architectures, the proliferation of microservices, containers, and ephemeral environments has caused an explosion in machine identities. Today, machine identities outnumber human identities by a staggering ratio of 45 to 1. Every single one of these machines, workloads, and services requires cryptographic proof of identity to communicate securely.

For years, organizations treated certificate management as an isolated, manual process handled by IT or InfoSec teams. However, the manual provisioning of SSL/TLS certificates, code signing certificates, and SSH keys now creates severe deployment bottlenecks, introduces massive security vulnerabilities through secret sprawl, and leads to catastrophic, headline-making outages.

Integrating certificate management directly into your Continuous Integration and Continuous Deployment (CI/CD) pipelines is no longer an advanced optimization—it is a baseline requirement for operational survival.

The Forcing Function: 90-Day Lifespans and Zero Trust

The industry is currently facing a massive paradigm shift in how we handle Public Key Infrastructure (PKI). Google has officially proposed reducing the maximum validity of public TLS certificates from 398 days to just 90 days. While the exact enforcement date is still pending, the implications are immediate: enterprise organizations are spending their current cycles frantically automating their pipelines to handle 90-day, or even shorter, lifecycles.

If your organization manages thousands of certificates, manual renewal under a 90-day regime is mathematically and operationally impossible.

Furthermore, the implementation of Zero Trust Architecture (ZTA) mandates that we no longer rely on secure network perimeters. Instead, CI/CD pipelines are being redesigned to issue short-lived, identity-based certificates to workloads at runtime. When combined with strict incoming compliance frameworks like the European Union's Digital Operational Resilience Act (DORA)—which penalizes financial entities for outages caused by expired certificates—automated lifecycle management becomes a strict legal and operational necessity.

Core Architectural Patterns for CI/CD Certificate Integration

To solve these challenges, engineering teams must shift away from static, long-lived secrets and embrace dynamic, Just-In-Time (JIT) certificate provisioning. A modern, secure CI/CD certificate integration typically follows one of three distinct architectural patterns, depending on the target deployment.

1. Infrastructure Provisioning with HashiCorp Vault and Terraform

When provisioning infrastructure, developers often prioritize speed, leading to the dangerous practice of hardcoding private keys or storing long-lived certificates as plain text in Git repositories. The solution is dynamic secret injection using OpenID Connect (OIDC) federation between your CI/CD provider and a secret manager like HashiCorp Vault.

In this pattern, your CI pipeline runs a Terraform deployment. Terraform authenticates to Vault using a short-lived CI/CD JWT token. Vault’s PKI secrets engine dynamically generates a private key and issues an X.509 certificate on the fly. Terraform then deploys the certificate directly to the target resource, such as an Application Load Balancer, without the private key ever touching the disk or the CI logs.

Here is a practical example of how you can configure Terraform to request a dynamic certificate from Vault during a pipeline run:

# Configure the Vault provider to use the CI/CD OIDC token
provider "vault" {
  address = "https://vault.internal.yourcompany.com"
  auth_login_jwt {
    role = "cicd-terraform-role"
    jwt  = var.github_actions_oidc_token
  }
}

# Request a dynamic certificate from the Vault PKI engine
resource "vault_pki_secret_backend_cert" "app_cert" {
  backend     = "pki_int"
  name        = "web-servers"
  common_name = "api.yourcompany.com"
  ttl         = "720h" # 30 days validity
  format      = "pem"
  private_key_format = "der"
}

# Deploy the dynamically generated certificate to an AWS Load Balancer
resource "aws_acm_certificate" "dynamic_alb_cert" {
  private_key       = vault_pki_secret_backend_cert.app_cert.private_key
  certificate_body  = vault_pki_secret_backend_cert.app_cert.certificate
  certificate_chain = vault_pki_secret_backend_cert.app_cert.ca_chain
}

By utilizing this approach, you completely eliminate the need to store static certificates in your repository. The certificate is generated at deployment time and is tied directly to the lifecycle of the infrastructure it serves.

2. Kubernetes Deployments with cert-manager

For containerized workloads running in Kubernetes, certificate management should be treated as native infrastructure-as-code. Rather than generating certificates outside the cluster and pushing them in via CI/CD, the modern approach is to push the intent to have a certificate, and let the cluster handle the provisioning.

This is achieved by integrating cert-manager into your Helm charts or raw Kubernetes manifests. When your CI pipeline pushes a deployment to the cluster, cert-manager intercepts the custom resources, communicates with an internal Certificate Authority or a public provider like Let's Encrypt via the ACME protocol, and mounts the resulting certificate directly into the pod as a secret.

Consider this practical YAML snippet that you would include in your CI/CD deployment package:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: microservice-tls
  namespace: production
spec:
  # The secret name where the cert and private key will be stored
  secretName: microservice-tls-secret
  duration: 2160h # 90 days
  renewBefore: 360h # 15 days
  subject:
    organizations:
      - YourCompany
  commonName: service.production.internal
  dnsNames:
    - service.production.internal
  issuerRef:
    name: internal-vault-issuer
    kind: ClusterIssuer

When your pipeline applies this manifest, cert-manager automatically handles the initial issuance and all future renewals. The CI/CD pipeline is responsible for defining the policy and the routing, but the actual cryptographic heavy lifting is offloaded to the cluster's native automation.

3. The Rise of Keyless Code Signing with Sigstore

While infrastructure certificates secure data in transit, code signing certificates secure the software supply chain. Historically, code signing in CI/CD pipelines required injecting highly sensitive GPG or RSA private keys into CI runners as environment variables. If a runner was compromised, the attacker could sign malicious artifacts as your company.

To achieve compliance with frameworks like SLSA (Supply chain Levels for Software Artifacts), organizations are rapidly adopting "keyless" code signing using Sigstore, specifically its Cosign tool.

Keyless signing leverages OIDC identities to request ephemeral, short-lived certificates from the Fulcio Certificate Authority. The artifact is signed using this ephemeral certificate, the signature is pushed to an OCI registry, and the event is recorded in the Rekor transparency log. Because the certificate expires in minutes, there is no private key to manage, rotate, or steal.

Here is how you can implement keyless signing in a GitHub Actions pipeline:

name: Build and Sign Container
on:
  push:
    branches: [ "main" ]

# Required to request the OIDC token from GitHub
permissions:
  contents: read
  packages: write
  id-token: write 

jobs:
  build-and-sign:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Install Cosign
        uses: sigstore/cosign-installer@v3.1.1

      - name: Build and Push Docker Image
        id: build-image
        run: |
          docker build -t ghcr.io/yourcompany/app:${{ github.sha }} .
          docker push ghcr.io/yourcompany/app:${{ github.sha }}

      - name: Sign the published Docker image
        env:
          COSIGN_EXPERIMENTAL: "true"
        run: |
          # Cosign automatically uses the GitHub Actions OIDC token 
          # to request an ephemeral certificate from Fulcio
          cosign sign --yes ghcr.io/yourcompany/app:${{ github.sha }}

The Kubernetes project itself recently migrated its release process to use Sigstore, completely eliminating the need for project maintainers to manage and secure static GPG keys. This drastically reduces the attack surface of the software supply chain while ensuring cryptographic verification of all releases.

Overcoming the DevOps vs. InfoSec Bottleneck

One of the primary reasons developers bypass proper certificate management is friction. Traditional PKI teams often take days to issue certificates via ticketing systems like ServiceNow or Jira. This fundamentally breaks the continuous flow of CI/CD.

The solution is implementing PKI-as-a-Service. Information Security teams must define the cryptographic policies centrally—specifying allowed algorithms, key lengths, and maximum validities—but developers must be able to consume these certificates via self-service APIs or native CI/CD plugins.

By utilizing OIDC federation, as demonstrated in the Vault and Sigstore examples above, you bridge the gap between DevOps and InfoSec. InfoSec trusts the identity provider (e.g., GitHub, GitLab, AWS IAM), and the CI/CD pipeline uses that trusted identity to request compliant certificates on demand. The bottleneck is entirely removed, and security is embedded by default.

Visibility and Expiration Tracking: The Missing Link

A critical trap that organizations fall into when implementing CI/CD certificate automation is the "set and forget" mentality. Automation is incredibly powerful, but it is not infallible.

What happens if your internal ACME server experiences an outage during a renewal window? What if the OIDC token configuration in your CI/CD pipeline expires or is accidentally modified? What if a developer manually overwrites an automated certificate with a static one during a late-night troubleshooting session?

When automated certificates fail to renew silently, services crash. Gartner estimates that enterprise IT downtime costs an average of $300,000 per hour. Therefore, automated issuance must be paired with independent, external visibility.

While your pipelines handle the heavy lifting of provisioning, you need a dedicated oversight mechanism to verify that the automation is actually succeeding. This is exactly where Expiring.at becomes an essential component of your infrastructure. By providing centralized expiration tracking and proactive alerting, Expiring.at acts as your safety net. It monitors the actual certificates deployed to your endpoints, regardless of how they were provisioned. If an automated CI/CD pipeline fails to rotate a certificate before its 90-day expiration, Expiring.at will alert your team well before an outage occurs, giving you the critical lead time needed to fix the pipeline.

Future-Proofing: Crypto-Agility and PQC Readiness

Looking slightly further ahead, integrating certificate management into your CI/CD pipelines is the only realistic way your organization will survive the transition