Certificate Profiles¶
Certificate profiles define what issued certificates should look like. They combine template defaults with validation rules for incoming certificate requests, for example via CMP or EST.
Use certificate profiles to control:
Subject attributes, such as
CN,OU, or other DN fieldsX.509 extensions, such as Key Usage, Extended Key Usage, SAN, or Basic Constraints
Certificate validity
Whether request values may override profile defaults
Which fields are required, allowed, fixed, or rejected
Access¶
Certificate profiles are managed under:
PKI > Certificate Profiles
The overview lists all available profiles with their unique name, display name, domain usage, timestamps, default status, and available actions.
Profile List¶
Each row represents one certificate profile.
Column |
Description |
|---|---|
Unique Name |
Internal profile identifier used by Trustpoint and request endpoints. |
Display Name |
Human-readable profile name. |
Active in Domains |
Shows where the profile is enabled. |
Created at |
Creation timestamp. |
Updated at |
Last update timestamp. |
Is default |
Indicates whether the profile is part of the default Trustpoint profiles. |
Config |
Opens the profile configuration. |
Issuance |
Starts certificate issuance using this profile, if available. |
Default profiles may be provided for common use cases such as TLS client, TLS server, OPC UA, IDevID, domain credentials, and issuing CA certificates.
Managing Profiles¶
Certificate profiles are JSON documents. A profile must be enabled in a domain before devices can request certificates with it.
A domain may define an alias for a profile. This allows different internal profiles to be requested through the same profile name in different domains.
When a device requests a certificate, it selects the certificate profile through the request URL path.
Profile Structure¶
A certificate profile can define the following root fields:
Field |
Description |
|---|---|
|
Must be |
|
Optional schema version. |
|
Human-readable name shown in Trustpoint. |
|
Defaults and constraints for the certificate subject. |
|
Defaults and constraints for X.509 extensions. |
|
Certificate validity settings. |
Example¶
{
"type": "cert_profile",
"ver": "1.0",
"display_name": "Example TLS Server Profile",
"subject": {
"allow": ["CN", "OU"],
"CN": {
"required": true,
"default": "device.example.com"
}
},
"ext": {
"key_usage": {
"digital_signature": true,
"key_encipherment": true,
"critical": true
},
"extended_key_usage": {
"usages": ["server_auth"]
},
"san": {
"dns": ["device.example.com"]
},
"basic_constraints": {
"ca": false,
"critical": true
}
},
"validity": {
"days": 90
}
}
Supported Rules¶
Rule |
Description |
|---|---|
|
Allows additional fields. Use |
|
Sets a fixed value. |
|
Sets a default value if the request does not provide one. |
|
Requires the field in the issued certificate. |
|
Allows the request to override the profile value. |
|
Rejects the request if it tries to modify the field. |
|
Marks an extension as critical. |
|
Prohibits the field. |
Field names may use RFC 5280 names, OIDs, snake case, camel case, or supported abbreviations.
Validity¶
The validity field defines how long issued certificates are valid.
Examples:
{
"validity": {
"days": 90
}
}
{
"validity": {
"notBefore": "2026-01-01T00:00:00Z",
"notAfter": "2027-01-01T00:00:00Z"
}
}
{
"validity": {
"duration": "P365D"
}
}
Relative values such as days, hours, minutes, and seconds are added together.
Validation Flow¶
For each certificate request, Trustpoint:
Parses the incoming request.
Converts it into an internal certificate request structure.
Validates and normalizes the selected certificate profile.
Validates and normalizes the request.
Applies the profile rules to the request.
Builds the certificate from the validated result.
Invalid requests are rejected or normalized according to the selected profile rules.