Oracle Cloud Infrastructure Documentation

Known Issues for Certificates

Known issues have been identified in Certificates.

Certificate revocation list (CRL) publishing fails when the Oracle Cloud Infrastructure Object Storage bucket is full

Details
The Certificates service can't publish a CRL to an Object Storage bucket that's at or near its storage limits. As a result, the lifecycle state of any Certificates resource that you tried to revoke remains stuck in an 'Updating' state until the CRL is successfully published.
Workaround
Maintain available space to store the CRL in the bucket that you configured for publishing CRLs. Check Object Storage quotas. Optionally, configure an object lifecycle policy to delete objects or move objects to another storage tier to prevent the bucket from meeting its limits. For more information, see Using Object Lifecycle Management.

Revoking resources fails when the key, vault, bucket, or policies are missing

Details
The Certificates service can't revoke certificates or certificate authorities (CAs) when any of the following are missing:
  • the key that you used to create the issuing CA
  • the vault that contains the key that you used to create the certificate or CA
  • the bucket that you use to publish the certificate revocation list (CRL)
  • the IAM policy that grants the service permission to write objects to the bucket where you publish CRLs
Without the key, the service can't revoke the certificate or CA. Without the bucket or permissions to write objects to the bucket, the service can't publish the CRL that specifies what you want to revoke.
When revocation fails, the resource that you tried to revoke remains in an Updating state. Resources stuck in an Updating state can neither be updated or deleted.
Workaround
No workaround exists. To help avoid this issue, you can follow some recommended best practices. Note which keys you use to create certificates and CAs, and then take care not to lose them. The Certificates service doesn't maintain this type of information for you. Similarly, note which buckets are being used by CAs and don't delete them either. Lastly, note which policy statements you need to maintain to provide the Certificates service access to the buckets used by Certificates service CAs.

Automatic renewal fails when the key or vault are missing

Details
The Certificates service can't renew certificates or certificate authorities (CAs) when either of the following are missing:
  • the key that you used to create the certificate or CA
  • the vault that contains the key that you used to create the certificate or CA
Automatic renewal of an internally managed certificate fails if you deleted the key (or the vault that contained the key) that you used to create the issuing certificate authority (CA). The Certificates service needs the key to sign certificates with.
Workaround
No workaround exists. Note which keys you use to create certificates and CAs, and then take care not to lose them. The Certificates service doesn't maintain this type of information for you.

Importing certificates with Terraform isn't supported

Details
You can't import a certificate by using Terraform.
Workaround
Instead, import a certificate by using the Console, CLI, or SDK.

Creating resources that exist past the year 2038 isn't supported

Details
You can't create Certificates service resources that either become valid or expire after the year 2038.
Workaround
We're working on a resolution.

Immediately deleting failed resources isn't supported

Details
You can't immediately delete Certificates service resources in a failed lifecycle state. At the earliest, you can delete a certificate authority (CA) about 7 days from the current time. For certificates, the soonest that you can delete a failed certificate is about 1 day from the current time. Until they're deleted, failed resources count against service limits.
Workaround
If needed, to increase service limits, open a support request. For more information, see Open a support request.

Updating rules can fail when existing resources bound by current rules exist

Details
You can't update certificate authority (CA) expiry rules if the following two things are true:
  • the changes that you specify are more restrictive than the rules already in place
  • you have existing resources in use that are bound by those rules

For example, if you have an active subordinate CA that expires in 60 days, you can't change the expiry rule of its parent CA to make the maximum validity duration 30 days.

Workaround
Changes to CA expiry rules apply only to new certificates and new subordinate CAs that you issue after making the changes. However, before you can update rules to be more restrictive, you must either deactivate or revoke Certificates service resources that don't align with the new rules.