Hierarchy
A root CA is self-signed. It signs only subordinate CAs, never certificates for servers or clients, so day-to-day issuance never uses the root’s key and an issuing CA can be replaced without touching the root.
A subordinate CA is signed by:
- a CA in the same project (a hosted subordinate), or
- your own existing root outside EZGH (an external subordinate): EZGH creates its key and a certificate signing request, your root signs it, and you import the result.
Hierarchies are at most three levels deep inside EZGH: root, intermediate, issuing. A CA’s path length says how many CA levels may sit below it, as its certificate states it: a root’s is 1 by default (issuing CAs below it), 2 to allow an intermediate between them, or -1 for no limit in its certificate (EZGH still allows three levels). A subordinate’s is lower than its parent’s: 0 (the default) for an issuing CA, which signs only certificates.
Fixed at creation
A CA’s subject, key algorithm (ecdsa-p256, ecdsa-p384, rsa-2048, rsa-3072 or rsa-4096),
path length, name constraints and validity can’t change. Its name, description and tags can, and
its longest certificate (maxLeafValidityDays, subordinates only) can be shortened. A new key
means a new CA; renewing a CA reissues its certificate for the same key, subject and
constraints.
Name constraints
Name constraints limit the names every certificate under a CA may hold: permitted and excluded DNS
names (a host or .domain), IP ranges (CIDR), email addresses (a mailbox, host or .domain) and
URIs (a host or .domain). A hosted subordinate’s constraints are within its parent’s. EZGH checks
every certificate against them before signing, and clients check them when they verify.
Profiles
A certificate’s extensions come from its profile, never from a CSR:
| Profile | Key usage | Extended key usage |
|---|---|---|
tlsServer |
Digital signature (and key encipherment for RSA) | Server authentication |
tlsClient |
Digital signature | Client authentication |
tlsServerClient |
Digital signature (and key encipherment for RSA) | Server and client authentication |
Every certificate carries its CA’s CRL, OCSP and CA certificate URLs on pki.ezghcloud.com. On
tlsServer and tlsServerClient, a common name that looks like a host name must be one of the
certificate’s DNS names.
States
| State | Meaning |
|---|---|
creating |
Its key is being generated and its certificate signed |
pendingCertificate |
An external subordinate waiting for you to import its certificate |
active |
It signs |
disabled |
It signs nothing, including managed renewals; its CRLs and OCSP are still published |
pendingDeletion |
Scheduled for deletion; restore it before the date to keep it |
deleted |
Its key is destroyed; its CRLs and OCSP are served until its certificate expires |
failed |
It couldn’t be created; delete it |
A subordinate revoked through its parent stays
disabled for good, with revokedAt and revocationReason set.
Trust
Clients trust a private CA’s certificates only where its root certificate is installed: in an
operating system’s or browser’s trust store, a container image, a Kubernetes trust bundle, or your
client’s CA file. Download it from the CA’s CA certificate tab in the console,
ezgh private-ca ca get <root> -o json, or http://pki.ezghcloud.com/ca/<root ID>.crt (DER).
Serve each certificate with its chain (the issuing CA and any intermediate), which the API, console
and CLI give alongside it.
Private certificates aren’t logged to Certificate Transparency: they aren’t publicly trusted, so no browser requires it.