Issuance walkthrough

Every form field on the New Certificate page, what it does, and what happens after you click Submit. Includes key-type guidance, policy enforcement, manual DNS, and CSR upload.

01Form fields

FieldRequiredNotes
IssueryesAn ACME account or AD CS profile in the current project.
Common nameyesThe primary subject. Must match a registered zone or have an explicit DNS challenge override.
SANsnoUp to 100. Each must also resolve to a zone or override.
Key typeyesECDSA P-256 / P-384, RSA 2048 / 3072 / 4096.
Auto-renewyesDefault on. Renewal window configurable.
Distribution targetsnoList of pre-configured targets to push to on every successful issuance/renewal.
Approval requiredpolicyForced on by project policy if applicable.

02Choosing a key type

  • ECDSA P-256 — the right default. Smallest, fastest handshake, lowest CPU, supported everywhere modern.
  • ECDSA P-384 — for higher-assurance use cases. Same wins, larger margin.
  • RSA 2048 — when a downstream device only speaks RSA (older F5 partitions, ancient JVMs).
  • RSA 3072 / 4096 — only when a compliance regime demands it. Significantly slower TLS handshake.

03Policy enforcement

Project policies can restrict the form before submission:

  • Allowed issuers (e.g. ban Let's Encrypt staging from the production project).
  • Required key types or minimum sizes.
  • Required SAN suffixes (every cert must include *.example.com).
  • Forbidden CN patterns (no wildcard CNs).
  • Mandatory auto-renew.

Policy violations produce a preflight warning that the operator must read; admins can override per-request, operators cannot.

04Bring-your-own CSR

If the device you're issuing for already has its private key (HSM-backed Vault, an HSM-protected web server), upload the CSR instead. CertAutoPilot uses the upload as the issuance CSR and stores only the resulting certificate, never seeing the private key.

  1. Toggle Bring your own CSR.
  2. Paste a PEM-encoded PKCS#10.
  3. Validation: subject must match policy, SANs are intersected with policy.
  4. The resulting certificate is downloadable but never auto-distributed (we don't have the key to bundle a PKCS#12).

05Manual DNS

For zones not delegated to a supported DNS provider — say, a registrar's homepage with no API. CertAutoPilot pauses the job, shows the exact TXT record to publish, and resumes after you click I've added it.

Manual DNS disables auto-renewal automatically (we cannot publish records you have to set by hand). Only use for one-off certs.

06Approval workflow

If approval is required, submitting the form creates a request in Requests rather than starting the issuance job. Approvers receive a notification, review the request (including all preflight warnings), and approve or reject with a comment. Self-approval is blocked.

07What happens after submit

  1. Worker creates an ACME order (or AD CS enrollment).
  2. For ACME: publishes DNS-01 challenges via configured zone credentials.
  3. Polls validation; CA finalises and issues.
  4. Worker stores certificate + chain (encrypted via DEK/KEK).
  5. Distribution targets fire (if configured) — fan-out, dry-run optional.
  6. Audit events emitted: cert.requested, cert.issued, cert.distributed.
  7. Renewal scheduler picks up the new cert and computes its renewal window.

08API

POST /api/v1/projects/{project}/certificates
GET  /api/v1/projects/{project}/certificates/{id}
POST /api/v1/projects/{project}/certificates/{id}/renew
POST /api/v1/projects/{project}/certificates/{id}/revoke
GET  /api/v1/projects/{project}/certificates/{id}/timeline