Concept
A certificate profile is a configuration set specifying how leaf certificates should be issued for a group of end-entities including the issuing CA, a certificate policy, and the enrollment method (e.g. ACME, EST, API, etc.) used to enroll certificates.
You typically request certificates against a certificate profile through its associated enrollment method. Each method defines its own interaction flow which you can read more about in its respective documentation.
Guide to Creating a Certificate Profile
To create a certificate profile, head to your Certificate Management Project > Certificates > Certificate Profiles and press Create Profile.
Here’s some guidance on each field:
- Name: A slug-friendly name for the profile such as
web-servers.
- Description: An optional description for the profile.
- Issuer Type: The type of issuer that should be used to issue certificates for the profile; this can be either
Certificate Authority or Self-Signed. If Self-Signed is selected, then the profile will only support the API enrollment method and be used to issue self-signed certificates over REST API.
- Issuing CA: The issuing CA that should be used to issue certificates for the profile when the Issuer Type is set to
Certificate Authority.
- Certificate Policy: The certificate policy that should be used to validate certificate requests for the profile.
- Enrollment Method: The enrollment method that should be used to enroll certificates for the profile such as ACME, EST, API, etc. Depending on which enrollment method you choose, you may be presented with additional enrollment-specific configuration fields.
The profile form also has a separate Certificate Details tab where you can pre-configure certificate values that are applied when a requester does not specify them. See Profile Defaults below for more details.
Profile Defaults
Requesting a certificate involves choosing a key algorithm, signature algorithm, key usages, subject attributes, and more. For users who are not familiar with these options, this can feel overwhelming. Profile defaults let administrators pre-configure sensible values so that requesters can issue certificates without needing to make every decision themselves. If a requester does not know what to pick, they can simply go with whatever the administrator has already set.
Defaults are automatically applied to any certificate request that does not explicitly specify those values. If a requester does provide a value, it takes precedence over the default. In the UI, defaults are pre-selected in the certificate request form. For non-UI flows such as API, EST, or ACME, the requester does not need to pass those values in the request at all — the defaults are applied automatically.
Combining Defaults with Policies
For the simplest possible requester experience, pair defaults with a tightly scoped certificate policy. By narrowing the policy down so that only one option is allowed for each field and then setting that option as the default, the requester has nothing left to decide — the profile handles everything automatically.
For example, if your policy only allows RSA 4096 as the key algorithm and you set RSA 4096 as the profile default, the requester never needs to think about key algorithms at all.
Defaults can be configured for TTL, subject attributes (Common Name, Organization, OU, Country, State, Locality), key algorithm, signature algorithm, key usages, extended key usages, and basic constraints.
If the certificate policy is updated after the profile is saved, the existing defaults may no longer comply with the new policy. When this drift occurs, certificate requests against the profile will fail at validation time. You will need to update the profile defaults to bring them back in line with the updated policy.
