Issue certificates

Certificates come from an active subordinate CA: roots sign only subordinate CAs. You need certificates.certificateAuthorities.issue on the CA. Each certificate gets a profile (tlsServer, tlsClient or tlsServerClient), a validity of at most the CA’s longest certificate and never past the CA’s own expiry, and up to 100 names (DNS names, IP addresses, URIs such as SPIFFE IDs, and email addresses) within the CA’s name constraints.

From a CSR

Your key never leaves your machine. Only the CSR’s public key, common name and names are used; the extensions it asks for are ignored, and --san (or the API’s sans) replaces its names.

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout api.key -subj "/CN=api.corp.example" \
  -addext "subjectAltName=DNS:api.corp.example" -out api.csr
ezgh private-ca ca issue corp-issuing --csr api.csr --profile tlsServer --validity-days 30 --out api.pem

api.pem holds the certificate, then its chain. A CSR is usually signed at once (IssueCertificate answers 201); if not, it answers 202 with an operation, and the certificate follows within seconds. In the console, open the CA and choose Issue certificate › Paste a CSR.

From a generated key

EZGH generates the key, keeps it, and exports it only encrypted with your passphrase:

ezgh private-ca ca issue corp-issuing --generate-key ecdsa-p256 \
  --san dns:worker.corp.example --san uri:spiffe://corp.example/worker --profile tlsClient
ezgh private-ca certificate export-key <certificate ID> --out worker.key --certificate-out worker.pem

export-key asks for the passphrase twice (12 to 1,024 characters), or reads it from --passphrase-file. The key is PKCS#8, encrypted with PBES2 (AES-256-CBC, PBKDF2-HMAC-SHA256 with 600,000 iterations). To use it unencrypted:

openssl pkey -in worker.key -out worker-plain.key

Exporting needs certificates.privateCertificates.exportKey, which no managed policy grants, and every export is recorded in Trails. EZGH keeps the key until you forget it (ezgh private-ca certificate forget-key), delete the certificate, or 30 days after it expires. Copies you exported keep working after that.

Find certificates

The console’s Private CA › Certificates lists every certificate the project’s CAs issued, from any path (CSR, generated key, managed certificate or ACME), newest first: its name, CA, status (Issued, Revoked or Expired), key source, expiry and serial. Filter it by CA, status, key source or expiry (expiring in 7, 30 or 90 days), or search by part of a common name or SAN, or the start of a serial; the filters stay in the page’s URL, so you can share a filtered list. A CA’s Issued certificates tab lists that CA’s.

ezgh private-ca certificate list                                   # every CA's
ezgh private-ca certificate list --status issued --search corp.example
ezgh private-ca certificate list --ca corp-issuing --key-source acme

Listing across the project needs certificates.privateCertificates.listAll (ListAllPrivateCertificates); one CA’s own list needs certificates.privateCertificates.list on it.

Revoke and delete

• Revoke a certificate with a reason (unspecified, keyCompromise, affiliationChanged, superseded or cessationOfOperation): see Revocation. Revoking for keyCompromise also destroys a key EZGH holds. Revocation is final.
• Delete a certificate’s record to tidy the list. The certificate stays valid until it expires (revoke it first if clients should stop trusting it), and its serial stays in its CA’s revocation data.

Records of expired certificates are removed a year after they expire.