X.509 over ACME
Internal TLS certificates, ordered with the protocol every client already speaks.
Hosts order TLS certificates by speaking RFC 8555 to
<public-url>/acme/directory. No Cardinal-specific client: certbot, lego,
acme.sh and Caddy all work, because the point of choosing ACME was to write
no client at all.
cardinal x509 ca init -subject "Cardinal Internal CA"
cardinal x509 ca list
cardinal x509 ca trust # every trusted certificate, PEM
cardinal x509 ca rotate <key-id>
cardinal host acme-credentials web-01 # external account binding for one machine
Distribute first, then rotate to it
A new authority is not signing until it has been distributed and rotated to. That order is deliberate: a CA nothing trusts, issuing certificates everything rejects, is a worse failure than not having one.
Nothing is issued for a name the directory has not granted
Whatever the CSR asks for. The external account binding ties an ACME account to an enrolled host, so ordering a certificate for a name is subject to the same question as proving that name over SSH: a machine cannot ask for a certificate for a name that belongs to a different machine.
Verified against a client nobody here wrote
The claim that this is really ACME is checked by driving it with lego rather
than by Cardinal agreeing with Cardinal. Everything else in the suite is the
project talking to itself; this one is not.
Limits
- No revocation list and no OCSP responder. Rotation is the answer, and for a TLS certificate that is a real gap rather than a comfortable one.
- One authority, rotated. No intermediate hierarchy, no cross-signing.
- The signing key lives in the database, sealed with a configured encryption key. No HSM, no PKCS#11.