Import (bring-your-own)

Import a certificate that was issued outside CertAutoPilot — a vendor wildcard, an enterprise/offline CA, or a partner-supplied cert — and manage it like any other certificate for everything except issuance and renewal. Once imported it can be distributed and bound to targets, downloaded (PEM/PFX/JKS/DER), and shows up in risk scoring, the timeline, and expiry views.

There is no CA behind an imported certificate, so it is exempt from every renewal-automation path. "Renewal" is you re-importing a fresh certificate — the old version is kept in history.

What you provide

Field	Required	Notes
Certificate (leaf)	Yes	PEM. A full-chain bundle (leaf + intermediates) is also accepted here.
Chain / intermediates	Recommended	PEM. Needed so chain-dependent targets validate. The root CA is excluded from the served chain automatically if you include it.
Private key	Yes	PEM, and it must match the leaf. Passphrase-protected keys are not supported — decrypt first. Stored envelope-encrypted.
Name / Owner / Description	Name required	Metadata only.

Chain handling

Classification is leaf-order-independent — paste the blocks in any order:

• The leaf is the certificate whose public key matches the uploaded private key.
• Intermediates are the non-leaf CA certificates, re-ordered leaf → up.
• A self-signed root, if present, is excluded from the distributed chain (trust anchors belong in the client's trust store, not the served chain). Its expiry is still captured for the expired-root-CA risk signal.
• Leaf-only uploads are accepted with a warning — some targets are fine with a leaf-only chain; chain-dependent ones need the intermediates.

How to import

1. Certificates → Import (button beside Issue Certificate).
2. Paste the leaf, optional chain, and the matching private key; give it a name.
3. Submit. The certificate is stored and becomes active immediately (synchronous — no job, no CA round-trip), tagged Imported.

You can also POST /api/v1/projects/{projectId}/certificates/import with a JSON body (name, cert_pem, chain_pem?, key_pem, owner?, description?). Requires the Admin role and consumes a certificate license slot.

Why Admin, not Operator

Import makes a certificate active and distributes it immediately, without going through the issuance-approval workflow. Requiring Admin prevents a non-privileged operator from using import to bypass an org's "require approval for issuance" control.

Refreshing — re-import

When the certificate nears expiry (you still get expiry notifications), open its detail page and click Re-import, or POST …/certificates/{id}/reimport with a fresh cert_pem/key_pem (Admin role). This creates a new current version; the previous version is retained in the certificate's history (subject to the history-retention setting), and distribution targets are re-triggered automatically. Re-import only works on an already-imported certificate.

The domains, primary domain, and key type are re-derived from the new leaf on every re-import, so a refresh whose SANs or key algorithm changed stays accurate.

Re-importing with different domains + templated paths

If you re-import a certificate whose domains differ from the original and its SSH/WinRM distribution uses a ${{ CAP_PRIMARY_DOMAIN }} / ${{ CAP_DOMAIN_SLUG }} variable inside a file path, the new domain renders a new path: the file is written there and the old-path file is left behind (these two modules don't reconcile old paths). Auto-named object modules (F5/NetScaler/Vault/Kubernetes) are unaffected — they reconcile the rename via per-certificate state. For a same-domain refresh (the normal case) nothing changes.

What is exempt

Imported certificates are deliberately excluded from CA-driven automation:

• No auto-renew — auto_renew is forced off and the renewal/rescue/ARI scheduler sweeps skip them.
• Manual Renew / Re-issue / Revoke are rejected (there is no CA to renew or revoke against). Use Delete to retire an imported certificate, and Re-import to refresh it.
• Certificate policy is not evaluated on import — an import records an external fact rather than requesting issuance.

What still applies: it flips to expired when it passes its notAfter, expiring-soon notifications fire (prompting a re-import), and distribution, download, risk, and timeline all work unchanged.

Corner cases

• Key does not match the leaf, malformed PEM, or a missing key → rejected (422).
• Passphrase-encrypted key → rejected with a clear message; decrypt it first.
• Already-expired leaf → rejected (distribution needs an active cert; re-import is the refresh path).
• Expired intermediate in the chain → rejected — the served chain would be broken; re-bundle the current intermediate.
• Too many certificates in the upload (more than 16 PEM blocks) → rejected; provide only the leaf and its intermediates.
• Weak/non-standard key (e.g. RSA-1024) → accepted (policy is skipped); it surfaces through risk scoring instead.
• Ed25519 key → accepted, but stored with a non-standard key-type label the UI/policy don't recognize; public CAs don't issue Ed25519 TLS certs, so it's outside the supported set.