How Anchor's ACME Relay Works

Anchor's public certificate relay provides the management and insight to use ACME at scale, without the risk and complexity of DIY.

Background

The Automatic Certificate Management Environment (ACME) protocol automates obtaining and managing the X.509 certificates needed for TLS encryption. It has near ubiquitous support across languages and frameworks, but it remains painful and risky to maintain the complexity on your own, especialy as you scale. If you would like to take a deeper dive, start with RFC 8555 (opens in a new tab).

DNS based domain validation (DNS-01 Challenges (opens in a new tab) in ACME terms) is a popular way to provision certificates, but it has drawbacks:

• ACME clients require write access to your DNS zone during certificate provisioning.
• CA credentials (ACME Accounts (opens in a new tab)) are usually overly permissive: default permissions are typically the entire DNS zone including all subdomains.
• Additional services and automation are often required to securely distribute certificate and private key material, adding operational burden.
• Manipulating DNS records from multiple places can cause coordination and split-brain problems.

Anchor uses delegated DNS validation: you assign ACME DNS responsibility to Anchor ahead of time, and we manage the in-flight DNS records for the ACME workflow. It's a lot like acme.sh’s DNS alias mode (opens in a new tab), except we manage it all for you. Anchor also uses ACME’s External Account Binding (EAB) tokens (opens in a new tab) to pre-authorize all orders for their identifiers, so your client won’t need to deal with ACME challenges.

Delegated DNS provides better visibility, simplified configuration, and faster provisioning. Combined with ACME request relaying, provisioning certificates with Anchor is also more secure and more reliable.

ACME Relay Workflow

When you use Anchor to provision a public certificate, your ACME client interacts with Anchor's ACME API instead a public CA.

Relaying ACME simplifies certificate creation for ACME clients:

1. Your ACME client loads an EAB token scoped to alice.anchor-demo.app, and initiates an ACME order for alice.anchor-demo.app to the Anchor ACME API.
2. If the order passes Anchor’s fine-grained authentication checks, an equivalent order is created with a public CA.
3. While your ACME client waits, Anchor manages DNS records and orchestrates the public CA workflow to get your certificate order ready.
4. Once ready, your ACME client finalizes the order by sending a Certificate Signing Request (CSR) (opens in a new tab) for alice.anchor-demo.app, which Anchor relays to the public CA.
5. When the public CA finishes generating the certificate, Anchor downloads & stores it, ready for your ACME client to fetch.

Anchor's ACME Relay provides a number of advantages:

• Anchor tracks ACME protocol improvements, unlocking features like shorter certificate lifetimes, automatic renewal, and more. These features are available via Anchor even if your ACME client does not support them.
• Enhanced security designed for deployments in non-cleanroom environments like IoT, edge and field deployments, and on-prem cloud.
• Supports CA failover, so an outage in a single public CA won’t break or stall your automation.
• Centralizes administration via the dashboard. For example, revoking lost or inaccessible certificates.

Signup and join the waitlist (opens in a new tab) right now, and be one of the first to experience how Anchor’s effortless encryption with public certificates.