Key Rotation Policies
The certificate management service supports automatically rotating key pairs. Administrators can update certificates with minimal intervention, eliminating many common configuration errors.
Resources called key rotation policies (KRPs) are exported through the PingOne API by the Certificate Management service. KRPs manage a set of key pairs that are created and rotated on a scheduled basis. These key pairs are referred to as KrpKeys to distinguish them from existing key pair resources. The cryptographic details of KrpKeys are managed by a specification attached to the KRP. The specification includes settings such as algorithm, key length, validity duration period, and distinguished name (DN). This specification and the rotation schedule are mutable after creation. Generated KrpKeys are always self-signed with no extraordinary extensions.
When an environment is created, PingOne creates an initial KRP configuration object as the default KRP. You can can create additional KRPs using the POST {{apiPath}}/environments/{{envID}}/keyRotationPolicies operation. There is no UI to manage KRPs in the PingOne admin console. PingOne allows up to five KRPs per environment. You won’t be able to create a new KRP if the environment already has five KRPs. You cannot delete the default KRP for an environment. A DELETE operation won’t succeed if the environment has only one KRP.
At any given time, a KrpKey has one of three designations: PREVIOUS, CURRENT, or NEXT. When created, a KRP has two KrpKeys with designations CURRENT and NEXT, respectively. After a period of time defined by a KRP’s rotation schedule, a new KrpKey is created and designated as NEXT. The KrpKey previously designated as NEXT transitions to CURRENT, and the KrpKey previously designated as CURRENT transitions to PREVIOUS.
A KRP exports another operation to list all KrpKeys that it manages. This is a read-only operation that returns a JSON Web Key set (JWKS) formatted file containing all public keys associated with a KrpKey managed by a KRP. This allows downstream clients to cache any public keys for use during signature validation. This operation is public and does not require an authentication token.
Key Rotation Policy data model
| Property | Type | Required? | Mutable? | Description |
|---|---|---|---|---|
|
String |
Required |
Mutable |
The algorithm this KRP applies to generated |
|
UUID |
N/A |
Read-only |
The |
|
Boolean |
Optional |
Mutable |
When creating or updating a KRP, setting this value to |
|
String |
Required |
Mutable |
The DN this KRP will apply to generated |
|
UUID |
N/A |
Read-only |
Unique identifier of the KRP. |
|
UUID |
N/A |
Read-only |
Unique identifier of the environment that the KRP belongs to. |
|
Integer |
Required |
Mutable |
The number of bytes of a cryptographic key this KRP will apply to generated |
|
String |
Required |
Mutable |
Human-readable name displayed in the admin console. |
|
UUID |
N/A |
Read-only |
The |
|
Date |
N/A |
Read-only |
The last time this KRP was rotated. |
|
Integer |
Optional |
Mutable |
The number of days to elapse before this KRP rotates |
|
String |
Required |
Mutable |
The signature algorithm this KRP will apply to generated |
|
String |
Required |
Mutable |
How the KRP will be used, pertaining to what operations the KRP supports. The only valid value for initial release is |
|
Integer |
Required |
Mutable |
Controls the expiration date of each |
Signing Request data model
| Property | Type | Required? | Mutable? | Description |
|---|---|---|---|---|
|
String |
Required |
Mutable |
Base64-encoded binary document to sign. |
|
String |
Optional |
Mutable |
If present, this value overrides the |
Signing Response data model
| Property | Type | Required? | Mutable? | Description |
|---|---|---|---|---|
|
Object |
N/A |
Read-only |
|
|
UUID |
N/A |
Read-only |
Unique identifier of the |
|
String |
N/A |
Read-only |
Base64-encoded signature (MAC) as the result of the signing operation. |
|
String |
N/A |
Read-only |
The signature algorithm used to perform the sign operation. |