For PKI architects and administrators planning how their PKI will run on Infisical. Read it before
you create your first Certificate Authority.
The layout
- Policies decide what a certificate may contain.
- Applications decide who can get one.
- Product Admins own the Certificate Authorities, policies, and profiles, and create each Application.
- Teams operate the Applications they are assigned to.
One CA per environment
A separate CA on each side is the strongest form of the boundary. If one environment’s CA has to be replaced, whether it was compromised, had its credentials rotated, or moved to a different provider, every environment with its own CA carries on untouched. With private CAs, create one root and one issuing CA per environment, sign the issuing CAs with the root, then take the root offline. If you already operate a root outside Infisical, keep it and sign the issuing CAs with it. Decide three things as you create them: key protection if the signing key belongs in your own HSM, CA lifetimes comfortably longer than the certificates they issue, and whether your validators can reach the CRL distribution point. With external CAs, register one per environment when the provider allows it. AWS Private CA, Microsoft ADCS, and DigiCert generally do. Public CAs often offer fewer: Let’s Encrypt publishes a staging and a production directory, so development and staging share an issuer. That works, because the boundary moves down a layer to the policy, and using the staging directory below production also keeps test issuance off production rate limits.Private and external CAs sit side by side. Issue internal service certificates from a private CA
and public-facing certificates from a provider, with one CA per environment in each case.
One policy per environment
A policy sets what a certificate is allowed to contain: validity, allowed names, key algorithms. It holds what certificate templates hold in Microsoft ADCS. Write one per environment for each type of certificate you issue, and put that environment’s naming rules inside it.
The boundary is enforced here. A developer who asks a development Application for
payments.example.com is refused, because dev-tls-rules permits only *.dev.example.com, and the policy and the profile above it are administered by someone else.
This example issues one type, TLS server certificates. If you also issue client certificates for service-to-service authentication, give them their own policy per environment, since they differ from browser-facing certificates in more than validity.
One profile per policy
A profile binds a policy to the CA that signs it. This is what teams request from.
Give a policy and its profile different names. They are separate objects that appear side by side in tables, requests, and audit events, so distinct names keep it clear which one a sentence means. Naming both after the environment, as above, also tells anyone attaching a profile which environment they are wiring up.
One Application per service and environment
A Product Admin creates each Application and attaches only that environment’s profile. Teams operate them from there.
Two things change across the rows. The attached profile decides what the team can produce. The membership decides who can produce it, so in production the wider team is read-only and issuance is limited to the on-call rotation and the deployment pipeline’s identity. Users, groups, and machine identities can all be members; prefer groups so access follows your directory instead of a hand-maintained list, and give each pipeline its own identity per environment.
Issuance begins once an enrollment method is configured on the attached profile, which the team can do itself: API for custom integrations, ACME for certbot and cert-manager, EST and SCEP for devices and MDM. Each method’s endpoint is unique to one Application and profile pair, which keeps issuance on each side of the boundary separate. On production, consider approvals to require review before a certificate is issued.
Adding a service later reuses everything above. Create its Applications, attach the profiles that already exist, and the team configures its own enrollment.
Who administers, who issues
Two different roles share the word admin. Product Admin is an organization-level role over the Certificate Authorities, policies, and profiles. Application Admin is a role inside a single Application, covering its enrollment, members, alerts, and syncs. Application Admins work strictly inside their own Application.
Application members need the Product Member role to reach the Applications they are assigned to. Product Admins control every Certificate Authority in the organization, private and external, so keep that set small and deliberate.
Where your current setup fits
Infisical sits on top of whatever you issue from today. Existing certificates stay valid until they expire or are revoked, and nothing needs re-issuing to adopt this layout.Choosing your boundary
Environment is the most common boundary, but the structure holds along whichever one you pick.When you need full separation
Product Admins administer every CA, policy, and profile in an organization. When environments must be administered by different people, for example under different compliance rules or across different legal entities, put each one in its own sub-organization, which sits inside your existing organization. Each sub-organization runs its own Certificate Authorities, policies, profiles, Applications, Product Admins, and audit trail. Certificate Authorities stay within their sub-organization, so there is no shared root between them.Limits of this model
- CA, policy, and profile administration is organization-wide. Product Admins administer all of them, and that scope covers every CA and every environment. Where one environment’s operators must be kept away from another environment’s CA, use a sub-organization.
- Audit logs are read by Product Admins and cover the whole product. Reading them takes the Product Admin role, and an admin who opens them sees all of it, every CA and every Application. The export carries CA and Application in event metadata, so a reviewer can narrow an exported set.
- Approvals cover issuance. Approval policies gate certificate issuance and code signing. CA lifecycle actions such as create, renew, and revoke fall outside approvals today.
Next steps
Certificate Authorities
Set up each environment’s CA, private or external.
Certificate Policies
Write the rules each environment enforces.
Applications
Create the workspaces your teams issue certificates from.
Access Control
The full permission model behind the roles above.