8.4 Bring Your Own Root

Bring your own root chains CertKit to a root CA you already operate — Active Directory Certificate Services, an offline openssl root, an HSM-backed appliance. CertKit generates a subordinate CA key and a certificate signing request; your CA signs it; CertKit issues from the resulting subordinate.

This mode is built for organizations with an established internal PKI:

• No trust rollout. Certificates chain to a root your devices already trust. Trust distribution is unnecessary so the CertKit agent does not install to the trust store.
• Your root key never touches CertKit. CertKit holds only the subordinate key. The root stays wherever it lives today — offline, in an HSM, in AD CS.
• Full automation below the root. Issuance, renewal, deployment, and revocation for the subordinate’s certificates are handled by CertKit exactly as for any other private CA.

Setting up

1. Create the CA. Choose Bring your own root on the Add Certificate Authority page. CertKit generates the subordinate’s private key — which is encrypted and never leaves CertKit — and a CSR requesting a subordinate CA profile: CA:TRUE with a path length of 0, Certificate Signing and CRL Signing key usages, and any name constraints you configured.

2. Sign the request with your CA. Use a subordinate CA template:

• AD CS — submit the CSR against the built-in Subordinate Certification Authority template.
• openssl — the setup page includes an example. Note that openssl x509 -req discards requested extensions unless you pass them back with -extfile; without it you get an end-entity certificate, which CertKit will reject.

3. Import the signed certificate. Paste or upload what your CA returns — PEM, DER, and PKCS#7 (.p7b) are all accepted, as a single certificate or a full chain. Include the chain up to your root if your CA provides it, so CertKit can verify and display the complete hierarchy.

Import validation

CertKit validates the certificate before activating the CA:

Check	Requirement
Key match	The certificate must be issued for the exact CSR CertKit generated.
Basic constraints	CA:TRUE — an end-entity certificate is rejected.
Key usage	Certificate Signing and CRL Signing (a certificate with no key usage extension is unrestricted and accepted). Without CRL Signing, revocation checking would fail for every certificate the CA issues.
Validity	Currently valid — neither expired nor post-dated.
Chain	When the root is included, the chain must cryptographically verify.

Until a certificate is imported, the CA is Pending and cannot issue.

Deeper hierarchies

Your root does not have to sign the subordinate directly. If the chain runs root → policy CA → CertKit subordinate, include the intermediate certificates when importing. CertKit stores them and delivers them with every issued certificate, so servers always present a complete chain up to your root.

Root and chain handling

When you supply your root certificate, CertKit records it for display and chain verification only. A bring-your-own root is never published at the public root URL and never distributed to agents — distribution of that root is presumed to be already handled some other way.

The subordinate’s own CRL and AIA endpoints are hosted by CertKit as usual: certificates issued by the subordinate point at CertKit’s CRL. Revocation of the subordinate certificate itself is governed by your CA’s own revocation infrastructure.

Renewal

The subordinate’s validity is whatever your CA granted it. As expiry approaches, CertKit warns on the CA’s details page. Renewing generates a fresh key and CSR under the same root — the current subordinate continues issuing until you import the newly signed certificate, at which point issuance switches over and the previous subordinate remains active to serve its CRL. One renewal request can be outstanding at a time.

Automatic issuing CA rotation does not apply to bring-your-own-root CAs: CertKit holds no root key, so replacing the subordinate always requires your CA to sign a new request.

Name constraints

Configured constraints are requested in the CSR, but many CAs apply their own template and strip requested extensions. This does not weaken enforcement: CertKit validates every certificate it issues against the CA’s constraints server-side, whether or not your CA kept the extension in the subordinate certificate.