Managing Certificate Authorities
Use Certificates to create and manage the certificate authorities that issue digital certificates.
Certificate authority (CA) management tasks include the following:
- Creating a Certificate Authority
- Issuing a Subordinate Certificate Authority
- Listing Certificate Authorities
- Viewing Certificate Authority Details
- Editing a Certificate Authority
- Editing a Certificate Revocation List
- Editing Certificate Authority Rules
- Viewing Certificate Authority Associations
- Renewing a Certificate Authority
- Moving a Certificate Authority
- Deleting a Certificate Authority
- Canceling Certificate Authority Deletion
Every CA has one or more CA versions. As such, CA management also includes the following tasks specific to CA versions:
Required IAM Policy
To use Oracle Cloud Infrastructure, you must be granted security access in a policy (IAM) by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don't have permission or are unauthorized, verify with your administrator what type of access you have and which compartment you should work in.
For some operations, the Certificates service also requires resources to have security access not granted by policies that cover users or groups. This section describes how to authorize users as well as resources that must act on other resources.
Step 1: Create a Dynamic Group
resource.type='certificateauthority'
This matching rule defines a dynamic group that includes all CAs as members. You need this dynamic group in order to authorize CAs to make API calls against other services, as needed. CAs typically need permission to access Oracle Cloud Infrastructure Vault and Oracle Cloud Infrastructure Object Storage resources. For more information about dynamic groups, see Managing Dynamic Groups.
Step 2: Create a Policy for the Dynamic Group
After creating the dynamic group, you create a policy for the dynamic group. In the following policy, the dynamic group has the example name CertificateAuthority-DG. The policy gives members of the dynamic group permission to use Vault keys and to do anything with Object Storage objects in the specified example compartments. This type of policy is referred to as a resource principal policy because it authorizes a resource as a principal actor that can act on other resources.
Allow dynamic-group CertificateAuthority-DG to use keys in compartment DEF
Allow dynamic-group CertificateAuthority-DG to manage objects in compartment XYZ
Step 3: Add a Policy for Administrators
You also need a policy to authorize administrators to access resources. The following
policy gives permission to the example group CertificateAuthorityAdmins to do
anything with any resources included in the aggregate resource-type
certificate-authority-family
and to work with required Vault and Object Storage resources in the specified example compartments, as needed. This includes the
permissions needed to specify the encryption key for the CA.
Allow group CertificateAuthorityAdmins to manage certificate-authority-family in compartment ABC
Allow group CertificateAuthorityAdmins to read keys in compartment DEF
Allow group CertificateAuthorityAdmins to use key-delegate in compartment DEF
Allow group CertificateAuthorityAdmins to read buckets in compartment XYZ
Allow group CertificateAuthorityAdmins to read vaults in compartment DEF
Together, these statements provide the minimum access needed to complete administrative tasks with certificate authorities, as described later in this topic. For more information about permissions or if you need to write less restrictive policies, see Details for the Certificates Service. If you're new to policies, see Getting Started with Policies and Common Policies.