Hub — certificate providers

A renewal profile issues certificates against a provider: an ACME (RFC 8555) certificate authority the Hub is configured to talk to. Cyphers ships five built-in providers and lets you register any additional RFC 8555 CA as a custom provider. This page covers both, plus what changes about renewal and certificate-authority rotation once more than one provider is in play.

What a provider is

Every provider row carries:

• a directory URL (and, for providers that publish one, a separate staging directory URL) — the ACME endpoint the Hub's client talks to;
• a CAA issuer domain — the domain name the Hub expects to find in a CAA record authorizing this CA to issue for a hostname;
• an optional External Account Binding (EAB) key ID + HMAC secret, for providers that require you to link your CA account before issuing.

A renewal profile picks one provider. ACME accounts are not something you create directly: the Hub registers one lazily, keyed by (email, provider, environment), the first time a profile with that combination issues. Two profiles that agree on all three share one account — which is what you want, since a CA's rate limits and its ARI renewal history are tracked per account, not per profile.

Built-in providers

Provider	Directory	Staging	EAB	CAA record to publish
Let's Encrypt	acme-v02.api.letsencrypt.org	yes	not required	0 issue "letsencrypt.org"
ZeroSSL	acme.zerossl.com/v2/DV90	no	required	0 issue "sectigo.com"
Google Trust Services	dv.acme-v02.api.pki.goog	no	required	0 issue "pki.goog"
SSL.com (RSA)	acme.ssl.com/sslcom-dv-rsa	no	optional	0 issue "ssl.com"
SSL.com (ECDSA)	acme.ssl.com/sslcom-dv-ecc	no	optional	0 issue "ssl.com"

SSL.com ships as two provider rows because it publishes separate ACME directories per key family: SSL.com (RSA) only issues against an RSA-keyed profile and SSL.com (ECDSA) only against an ECDSA-keyed one. The profile editor enforces the match — pick the row for the key type your profile actually uses.

SSL.com's directories advertise EAB as optional, not required — its externalAccountRequired metadata reports false, so registration succeeds with nothing stored. If you do store EAB credentials on the SSL.com row (Settings → Certificate Providers), the Hub sends them at account registration regardless — the Hub attaches EAB whenever credentials are stored, not only when the provider demands them. Enter them only if your account setup requires it; leave both fields blank otherwise.

Getting EAB credentials

• ZeroSSL — the Hub can fetch these for you. Select ZeroSSL under Settings → Certificate Providers, enter a contact email, and press Fetch from ZeroSSL: the Hub calls ZeroSSL's credential API, and the key ID and HMAC secret go straight to encrypted storage. The key ID is shown back afterward in Settings (Configured (kid …)) so you can confirm which credential is configured; the HMAC secret is never displayed (see Operational notes below). No dashboard visit and no signup step — ZeroSSL issues reusable credentials against the email alone. (The manual form stays available for credentials you already hold, e.g. from the Developer section of the ZeroSSL dashboard.) The Hub reaches api.zerossl.com for this, which is a different host from the ACME directory — a firewalled install needs it allowed.
• Google Trust Services — mint one with gcloud publicca external-account-keys create (Google Cloud CLI, Public CA API enabled on the project). GTS EAB keys are single-use and expire unused — you cannot reuse one to re-register an account later; a re-register always needs a freshly minted key. That is also why the Hub does not fetch them for you: a key minted now would likely be dead before it was used.
• SSL.com — the ACME credentials panel in your SSL.com account dashboard. Optional (see above) — only needed if your account setup requires it, but the Hub will use whatever you enter either way.

Enter what you get on the provider's row under Settings → Certificate Providers.

ARI

All five directories above currently advertise ACME Renewal Information (ARI, renewalInfo) support. That is a fact about the CA's directory, not a promise about what the Hub does with it yet: in this phase, the Hub's ARI refresher only polls Let's Encrypt. Certificates from every other provider — ZeroSSL, Google Trust Services, both SSL.com rows, and any custom provider — fall back automatically to the renewal profile's own parametric renewal window instead of an ARI-driven one. Nothing you need to configure; renewals still happen on schedule.

Phase-1 boundary

• HTTP-01 profiles stay on Let's Encrypt. Choosing a different provider on an HTTP-01 issuance path is refused — Scout-side HTTP-01 issuance against arbitrary providers is a later phase. Use a DNS-01 validation method for every other provider.
• DNS-01 profiles support every provider, built-in or custom, on both DNS-01 lanes: manual (you publish the _acme-challenge TXT record by hand) and automatic (the Hub publishes it through your configured DNS provider's API, waits for it to become visible, and removes it afterwards). A profile saved earlier may show a third option labelled DNS-01 (Automatic via API — legacy "delegated"): delegation no longer exists, and the verb runs the identical code against the same Hub-held DNS provider as the automatic lane. See Renewal lanes.
• Wildcard issuance needs DNS-01, regardless of provider — that constraint is unchanged and applies the same way to every provider on this page.

Key types and private-key reuse on the DNS-01 lanes

A renewal profile names a key type (ecdsa_p256, ecdsa_p384, rsa_2048, rsa_4096). On the Hub-driven DNS-01 lanes (and the built-in CA), the Scout never generates a fresh RSA key — fresh keys on those lanes are always ECDSA. An RSA-keyed profile is honored there through key reuse: with Reuse private key across renewals enabled on the profile, the renewal reuses the RSA key the endpoint already holds, provided its modulus size matches the profile's key type (rsa_2048 ↔ 2048-bit, rsa_4096 ↔ 4096-bit). That is how an endpoint with a published pin (HPKP/DANE) keeps its RSA key across renewals. If the endpoint's key is not yet under management, the one-time Adopt key action copies it into the Scout's managed storage first — see Scout — commands. (HTTP-01 issuance is different: that lane generates whatever key type the profile names, RSA included.)

Prevalidated domains

Some orders arrive with nothing left to validate: the CA already holds valid authorizations for every domain — for example a CA that has prevalidated your domains as part of an organization-validated (OV) setup, or any ACME CA reusing authorizations it validated recently. The Hub handles this per authorization: only pending authorizations get a DNS-01 challenge; already-valid ones are skipped.

On a manual DNS-01 profile this means an order can park with zero TXT records to add. The Manage drawer then shows Complete renewal — "No DNS records are required" — and the Hub's DNS watchdog, which re-checks parked orders every 30 seconds, completes the order automatically: the certificate is finalized and delivered within about half a minute of the Renew click, with no DNS work at all.

On a per-certificate-billed CA, Renew Now is the paid action

With every domain prevalidated there is no TXT step between clicking Renew Now and finalization — and no second confirmation. On a CA that bills per certificate, treat the click itself as the purchase.

When TXT records are required, the manual-DNS park has a 5-minute timeout: if the records are not placed and verified within 5 minutes of the renewal starting, the renewal fails and the order is left unfinalized — on a per-certificate-billed CA nothing has been bought — and Renew can simply be clicked again later, once the records are ready to place.

Custom providers

Any RFC 8555-compliant CA can be registered as a custom provider from Settings → Certificate Providers. (For the full end-to-end procedure — register, EAB, profile, adopt, renew — see How-to → Renew through a paid / third-party CA.) Required fields:

Field	Notes
Provider ID	Lowercase slug, 1-64 characters, [a-z0-9-] only.
Display name	Shown throughout the dashboard and in preflight/remedy messages.
Directory URL	Must start with https://.
Staging directory URL	Optional; if set, must also start with https://. Profiles may only use staging: true against a provider that has one.
CAA issuer domain	Required.
Requires EAB	Checkbox — controls only whether registration hard-refuses with nothing stored. You may enter EAB credentials on any provider row regardless of this checkbox; the Hub attaches whatever is stored at registration either way.

Why the CAA issuer domain is mandatory: the Hub's CAA preflight is fail-closed. Before ordering, it checks each domain's CAA records; if one authorizes issuance to a name other than the provider you configured, the order is refused rather than proceeding against a CA the domain owner didn't authorize. Without a declared CAA issuer domain, the Hub would have nothing to compare a published CAA record against, so the field cannot be left optional.

A custom provider starts with ARI marked unsupported — the Hub has not observed a renewalInfo endpoint on a directory it doesn't already know — so its certificates always use the profile's parametric renewal window.

Deleting a provider: built-in rows can never be deleted. A custom row deletes only while nothing references it — no renewal profile and no registered ACME account. Either reference refuses the delete and names the blocker.

Operational notes

• The CAA preflight uses the host's resolvers. It resolves through the DNS servers the Hub host is configured with (its system resolver configuration), not a hardcoded public resolver — so split-horizon zones and egress-filtered networks behave: what the Hub checks is what your network actually resolves. Only if the system resolver configuration is unreadable does the Hub fall back to the resolver library's default.
• The DNS-01 TXT pre-verification does not, and this is deliberate. Both the automatic lane's propagation wait and the manual lane's Verify check resolve the challenge zone's NS records and then query those authoritative nameservers directly, with caching disabled — falling back to the system resolver only when the zone's nameservers cannot be determined. A challenge record carries a 120-second TTL, so a recursive resolver can keep serving a previous challenge value for longer than the automatic lane's whole budget, while the CA — resolving from the root — sees the new one. Checking through a cache made the pre-check stricter than the validation it protects and blocked an order that would have passed. It does mean the Hub needs outbound DNS on port 53 to internet nameservers; see Hub — install.
• EAB is write-only. Once you save a provider's EAB key ID + HMAC, Settings shows only that a secret is set, never the secret itself.
• EAB secrets are encrypted under the CA passphrase, the same envelope discipline as stored ACME account credentials, tagged so one can't be swapped for the other. CA passphrase rotation (cyphers-hub rotate-ca-passphrase) does not re-wrap them. After a rotation, every provider's stored EAB secret is sealed under the old passphrase and can no longer be decrypted. Recover by, for each provider that had EAB configured:
  1. Re-entering its EAB key ID + HMAC in Settings → Certificate Providers.
  2. Re-registering any ACME account that used it.
  3. For Google Trust Services specifically: mint a fresh EAB key first (gcloud publicca external-account-keys create) — the old key is single-use and cannot be reused for the re-register.
• Duplicate-certificate preflight is per provider. Let's Encrypt limits identical certificates to 5 per 7 days, and the Hub's preflight warns as you approach that limit and blocks past it. The other built-in providers don't publish an equivalent duplicate-name limit, so the Hub skips that specific check for them — any quota limit they do enforce surfaces as an ordinary issuance/retry error instead of a preflight finding.