Public certificates over ACME

Skyrsoft CertOps can act as an ACME client, obtaining certificates from publicly-trusted certificate authorities for internet-facing services — separate from the internal CA hierarchy used for agent, EST and SCEP enrolment. It supports three CAs: Let’s Encrypt, ZeroSSL and Google Trust Services. Domain control is validated automatically, either by writing a DNS record through one of three supported providers or by serving a token from CertOps’s own web server. CertOps holds the private key for every certificate obtained this way, which is what makes it deployable to servers and appliances rather than usable only where it was issued.

How it works

ACME defines two ways to prove control of a name, and for a product that issues certificates on behalf of other machines they are not equally useful.

CertOps typically obtains a certificate for a load balancer, firewall or IIS server and then pushes it out to that target — the name belongs to another machine, not to CertOps. DNS-01 is the default for exactly that reason: the CA is satisfied from your DNS zone regardless of where the name actually points. HTTP-01 only makes practical sense for a certificate covering the CertOps server itself, where the name does resolve here, and only when it does not need to cover a wildcard or a second name.

# a certificate for an internet-facing load balancer, obtained over ACME
ACME order (Let’s Encrypt) for portal.example.com
dns-01 validated via Cloudflare
issued & auto-renewing · deployed to IIS and the load balancer

ACME certificate authorities

ZeroSSL and Google Trust Services

ZeroSSL and Google Trust Services are offered as presets alongside Let’s Encrypt, and both are free and publicly trusted. Each requires External Account Binding — a one-time key ID and HMAC key pair generated on the CA’s own dashboard and pasted into CertOps when the account is added. Let’s Encrypt needs no such step. Google Trust Services also offers a genuine staging environment that chains to an untrusted test root, useful for exercising the issuance flow without spending a production quota.

CertOps retries a request automatically on a gateway error (502, 503, 504, 429) or a timeout, fetching a fresh nonce each time, so a single blip does not fail an order. That matters most against ZeroSSL: its newNonce endpoint answers a HEAD request with 502 rather than the response RFC 8555 requires, so CertOps requests a nonce with HEAD first and falls back to GET. Independent of that fix, ZeroSSL’s own gateway returns a meaningful rate of transient errors on top. An order against it can occasionally take more than one attempt before it lands; that is ZeroSSL’s own error rate, not a sign that something is misconfigured.

DNS-01 providers

CertOps writes and removes the _acme-challenge TXT record automatically for three DNS providers: Cloudflare, AWS Route 53 and Azure DNS. Leaving the zone field blank behaves differently by provider — Cloudflare and Route 53 resolve the zone from the domain name automatically, with one extra API call, while Azure enumerates the zones in the configured resource group to find the one that actually contains the name. A DNS-01 order pointed at a provider that does not host the target zone now fails within a few seconds, rather than sitting in a pending state waiting for a record that was never going to appear — but what the failure says differs by provider. Azure and Route 53 name the zone they actually found instead of the one requested (Route 53 quotes AWS’s own rejection message verbatim); Cloudflare instead reports finding no active zone for the domain at all in that token’s account, since it never resolves to a specific — merely wrong — zone the way the other two do.

HTTP-01

HTTP-01 is deliberately de-emphasised. CertOps exists to obtain certificates for machines other than itself, and HTTP-01 can only be answered by whichever server the name resolves to — so it is only useful for a certificate covering this CertOps server’s own hostname, and even then it needs inbound port 80 reachable from the internet. HTTP-01 is refused outright for a wildcard name: there is no file that can prove control of every name under *.example.com, so typing a wildcard as the common name or a SAN greys out the option in the order form and switches to DNS-01, and an API caller that requests the combination directly gets a 400 naming the offending name.

Limits

HTTP-01 cannot issue a wildcard certificate, on any CA. This is a protocol limit, not a CertOps one — Let’s Encrypt, ZeroSSL and Google Trust Services all reject such an order, so DNS-01 is mandatory for any name starting with *..

A certificate covering more than one name is DNS-01 only in the order form, but that guard is a practical one rather than an enforced protocol rule — a multi-name HTTP-01 order is legal ACME if every name genuinely resolves to this server. The form blocks it as a guard rail; the API does not.

ZeroSSL has a meaningful gateway error rate independent of anything CertOps does. Retries absorb most of it, but an order against ZeroSSL can still take longer, or need a second attempt, compared with Let’s Encrypt.

A Google Trust Services external account key is single-use at registration. Each key covers exactly one ACME account; registering a second account needs a fresh key from the Google Cloud project.

ACME-issued certificates count against the same certificate pool as everything else — agent, EST, SCEP, portal and private-CA issuance all draw from one number, not a separate ACME-specific limit. Free’s pool is fixed at 10 across all of them combined; Pro’s pool is sized to the count you purchase — see pricing — not unlimited.