Oracle Cloud Infrastructure Documentation

Bringing your own Certificate Authority

Bring Your Own Certificate Authority (BYOCA) for OCI Certificates gives enterprises the flexibility to integrate their existing Certificate Authority (CA) infrastructure directly into OCI while keeping full control of their private keys.

Enterprises today run mature, deeply rooted PKI environments that support thousands of applications, regulatory mandates, and long-standing trust chains. Rebuilding this hierarchy in the cloud is expensive, risky, and rarely feasible. Customers need a secure, predictable way to connect their existing root CAs into OCI, maintain trust continuity, and adopt cloud automation without disrupting operations.

BYOCA is built precisely for this.

Bringing your own Root Certificate Authority

You can import an external root Certificate Authority (CA) into OCI Certificates by providing the certificate (PEM), without ever uploading your private keys. OCI registers the CA as an externally managed root CA, maintaining trust with an existing Public Key Infrastructure while ensuring keys remain solely under your control.

To import your root CA, follow these steps:

  1. In the OCI Console, open the main menu (☰ hamburger menu) and go to Identity & Security then select Certificates.
  2. Under Certificate Authorities, select Import Certificate Authority.
  3. Enter the Name and Description.
  4. Select the Compartment for your root CA.
  5. Either Upload or Paste your root CA certificate PEM file into OCI. Add an external key description.
  6. Select Import.
Note

For further details on importing your certificate see: Importing your own Certificate Authority

Creating an OCI-Managed Subordinate CA

After importing your root CA, generate a Certificate Signing Request (CSR) in OCI. To create a new subordinate CA (subCA) select Subordinate Certificate Authority: External CA issued, Managed Internally from the Create Certificate Authority dialog. Then, sign this CSR externally using your existing root CA keys and upload the signed certificate back into OCI. At that point, OCI Certificates service activates the subordinate CA and manages it on your behalf, using keys securely stored in OCI Key Management Service (KMS). The subordinate CA needs a Hardware Security Module (HSM) backed key.

Steps to Create a Subordinate CA

To create a subordinate CA, follow these initial steps:

  1. Import External Root CA into OCI. See preceding section.
  2. Navigate to the Certificate Authorities list page, select Create Certificate Authority. If you need help finding the list page, see Listing Certificate Authorities.
  3. Under Basic Information, enter the Name and Description.
  4. Select the Compartment for the root CA.
  5. Select Subordinate Certificate Authority external CA issued, managed internally.

Fill out the remaining sections in the CA dialog.

(1) Subject Information

Subject Information: Enter the Common Name that identifies the subordinate CA created within the organization's certificate hierarchy.

Fill out any Additional subject distinguished name options as needed.

(2) Authority Configuration

Authority Configuration:
  • Select:
    • Compartment: Target compartment for root CA.
    • Issuer certificate authority: The imported external root CA that serves as the parent authority for this subordinate CA.
  • Select:
    • Compartment: Target compartment for vault.
    • Vault: The vault that stores the key.
  • Select:
    • Compartment: Target compartment for the key.
    • Key: The key for the CA.

(3) Rules

Follow these steps to configure rules:

  1. Expiry Rule: Enabled. The default value.
    • Maximum validity duration for Certificate: Recommended value is 90 days.
    • Maximum validity duration for Subordinate CA: Recommended value is 1095 days (3 years).

    Modify the validity periods to suit the organization's requirements.

  2. Issuance Rule: Enabled. The default value.
    • Path length constraint: Specify the length.
    • Name constraint: Define any name constraints that define what certificates subject names/SAN this CA is allowed to issue.
    To configure issuance rules, specify the permitted path length and any name constraints that define what certificates subject names/SAN this CA is allowed to issue.

(4) Revocation configuration

You can configure a location for publishing a certificate revocation list (CRL). A CRL specifies the versions of a CA or certificate considered no longer trustworthy and invalid before the end of their validity period. Revocation settings can be updated at any time.

  • Enable revocation: Enabled. The default value.
  • Compartment: Compartment for the object storage bucket.
  • Object storage bucket: Select target bucket.
  • Object name format: Specify a format for object files.
  • Custom formatted URL: Specify a custom formatted URL as the CRL distribution point (CDP).

Review

Review your configuration options. Select Create Certificate Authority.

This creates a Subordinate CA entity in OCI.

Steps to Activate a Subordinate CA

To activate the Subordinate CA, follow these steps

  1. Navigate to the Certificate Authorities list page. If you need help finding the list page, see Listing Certificate Authorities.
  2. Select the recently created subordinate CA.
  3. Go to Versions tab. Under Pending_Activation stage. Select the Actions menu (three dots) for the version and select Download CSR.
  4. Take the downloaded CSR and sign the CSR with your external CA.
  5. Return to the same Versions tab and select on Activate. Upload the signed certificate and select Activate.

The result after creating and activating your CA:

  • A fully operational subordinate CA
  • A flexible option of Private keys either generated or imported inside OCI KMS
  • Full OCI lifecycle management and certificate issuance directly from the SubCA.

You can also import their own asymmetric key pairs for subordinate CAs directly into OCI KMS, giving them greater flexibility in how keys are created and controlled.

Summary

With BYOCA, you can:

  • Extend an existing root CA hierarchy into OCI without exposing private keys.
  • Create OCI-managed subordinate CAs using CSRs signed by the external root.
  • Issue certificates directly from OCI-managed subordinate CAs using secure KMS-backed keys.
  • This bridges the gap between your current PKI investments and the automation and scalability benefits of OCI.

Benefits include:

  • More Flexibility: Leverage your existing CA infrastructure, policies, and governance models in OCI without redesign.
  • Better Interoperability: Connect hybrid environments effortlessly. BYOCA makes it easier to run distributed workloads across on-prem, multi-cloud, and OCI.
  • Stronger Compliance: Alignment BYOCA supports strict separation of duties models, regulatory requirements, and audit mandates while OCI manages the operational lifecycle of subordinate CAs in a secure, compliant platform.
  • Stronger Security Options: Decide where keys live and how keys are managed. Maintain full control of root keys while OCI manages the operational burden of subordinate CAs.