Ran the script against a live Infisical instance for the first time. It failed
at four separate points, each fixed here.
Responses are read through Get-ApiProperty/Get-ApiCollection/Get-ApiObject
rather than directly. Set-StrictMode makes an absent property terminating, and
the cert-manager routes return bare payloads - a naked array for a list, the
resource itself for a create - where the secrets and pki routes wrap theirs in
a named property. All eighteen reads now handle either shape. The
application-to-profile listing is a join row carrying profileId, not a profile
object with an id, so it is read accordingly.
Renamed the local $configuration inside the CA loop to $caConfiguration.
PowerShell variable names are case-insensitive, so from the second CA onward it
shadowed the script-level $Configuration block and every lookup into it failed.
Renamed the $profile loop variables for the same reason: $profile is an
automatic variable.
Policies now carry subject, sans, and signature algorithms, and profiles carry
defaults. The previous comment claimed omitting subject and sans left them
unconstrained; the opposite is true. Infisical refuses any attribute with no
policy entry ("no subject policies defined"), refuses a policy that defines no
signature algorithm, and refuses a request missing a usage the policy marks
required - Request-InfisicalCertificate sends none of its own, so the profile
default has to supply it. The enumeration list in the header dropped
domain_component, upn, and any_purpose, which the API does not accept.
Verified end to end: a clean run builds both CA hierarchies including the
subordinate CSR-sign-import sequence, and a re-run creates nothing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gsadmin
3015138484