Skip to main content

Documentation Index

Fetch the complete documentation index at: https://infisical.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

This guide is for existing customers on the legacy project-based model. If you’re new to Infisical Certificate Manager, start with Getting Started.

​
Backward Compatibility

Your existing certificates, profiles, alerts, syncs, and approval policies continue to work. Certificates will keep renewing, alerts will keep firing, and syncs will keep running. Nothing breaks. What you can still do at the product level: What must now be done inside Applications: Legacy profiles with enrollment methods configured will continue to issue certificates, but you cannot modify their enrollment configuration. New enrollment must be configured inside Applications. Legacy alerts, syncs, and approval policies remain functional and can be modified, but new ones cannot be created at the product level. New ones must be created inside Applications.

​
What Changed

The old project model put everything in one place (CAs, profiles, certificates, alerts, syncs) with project-level access control. The new model separates shared infrastructure from team operations. Certificate Authorities, policies, and profiles now live at the product level, shared across your organization and managed by Product Admins. They’re the building blocks that define what certificates can look like. Applications are where teams actually work. An Application represents a service or workload that needs certificates: a payments API, an internal web app, a mobile backend. Each Application has its own:
  • Members (with Admin, Operator, or Auditor roles)
  • Enrollment methods (configured per profile)
  • Certificate inventory
  • Alerts, syncs, and approval policies
Organization
└── Certificate Manager
    ├── Certificate Authorities        ← shared, admin-managed
    ├── Certificate Policies           ← shared, admin-managed
    ├── Certificate Profiles           ← shared, admin-managed
    └── Applications
        ├── payments-api
        │   ├── Members
        │   ├── Enrollment Methods
        │   ├── Certificates
        │   ├── Alerts, Syncs, Approval Policies
        └── mobile-backend
            └── ...
What this changes:
Before (Projects)After (Applications)
Everything in one projectShared infrastructure + scoped Applications
Project-level access (see everything)Application-level access (see only your service)
Enrollment baked into profilesEnrollment configured per Application
Custom roles + conditions for scopingSimple roles: Admin, Operator, Auditor
Alerts/syncs at project levelAlerts/syncs scoped to each Application

​
Access Control

For details, see Access Control. Product Level:
RoleWhat they seeWhat they can do
Product AdminEverythingFull control of CAs, Policies, Profiles, Applications
Product MemberApplications they’re assigned toOperate within assigned Applications only
Application Level:
RoleWhat they can do
AdminConfigure enrollment methods, syncs, alerts, approvals. Manage members.
OperatorIssue, renew, revoke certificates
AuditorView certificates and configuration (read-only)
No custom roles. No attribute-based conditions. Add someone to an Application, pick a role, done.

​
Migration Steps

1

Review your current setup

Document your existing:
  • Certificate profiles and their enrollment methods
  • Alert configurations
  • Certificate syncs
  • Approval policies
  • Team members and their access levels
2

Create Applications

Create an Application for each service or workload that needs certificates:
  1. Go to Certificate Manager → Applications
  2. Click Create Application
  3. Name it after the service (e.g., payments-api, mobile-backend)
Think about ownership: who is responsible for certificates for this service? That’s who should be in this Application.
3

Configure enrollment methods

For each Application:
  1. Go to the Settings tab and find the Certificate Profiles section
  2. Attach profiles and configure enrollment methods (API, ACME, EST, SCEP)
One profile can now serve multiple Applications with different enrollment methods. No more duplicating profiles.
4

Recreate alerts

For each Application:
  1. Go to the Settings tab and find the Alerting section
  2. Create alerts for expiration, issuance, renewal, and revocation
You can still modify or delete legacy alerts, but new alerts must be created inside Applications.
5

Recreate syncs

For each Application:
  1. Go to the Certificate Syncs tab
  2. Configure syncs to push certificates to your destinations
You can still modify or delete legacy syncs, but new syncs must be created inside Applications.
6

Recreate approval policies

For each Application:
  1. Go to the Settings tab and find the Approval Policies section
  2. Configure approval requirements for each attached profile
Pending approval requests appear in Certificate Manager → Approval Requests.
7

Assign team members

  1. Grant Product Member role to team members who need Application access
  2. Assign them to specific Applications with Admin, Operator, or Auditor roles
Go to the Application’s Members tab to add members and assign roles.
8

Update issuance clients

Enrollment URLs have changed from profile-based to Application + Profile based. Update your:
  • ACME clients (Certbot, cert-manager, etc.): Directory URLs now include both Application ID and Profile ID
  • Infisical Agent: Update configuration to reference application-name and profile-name
  • EST/SCEP clients: Endpoint URLs now include Application and Profile path segments
  • Terraform: Update any infisical_pki_* resources to use the new Application-based configuration
  • API integrations: Update endpoints to use the new Application context

​
FAQ

Yes. Existing ACME clients, Infisical Agent configurations, API integrations, and other issuance flows continue to work. Legacy profiles with enrollment methods configured will keep issuing certificates as before.
Yes. You can modify or delete legacy resources, but you cannot create new ones at the product level. New alerts, syncs, and approval policies must be created inside Applications.
No. Existing certificates are unaffected. The migration is about how you organize and manage certificates going forward.
Your existing setup will continue working, but you won’t be able to create new alerts, syncs, or approval policies at the product level. All new configuration must happen inside Applications.
Yes. Profiles still exist and define certificate attributes (CA, validity, constraints). The change is that enrollment methods are now configured per Application, not per profile.
A profile defines what a certificate looks like: one CA, one policy, one set of constraints. A service often needs multiple certificate types. Keeping profiles at the product level lets admins define them once and let multiple Applications consume them, each with their own enrollment methods and access control.

​
Need Help?

If you have questions about migration, contact support@infisical.com.