ACME Beyond Let's Encrypt: How the Protocol Is Expanding to Non-TLS PKI

ACME: From Niche Protocol to Industry Standard

When Let's Encrypt launched in 2016, ACME (Automatic Certificate Management Environment) was a protocol built for one purpose: automating free DV certificate issuance. A decade later, ACME has evolved into the industry standard for certificate automation — and it's expanding beyond TLS into entirely new PKI use cases.

In 2026, ACME is supported by virtually every major certificate authority, adopted by DNS registrars like Gandi, and the subject of research initiatives extending it to non-TLS PKI with W3C Verifiable Credentials. The protocol that automated Let's Encrypt is becoming the automation layer for all of PKI.

The ACME Ecosystem in 2026

Certificate Authorities Supporting ACME

ACME is no longer a Let's Encrypt exclusive. Major CAs now offer ACME endpoints:

ACME Clients and Tools

The ACME client ecosystem has matured significantly:

Standalone Clients

• Certbot: The original Let's Encrypt client, now CA-agnostic
• acme.sh: Lightweight shell-based client with broad DNS plugin support
• Lego: Go-based ACME client used by Traefik and other tools
• win-acme: Windows-specific ACME client for IIS and Exchange

Integrated Solutions

• Caddy: Web server with built-in ACME, automatic HTTPS by default
• Traefik: Reverse proxy with native ACME support
• cert-manager: Kubernetes-native certificate management with ACME issuers
• Nginx Proxy Manager: UI-based reverse proxy with ACME integration

Enterprise Platforms

• TigerTrust: Multi-CA ACME with policy enforcement and deployment automation
• HashiCorp Vault: PKI secrets engine with ACME client capabilities
• Step CA: Open-source CA with ACME server support

Gandi Adds ACME: Why It Matters

The DNS Registrar Play

In early 2026, Gandi announced ACME support for certificate issuance. This is notable not because of Gandi's CA capabilities, but because of what it represents: the convergence of DNS management and certificate automation.

Gandi manages millions of domains. By adding ACME support, they enable customers to automate certificate issuance through the same provider that manages their DNS — eliminating a common integration point between CA and DNS provider.

The Integration Advantage

When your DNS registrar is also your ACME CA:

Traditional flow:
  1. Certificate request → CA (DigiCert/Let's Encrypt)
  2. DNS challenge → DNS provider (Gandi/Cloudflare/Route53)
  3. Validation → CA verifies DNS record
  4. Issuance → CA issues certificate

Integrated flow:
  1. Certificate request → Gandi (CA + DNS)
  2. Validation → Internal (same provider)
  3. Issuance → Immediate

Fewer integration points mean fewer failure modes. DNS propagation delays — a common cause of ACME validation failures — are eliminated when the CA and DNS provider are the same entity.

ACME for Non-TLS PKI: The Research Frontier

The Limitation of Current ACME

Today, ACME is designed almost exclusively for TLS certificates. The protocol's challenge mechanisms (HTTP-01, DNS-01, TLS-ALPN-01) verify control over domains and web servers. But PKI extends far beyond TLS:

• Code signing certificates verify software publisher identity
• S/MIME certificates encrypt and sign email
• Document signing certificates verify document authenticity
• IoT device certificates authenticate connected devices
• Client authentication certificates identify users and services

These use cases require different identity verification than domain control. You can't prove you're a legitimate software publisher by placing a file on a web server.

ACME + Verifiable Credentials

Research initiatives in 2026 are proposing an extension to ACME that uses W3C Verifiable Credentials (VCs) for non-domain identity verification:

Traditional ACME:
  Challenge: "Prove you control example.com"
  Method: DNS-01, HTTP-01, TLS-ALPN-01
  Result: DV certificate for example.com

Extended ACME with VCs:
  Challenge: "Prove your organizational identity"
  Method: Present Verifiable Credential from trusted issuer
  Result: OV/EV certificate, code signing cert, or S/MIME cert

How It Would Work

# Hypothetical ACME + VC flow
acme_request:
  type: "code-signing"
  identifier:
    type: "organization"
    value: "Example Corp"

  verifiable_credentials:
    - type: "OrganizationCredential"
      issuer: "did:web:duns.dnb.com"  # D&B verified organization
      proof:
        type: "Ed25519Signature2020"
        # Cryptographic proof of organization identity

    - type: "DeveloperCredential"
      issuer: "did:web:github.com"  # GitHub verified developer
      proof:
        type: "Ed25519Signature2020"
        # Cryptographic proof of developer identity

  # CA validates VCs, issues code signing certificate
  result:
    certificate_type: "code-signing"
    subject: "Example Corp"
    valid_for: "200 days"

Why This Matters

If ACME expands to non-TLS PKI, it would bring the same automation benefits that transformed TLS certificate management to:

1. Code signing: Automated certificate issuance for CI/CD pipelines
2. S/MIME: Automated email certificate provisioning for enterprise users
3. IoT: Automated device certificate enrollment at scale
4. mTLS: Automated client certificate management for service-to-service auth

The ACME Protocol Roadmap

Current State (RFC 8555)

The current ACME specification (RFC 8555) supports:

• Account management (registration, key rollover)
• Order management (request, finalize)
• Challenge types (HTTP-01, DNS-01, TLS-ALPN-01)
• Certificate issuance and revocation
• Pre-authorization for future issuance

Active Extensions

Several ACME extensions are in development or recently finalized:

ARI (ACME Renewal Information) — RFC 9440

Allows CAs to signal when clients should renew, enabling coordinated renewal timing:

GET /acme/renewal-info/certID

Response:
{
  "suggestedWindow": {
    "start": "2026-09-15T00:00:00Z",
    "end": "2026-09-20T00:00:00Z"
  }
}

This prevents renewal storms where all clients renew simultaneously.

ACME STAR (Short-Term, Automatically Renewed)

Enables ultra-short-lived certificates (hours to days) that are continuously auto-renewed:

star_certificate:
  validity: 24_hours
  auto_renewal: true
  renewal_interval: 12_hours
  use_case: cdn_edge_certificates

DNS-PERSIST-01

Let's Encrypt's proposed validation method that reduces DNS update frequency:

• Set a persistent DNS record once
• CA validates periodically without requiring record changes
• Reduces DNS API calls and propagation-related failures

Future Directions

• ACME for device certificates: IoT device enrollment via ACME
• ACME for S/MIME: Email certificate automation
• ACME + DID/VC: Non-domain identity verification
• ACME for private CAs: Standardized internal CA automation

Implementing Multi-CA ACME in Your Organization

Architecture Pattern

┌──────────────────────────────────────────────────┐
│              CLM Platform (TigerTrust)            │
├──────────────────────────────────────────────────┤
│                ACME Client Layer                  │
│  ┌──────────┬──────────┬──────────┬────────────┐ │
│  │  Account │  Order   │ Challenge│ Certificate│ │
│  │  Mgmt    │  Mgmt    │  Solver  │  Deployer  │ │
│  └──────────┴──────────┴──────────┴────────────┘ │
├──────────────────────────────────────────────────┤
│               CA Router (Policy-Based)            │
│  ┌──────────────────────────────────────────────┐ │
│  │ Rule: *.prod.example.com → DigiCert (OV)    │ │
│  │ Rule: *.staging.* → Let's Encrypt (DV)      │ │
│  │ Rule: internal.* → Step CA (Private)        │ │
│  │ Rule: default → Let's Encrypt (DV)          │ │
│  └──────────────────────────────────────────────┘ │
├──────────────────────────────────────────────────┤
│            ACME Directory Endpoints               │
│  ┌────────────┬──────────┬──────────┬──────────┐ │
│  │ Let's      │ DigiCert │ Step CA  │ Gandi    │ │
│  │ Encrypt    │          │          │          │ │
│  └────────────┴──────────┴──────────┴──────────┘ │
└──────────────────────────────────────────────────┘

Policy-Based CA Selection

Define rules that automatically route certificate requests to the appropriate CA:

ca_routing_policy:
  rules:
    - match:
        domain_pattern: "*.prod.example.com"
        certificate_type: "OV"
      route_to: digicert
      reason: "Production domains require OV validation"

    - match:
        domain_pattern: "*.staging.*"
        certificate_type: "DV"
      route_to: letsencrypt
      reason: "Staging uses free DV certificates"

    - match:
        domain_pattern: "*.internal.example.com"
      route_to: step_ca
      reason: "Internal services use private CA"

    - match:
        default: true
      route_to: letsencrypt
      reason: "Default to Let's Encrypt for DV"

  fallback:
    enabled: true
    primary_to_fallback:
      digicert: letsencrypt
      letsencrypt: zerossl
    reason: "Automatic failover if primary CA is unavailable"

Monitoring ACME Operations

Track these metrics across all ACME endpoints:

Looking Ahead

ACME's expansion from a Let's Encrypt-specific protocol to a universal PKI automation standard is one of the most important developments in certificate management. As the protocol extends to non-TLS use cases and more CAs adopt it, organizations that standardize on ACME today will be positioned to automate their entire PKI — not just TLS certificates.

The next five years will see ACME become to certificate management what APIs became to cloud computing: the standard automation interface that makes everything else possible.

TigerTrust provides multi-CA ACME automation with policy-based routing, automated deployment, and comprehensive monitoring. Standardize your certificate automation at tigertrust.io.