Stop Hardcoding Secrets: The 2025 Guide to CI/CD Certificate Integration

The era of manually managing certificates in your deployment pipelines is officially over. With machine identities now outnumbering human identities by a factor of 45 to 1, Continuous Integration and Continuous Deployment (CI/CD) pipelines have become the primary factories for generating these identities. Yet, many organizations are still relying on outdated, high-risk practices like hardcoding long-lived .pem files into GitHub Secrets or GitLab CI environment variables.

Driven by the exponential growth of microservices, impending industry mandates, and a surge in software supply chain attacks, modern CI/CD pipelines must not only be secured by certificates, but they must also seamlessly provision and utilize them on the fly.

If your pipeline relies on a certificate that expires in a year, you are already behind the curve. Here is your comprehensive guide to modernizing CI/CD certificate integration, eliminating secret sprawl, and building a crypto-agile software factory.

The 90-Day Countdown: Why Manual PKI is Dead

The biggest driver forcing DevOps teams to rethink certificate management is Google’s proposal to reduce the maximum validity of public TLS certificates from 398 days to just 90 days. While this specifically targets public trust, internal Public Key Infrastructure (PKI) is rapidly following suit.

When certificates expire every 90 days, manual provisioning and rotation are no longer mathematically viable. A single expired certificate used for internal repository access (like pulling dependencies from Nexus or Artifactory) can halt your entire CI/CD pipeline.

We don't have to look far for cautionary tales. Recently, an expired TLS certificate caused a massive backend outage for Epic Games, highlighting a critical failure in automated renewal within their deployment pipeline. When automation fails, or when manual steps are forgotten, the software factory stops.

To survive the 90-day lifecycle, full automation via the Automated Certificate Management Environment (ACME) protocol, proprietary APIs, and ephemeral credentials is an absolute requirement.

The Dual Role of Certificates in Modern Pipelines

Before diving into the technical implementation, it is crucial to distinguish between the two primary ways certificates interact with your CI/CD pipeline. Treating these as a single problem often leads to architectural confusion.

1. Securing the Pipeline (Authentication & mTLS)

This involves the certificates used by the CI/CD runners to authenticate to internal infrastructure. For example, your GitHub Actions runner needs to securely connect to your Kubernetes cluster, your database, or your cloud provider. Under Zero Trust Architecture frameworks like NIST SP 800-207, this requires mutual TLS (mTLS).

2. Securing the Output (Code Signing & SLSA)

This involves the certificates your pipeline uses to sign the artifacts it creates. To comply with the Supply-chain Levels for Software Artifacts (SLSA) framework and US Executive Order 14028, pipelines must automatically generate verifiable digital signatures for Docker images, binaries, and Software Bill of Materials (SBOMs).

The Old Way vs. The New Way: From Static Secrets to OIDC

The "Old Way" of handling pipeline certificates involved a security administrator generating a wildcard certificate with a 1-year expiration, handing the private key to a DevOps engineer, and storing it in a CI/CD secret manager. If that key was compromised, the blast radius was massive. If the engineer left the company, the renewal date was often forgotten.

The "New Way" relies on OpenID Connect (OIDC) and ephemeral certificates. Instead of storing a long-lived certificate, the pipeline authenticates dynamically to a secret manager, mints a certificate valid only for the duration of the build, uses it in memory, and lets it expire.

Implementing OIDC with GitHub Actions and HashiCorp Vault

Let's look at a practical example of a cloud-native FinTech company that successfully migrated away from static credentials. They use HashiCorp Vault as their internal PKI engine and GitHub Actions for CI/CD.

First, you configure your GitHub Actions workflow to request an OIDC token. Notice the permissions block, which is required to fetch the OIDC token.

name: Deploy Microservice
on:
  push:
    branches: [ "main" ]

# Required to fetch the OIDC token
permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Import Secrets via Vault OIDC
        uses: hashicorp/vault-action@v3
        with:
          url: https://vault.your-company.com:8200
          role: github-actions-deploy-role
          method: jwt
          exportToken: true

In this setup, GitHub Actions generates a short-lived JWT (JSON Web Token). Vault verifies this token against GitHub's public OIDC endpoints. If the repository and branch match Vault's strict policies, Vault grants a temporary access token. No passwords, no static API keys.

Step-by-Step: Minting Ephemeral Certificates

Once authenticated, the pipeline needs to mint a certificate to secure the workload it is deploying. Because we are using Vault's PKI secrets engine, we can generate a certificate that is valid for just a few hours.

      - name: Generate Ephemeral TLS Certificate
        run: |
          # Request a certificate valid for 4 hours
          vault write -format=json pki_int/issue/microservice-dot-com \
            common_name="api.microservice.internal" \
            ttl="4h" > cert.json

          # Extract the certificate and private key into memory/environment
          export TLS_CERT=$(jq -r '.data.certificate' cert.json)
          export TLS_KEY=$(jq -r '.data.private_key' cert.json)

          # Pass to deployment script (e.g., Helm or Terraform)
          ./deploy.sh --cert "$TLS_CERT" --key "$TLS_KEY"

Best Practice: Notice that the certificate and private key are extracted directly into environment variables and passed to the deployment script. They are never written to the disk of the CI/CD runner, preventing accidental leakage in build logs or cached workspaces. Because the certificate expires in 4 hours, revocation is unnecessary.

Keyless Code Signing with Sigstore

Securing the pipeline's connection is only half the battle; you must also secure the software supply chain. Historically, code signing required storing highly sensitive private keys in CI/CD variables. If an attacker breached the pipeline, they could use those keys to sign malware, as seen in high-profile supply chain attacks like SolarWinds.

Today, the industry standard is "keyless" signing using Sigstore. Sigstore's Cosign tool leverages OIDC to generate an ephemeral certificate tied to the identity of the CI/CD workflow itself. It signs the artifact, publishes the signature to an immutable transparency log (Rekor), and discards the private key immediately.

Here is how you implement keyless signing for a Docker image in GitHub Actions:

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

      - name: Build and Push Docker Image
        id: build-and-push
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: user/app:latest

      - name: Sign the Published Docker Image
        env:
          # This allows Cosign to use the GitHub OIDC token
          COSIGN_EXPERIMENTAL: "true"
        run: |
          cosign sign --yes user/app@${{ steps.build-and-push.outputs.digest }}

With this implementation, anyone verifying the Docker image can cryptographically prove it was built by your specific GitHub Actions workflow on your specific repository, without you ever having to manage or rotate a code signing certificate.

Preventing the "Silent Killer": Certificate Expiration

While shifting to ephemeral certificates in the pipeline solves the problem of long-lived credential theft, what happens to the workloads after they are deployed?

Often, pipelines deploy infrastructure that relies on cert-manager in Kubernetes to handle automated renewals. However, automation can and will fail. A misconfigured DNS challenge, a revoked ACME account, or a firewall blocking Let's Encrypt can cause cert-manager to fail silently. The pipeline did its job, but the deployed certificate is ticking toward expiration.

This is where external visibility becomes critical. Security and DevOps teams often have zero visibility into the certificates being minted by developers or automated systems until an outage occurs.

To prevent this, you must decouple your monitoring from your provisioning. Using a dedicated tracking platform like Expiring.at provides an essential safety net. By monitoring your public-facing endpoints and internal infrastructure independently of your CI/CD tools, you gain proactive alerts before an automated renewal failure turns into a Sev-1 outage.

Integrating expiration tracking ensures that even if your GitOps sync fails or your Vault token expires, you are notified via Slack, email, or webhook weeks before the 90-day (or shorter) validity period ends. It bridges the gap between pipeline automation and day-two operations.

Future-Proofing: Crypto-Agility and PQC Readiness

Looking slightly further ahead into 2025, the finalized Post-Quantum Cryptography (PQC) standards from NIST (FIPS 203, 204, and 205) are forcing organizations to audit their pipelines for "crypto-agility."

Quantum computers will eventually break standard RSA and ECC encryption. If your CI/CD pipelines rely on hardcoded certificates, migrating to quantum-resistant algorithms will require thousands of manual pull requests across hundreds of repositories.

However, if you have adopted the automated, OIDC-driven PKI architecture described above, achieving PQC readiness is remarkably simple. You simply update the cryptographic algorithm policy in your central PKI engine (like Vault or Venafi). The next time your CI/CD pipeline runs, it will automatically request, receive, and deploy a post-quantum certificate. Automation is the only realistic path to crypto-agility.

Key Takeaways and Next Steps

Integrating certificate management deeply into your CI/CD pipelines is no longer optional; it is a foundational requirement for modern security and compliance. To summarize your immediate action items:

1. Audit Your Secrets: Scan your Git repositories and CI/CD variables for static .pem, .crt, and .key files. Plan their deprecation