The subscriber guidance shipped in #18 was wrong for fleet enrollment.
signSubscriberCert rejects any CSR whose CN differs from the subscriber's
commonName, and allowlists the subscriber's subjectAlternativeNames, so a
subscriber is a single named identity rather than a template. Enrolling N
machines through subscribers would require N subscribers.
Certificate profiles are the correct path: they accept a per-request common
name constrained by policy allowed/required/denied lists, and profile issuance
is the only path that skips the CA direct-issuance gate
(!isFromProfile && !ca.enableDirectIssuance && !certificateTemplate), so a
profile issues against a CA whose EnableDirectIssuance is False.
Also documents that enableDirectIssuance cannot be changed after CA creation:
it appears in no Infisical create or update schema (the generic CA schemas
accept only name and status). Migration 20250521110635_add-external-ca-pki.ts
renamed requireTemplateForIssuance to enableDirectIssuance and inverted every
existing value, so CAs that previously required a template now read False
permanently. The remedies are a profile, or a new CA (column defaults to true).
README end-to-end example switched from subscriber to profile issuance, and the
issuance-path table now leads with whether the common name varies per request.
Cmdlet help for Request-InfisicalCertificate and Get-InfisicalCertificateAuthority
updated to match.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gsadmin
f56fd15b38