Certificate Revocation

Learn about how to revoke a certificate or certificate authority (CA) to help keep resources secure in the event a certificate can no longer be trusted.

You can revoke a certificate or certificate authority (CA) if you want to invalidate it as a trusted resource for any number of reasons. Revocation lets you indicate that a specific version of a certificate or CA is no longer trustworthy and mark it as invalid for use before the end of its validity period. While you can revoke specific versions, you must always have at least one version of a certificate or CA unless you delete the resource altogether. If you do decide to delete a CA, we recommend that you revoke the CA first.

To revoke a certificate version or CA version, you issue and publish a certificate revocation list (CRL). CRLs are published when a CA version or certificate version is revoked, as well as when a CA is created. A CRL lists the X.509 certificates that a CA has revoked prior to their expiration date. When a CA is initially created, the CRL is an empty list that contains no revoked certificates.

If you do not configure a CA for revocation when you create it, you can configure revocation later. Any certificate version or CA version that you revoke before you configure revocation, which includes the corresponding publication of a CRL, is published to the CRL when the CRL becomes available.

In a CRL, the revocation status includes a reason for the revocation, and the revocation status for a CA and its certificates do not need to match. Revocation statuses can include:

• UNSPECIFIED. No specific reason. (Although you can revoke a certificate without specifying why, the practice is not recommended.)
• KEY_COMPROMISE. Suspected or actual compromise of the private key corresponding to the public key in the certificate. For example, the device that stores the private key is lost or stolen. (This reason is used for end entity certificates.)
• CA_COMPROMISE. Suspected or actual compromise of a CA or the private key corresponding to the public key in the CA certificate. Again, for example, the device that stores the private key is lost or stolen.
• AFFILIATION_CHANGED. Certificate subject information or other certificate details changed because an individual left the organization specified in the Distinguished Name attribute of the certificate.
• SUPERSEDED. A replacement certificate has been issued that supersedes the revoked certificate, and the reason is not one of the other revocation reasons.
• CESSATION_OF_OPERATION. The CA is ceasing operation and no longer publishing CRLs for currently issued certificates.
• PRIVILEGE_WITHDRAWN. The certificate holder no longer has the privileges required to continue using the certificate.
• AA_COMPROMISE. Suspected or actual compromise of the authentication authority (AA) validated in the certificate.

To validate a certificate, clients of a certificate get the .crl file hosted at the endpoint named in the certificate as the CRL distribution point (CDP). Then, they check whether the file lists the serial number of the certificate. Any certificate included in the CRL is rejected as invalid.

You need to have a unique, dedicated Oracle Cloud Infrastructure Object Storage bucket where you can store the CRL before you create a CA or before you configure a CA for revocation. If the service cannot publish a CRL to Object Storage after several attempts, the next attempt to publish the CRL happens when the next certificate is revoked.

CRLs are published with a validity period of seven days and are refreshed every three days, before they expire, or whenever a certificate is revoked. A CA can refresh a CRL as long as the CA lifecycle state is 'Active'.

You hold responsibility for hosting the CDP at an endpoint that clients can reach. The service does not validate CDP endpoints. The CDP of a certificate is included in the certificate and in the certificate of the issuing CA. You can have an HTTPS address as the CDP only if you can guarantee that there are no circular dependencies in the verification of the HTTPS chain.

Updating the details of the CRL, including the Object Storage bucket where it is stored or the URL of the CDP, does not automatically update the certificate of the current CA version. If you want to issue a new certificate to reflect a new CDP, then you must create a new CA version.

Revoking a certificate puts the resource's lifecycle state into 'Updating' until the CRL is successfully published to the Object Storage bucket, if the issuing CA is configured to publish a CRL. A revoked CA remains in an 'Active' state because you can still renew the CA. Only the CA version is revoked. Furthermore, revocation of a CA does not affect the revocation status of a subordinate CA or the certificates the CA has issued. Oracle recommends that you revoke every descendant in the hierarchy if an issuing CA is compromised.