Create a CA | EZGH Cloud

Create a root and its issuing CA, or a subordinate signed by a root you already have.

You need certificates.certificateAuthorities.create in the project, and certificates.certificateAuthorities.issue on the parent of a hosted subordinate. CertificatesFullAccess has both. A project holds up to 10 CAs.

A root and its issuing CA

Open Private CA › Certificate authorities and choose Create certificate authority.
Choose Root CA, give it a name and subject, a key algorithm (ECDSA P-384 is common for roots), a validity of 1 to 25 years, and any name constraints. Review and create it.
The dialog continues with Create issuing CA, the root preselected. Give it a name, its longest certificate (up to 825 days) and any narrower name constraints, and create it once the root is active.

ezgh private-ca ca create --name corp-root --type root \
  --key-algorithm ecdsa-p384 --common-name "Corp Root" --organization Corp --wait
ezgh private-ca ca create --name corp-issuing --type subordinate --parent corp-root \
  --common-name "Corp Issuing" --permitted-dns corp.example --max-leaf-validity-days 90 --wait

--wait waits until each CA is active: generating its key and signing its certificate takes a few seconds.

CreateCertificateAuthority answers 202 with the CA (creating) and the operation that finishes it; follow the operation with GET /v1/organizations/<org>/operations/<id> until finishedAt is set, or read the CA until its state is active.

curl -X POST "https://certificates.ezghcloud.com/v1/organizations/$ORG/projects/$PROJECT/certificate-authorities" \
  -H "Authorization: Bearer $EZGH_API_KEY" -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"name": "corp-root", "type": "root", "keyAlgorithm": "ecdsa-p384",
       "subject": {"commonName": "Corp Root", "organization": ["Corp"]}, "validityDays": 3650}'

A hosted subordinate adds "type": "subordinate", "parentId": "<root ID>", and optionally "maxLeafValidityDays" and "nameConstraints": {"permittedDns": ["corp.example"]}.

Then install the root’s certificate wherever its certificates must be trusted (see Trust).

A subordinate signed by your own root

If you already run a root CA, EZGH can host an issuing CA under it. EZGH generates the key and a certificate signing request; your root signs it; you import the signed certificate and the chain above it.

Create the subordinate as external, with the subject and name constraints your root will sign:

ezgh private-ca ca create --name corp-issuing --type subordinate --external \
  --common-name "Corp Issuing" --organization Corp --permitted-dns corp.example
ezgh private-ca ca csr corp-issuing > corp-issuing.csr

It waits in pendingCertificate. In the console, the CSR is on its CA certificate tab.

Sign the CSR with your root as a CA certificate. With OpenSSL:

cat > issuing-ext.cnf <<'CONF'
basicConstraints = critical, CA:TRUE, pathlen:0
keyUsage = critical, keyCertSign, cRLSign
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
nameConstraints = critical, permitted;DNS:corp.example
CONF
openssl x509 -req -in corp-issuing.csr -CA root.crt -CAkey root.key -CAcreateserial \
  -days 1825 -sha256 -extfile issuing-ext.cnf -out corp-issuing.crt

The certificate must keep the CSR’s subject exactly, allow keyCertSign and cRLSign, carry a subject key identifier, match the path length and name constraints you asked for, and not outlive the certificates above it. Leave out extended key usage, or allow both server and client authentication.

Import it with the chain up to your root, nearest first:
```
cat corp-issuing.crt root.crt > signed.pem
ezgh private-ca ca import corp-issuing --chain signed.pem --wait
```
In the console, use Import certificate on the CA’s page. EZGH checks the key, subject, constraints and chain, and the CA becomes active.

EZGH never needs your root’s key. The chain you import is served with every certificate the subordinate issues. Revoke an external subordinate from your own root.

After it’s created

Disable a CA to stop it signing; its CRLs and OCSP keep being published. Enable it to sign again.
Renew a CA to reissue its certificate for the same key (ezgh private-ca ca renew), then install the new certificate where the old one is.
Delete a CA to stop it signing now; its key is destroyed when the deletion window (7 to 30 days, 30 by default) ends. Until then, Restore cancels the deletion, and the CA comes back disabled. A CA can’t be deleted while it has active subordinates, or managed certificates that renew from it: delete those first.