Skip to main content

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.

Form 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.
SANsnoNo platform limit — your CA imposes one (Let's Encrypt allows 100 identifiers) and exceeding it fails at order time, not at submit. Set san_rules.max_san_count in the certificate policy to enforce a limit locally. 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.

Choosing 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.

Policy 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.

A request that violates the policy is rejected with HTTP 422 and a structured list of violations — nothing is created and no job is enqueued. There is no per-request override and no admin bypass: change the policy, or change the request.

Bring-your-own CSR — not supported​

CertAutoPilot always generates the key pair itself and builds the CSR internally; there is no way to supply your own PKCS#10. If your requirement is that the private key never exists outside a device or HSM, this product cannot satisfy it today — import an externally issued certificate instead, or issue through your device's own enrolment path.

Manual 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.

HTTP validation​

No DNS access at all? Pick HTTP: route the ACME challenge path (/.well-known/acme-challenge/*) on each domain to CertAutoPilot at your edge (gateway / ingress / reverse proxy — CertAutoPilot can stay internal), and the CA validates over port 80 — no zone, no DNS credential, immediate validation, auto-renew fully supported. Wildcards are not possible with HTTP validation. See HTTP validation.

Approval 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.

What happens after submit​

  1. Worker creates an ACME order (or AD CS enrollment).

  2. For ACME with automated DNS, issuance is phased across three jobs, not one. issue_certificate publishes the DNS-01 TXT records and hands off — it completing quickly does not mean the certificate was issued.

  3. await_dns_propagation polls DNS on its own schedule without holding a worker, up to the propagation deadline (default 30 minutes, configurable 5 minutes–4 hours). finalize_order then accepts the challenges, finalises the order and downloads the certificate.

    Manual DNS, HTTP-01, the sequential RRset-replacing provider rfc2136, and Cloudflare, DigitalOcean, OVH and Plesk use the older single-job synchronous flow instead — those four delete their TXT record from the process that created it, so they cannot use the phased flow's separate cleanup job.

  4. Worker stores the certificate and chain, plus the private key envelope-encrypted with a DEK wrapped by the KEK. The certificate and chain themselves are public data and are stored as-is.

  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.

API​

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

See also​