Takes any IDictionary, so a hashtable, an [Ordered] dictionary, or a generic
Dictionary[String,String] all bind. Verified against all three issuance
parameter sets under Windows PowerShell 5.1.
The reconcile is client-side by necessity. Infisical's PATCH /certificates/{id}
replaces a certificate's metadata wholesale - certificate-v3-service deletes
every resource_metadata row for the certificate before inserting what it was
sent - so sending just the caller's keys would silently discard everything else
attached to it. The module reads the current set, merges the supplied keys over
it, and writes back the union. Keys it was not asked about survive, and when
nothing would change no request is sent at all.
Reconciliation runs on the reuse path too, so changing metadata does not force
a reissuance to take effect.
Values are flattened to strings because the API accepts only strings: 443
becomes "443", $True becomes "True", $Null becomes "". Keys are trimmed and
compared case-insensitively, matching how PowerShell callers supply them, and
blank keys are dropped since the API rejects them.
Metadata never fails an issuance that otherwise succeeded. By the time it is
applied the certificate exists and may already be installed in the store, so a
failure is reported as a warning and the certificate is still emitted.
Adds InfisicalCertificate.Metadata and InfisicalCertificateResult.Metadata as
case-insensitive dictionaries, the PATCH endpoint under both the cert-manager
and pki route namespaces, and models the metadata array already returned by the
certificate response.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Stands up a complete Certificate Manager environment from one declarative
configuration block, taking only a base URI, client id, and client secret.
Standalone: the module consumes the result but is not needed to produce it,
since InfisicalConnection deliberately does not expose its access token.
Seeds an RSA hierarchy carrying server and client authentication for SCCM/MECM,
and an ECDSA P-384 hierarchy carrying server, client, and code signing. Objects
are cross-referenced by name in the configuration and resolved to ids at run
time, so adding a policy or profile means adding an entry rather than editing
code.
Creating a subordinate CA needed more than one call. Infisical only self-signs
on creation for a root, and only when given an expiry; a subordinate is created
with status pending-certificate and generateIntermediateCaCertificate is never
invoked by the create path. The script performs the sequence itself: create,
GET the CSR, sign it with the parent, then import the certificate and chain
back onto the subordinate.
Idempotent by lookup on each natural key, so a re-run reports what exists and
creates only what is missing, and -WhatIf shows the whole plan without
contacting anything beyond authentication.
Also corrects a documentation error this research surfaced. The README claimed a
newly created CA defaults to direct issuance enabled, on the strength of the
database column default. The creation service passes enableDirectIssuance:false
explicitly, so every CA created through the API or UI has it disabled and
nothing can enable it afterwards - which makes certificate profiles the only
workable issuance path, not merely the recommended one.
Validated by parsing the script, exercising the policy payload builders against
the shapes Infisical's zod schemas accept, confirming every enum literal matches
a defined Infisical value, checking that all name cross-references resolve, and
running -WhatIf to the point of authentication. Not yet exercised against a live
Infisical instance.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gsadmin