OCI（Oracle Cloud Infrastructure）には証明書の発行，保管，管理の機能をクラウドベースで提供する証明書サービスとして，「OCI Certificates」があります。作成した証明書はロードバランサやAPIゲートウェイと連携することができ，HTTPS接続などで必要となる証明書を手軽に管理できます。
本サービス自体は基本的に無料で利用することが可能です。しかし，一部シークレットの格納に Vault サービスと連携することがあり，そのVaultサービスの方で課金が発生する可能性がありますのでご注意ください。
他の記事では「証明書サービス」と記載している場合もありますが，ここでは「OCI Certificates」と表現を統一します。
OCI Certificatesは，X.509証明書のライフサイクル管理を簡素化するためのクラウドベースのサービスです。
このサービスには大きく分けて２つの機能があると私は見ています。
- 独自CAによるプライベートPKI の提供
- パブリックのデジタル証明書の格納・他OCIサービスからの参照
余談ですが，プライベートPKIという表現は「Private Public Key Infrastructure」ということになるので，プライベートなんだかパブリックなんだかわからなくなっちゃいますね。
まぁ，それぞれ見ていきます。
1-1. プライベートPKI
OCI 上に認証局（CA）を作成・管理し，プライベート証明書の発行，管理，失効までのライフサイクル管理を一元的に行います。CA の秘密鍵は OCI の KMS である「OCI Vault」を利用し，証明書失効リスト（CRL）はオブジェクトストレージにて配布されます。
このプライベートCAによる証明書の発行形態（名称は管理形態ですが）として以下の２つがあります。
▼ 内部管理
- OCI Certificates サービスが，鍵ペアの生成を含め証明書の作成，更新，失効まで面倒をみます
- ここで作成した証明書はロードバランサや APIゲートウェイの他OCIサービスと連携することができます
- コンソール上では「
内部CAによって発行済（Issued by internal CA）」と表現されています
▼ 外部管理
- OCIに作成したプライベートCAに対してCSR（証明書署名要求）を提出し，署名を行ってもらいます。OCIサービス外部で証明書を使用する際に利用します
- コンソール上では「
内部CAによって発行され，外部で管理（Issued by internal CA, managed externally）」と表現されています
1-2. パブリックのデジタル証明書の格納・他OCIサービスからの参照
もう一つの機能として，サードパーティのCA（認証局）によって発行された証明書を登録することができます。証明書をこの機能を通じてインポートすることで，内部管理の機能で発行されたプライベート証明書と同様に，ロードバランサやAPIゲートウェイなどのサービスと連携することできるようになります。
対象は特にパブリックな証明書に限定しているわけではないですが，主なユースケースとしてはロードバランサなどの公開向けサービスとの連携が多いと思いますので，見出しを「パブリックのデジタル証明書～」としています。
証明書をインポートする際，上記の「内部管理」「外部管理」と分ける形で，コンソール上では「インポート済（Imported）」と表現されています。
2-0. 作成における前提条件
プライベートCAを作成する前に，以下の３つを事前に作成しておく必要がありますので，確認しておきましょう。カッコの中身は実際にサービス内で作成するものです。
- Vault（マスター暗号化キー）
- オブジェクトストレージ（バケット）
- IAMポリシー（動的グループ，IAMポリシー）
(1) Vaultの作成
CA を作成する前に，OCIのキー管理サービスである OCI Vault にて CA が使用する秘密鍵を作成する必要があります。OCI Vault の画面にて Vault を作成，その後マスター暗号化キーからキーを作成します。以下，キーを作成するときの注意点です。
- 非対称暗号アルゴリズムにする（RSA・ECDSA）
- 保護モードを「HSM」にする（「ソフトウェア」はCAの作成の際には選択できません）
(2) バケットの作成
CRLを格納するための空のバケットを作成しておきます。一応，プライベートで作成しても問題ありません。
(3) IAMポリシーの作成
作成したCAが，Vault内の鍵およびオブジェクトストレージにアクセスできるようポリシーを設定する必要があります。
まずは動的グループ（例：dg-certificates-ca）を作成します。
以下のルールでは，Certificatesサービス内のすべてのCAが対象になります。
resource.type="certificateauthority"
特定のコンパートメント内のCAに限定する場合は以下のようになるでしょうか
all { resource.type="certificateauthority", resource.compartment.id='' }
その他，動的グループの記述ルールの詳細はこちらを参照してください。
次にVaultの鍵とオブジェクトストレージにアクセスを許可するポリシーを作成します。
Allow dynamic-group dg-certificates-ca to use keys in compartment comp-dev
Allow dynamic-group dg-certificates-ca to manage objects in compartment comp-dev
これで準備が整いましたので，Certificates の画面より，CAを作成します。
2-1. CAを作成する
「ルート認証局」と「下位認証局」がありますが，ここでは「ルート認証局」を作成することとします。
同じテナントで同じCA名は使えませんので，重複しないようにします。あとから命名を変更することはできず1，CAの削除には最低でも7日かかるので再作成する際は注意してください。
サブジェクト情報を記入します。サブジェクトの各属性は RFC 52802 を確認してください。
CAの有効期限の開始日時と終了日時をUTCで指定します。
- 開始日時
- デフォルトでは何も設定されていません。日付を指定しない場合，CAの有効期間は即時に開始されます
- 終了日時
- CAおよびその下位CAや発行した証明書が使用できなくなる日時を指定します
- 開始日時より1日以上後の日付を指定する必要があります
- 2037年12月31日より後の日付は指定できません
- デフォルトで１０年後が自動設定されます
特にCAの有効期間より後の日付の証明書は発行できないため，CA有効期限は特に考慮しておきます。
次に，事前に作成した Vault とマスター暗号化鍵をCAの秘密鍵として登録します。この際，保護モードがHSMになっていないものは選択できません。
続くルール設定の「証明書の最大有効期間（日数）」では，このCAが発行する証明書の有効期間の上限を日数で指定します。OCIのドキュメントでは，有効期間を90日以内に設定することが推奨されています。なお，この設定は後から変更可能です。
CRLを格納するためのオブジェクトストレージ・バケットを指定します。
オブジェクト名を指定します。オブジェクト名に使える文字列のルールは，こちらを参照してください。
また，オブジェクト名に中括弧 {} を使用するとその部分にCAバージョン番号が挿入され，バージョンごとに固有のCRL配布ポイント（CDP）となり，上書き防止にすることができます。
「カスタム形式のURL」を設定すると，発行した証明書にCDPとしてX509v3 CRL Distribution Points:フィールドが作成されます。こちらも同様にURLに中カッコを含めることで，発行元CAのバージョン番号に置換するよう指定することができます。
最後に設定を確認し，[認証局の作成]を選択。ステータスが「アクティブ」になれば，CAが正しく作成されたことを確認できます。
なお，前提条件として必要なIAM権限やVault鍵の権限が不足していると，CA作成時に以下のエラーがでます。
Authorization failed or requested resource not found: Key Id
ocid1.key.oc1.iad.a47fres.abwucjisawsisjraur3eievy3rzfrishruiosgrus4879w65
2-2. CA証明書の管理
・ダウンロードする
作成したCAによって署名された証明書を使用する場合，当然クライアントにCAの証明書を配布する必要があります。
CA証明書は，コンソールの「認証局の詳細」画面で「バージョン」タブを選択し，該当バージョンのケバブメニューから「コンテンツの表示」を選ぶことで取得できます。
CLI を使う場合は以下のコマンドになります。
証明書および証明書チェーンの取得
oci certificates certificate-bundle get --certificate-id --version-number
・CA証明書を更新する
コンソールの「認証局の詳細」画面で「バージョン」タブを選択，「認証局の更新」から更新することができます。
デフォルトでは証明書を更新すると，それが現在の証明書バージョンになります。「保留中に設定」のチェックボックスを選択することで，証明書バージョンを文字通り”保留”にしたまま作成することができます。
更新ボタンを押すと，更新は数秒で完了します。
あとで現行バージョンを明示的に切り替えることができます。
・失効させる
ルートCA証明書自体を失効させることはできません。
失効させる場合，発行された証明書を失効させ，理由を「CA危殆化（CA_COMPROMISE）」とします。
3-1. 証明書を作成する
a. 内部管理（内部CAによって発行済）
このケースでは，鍵ペアの作成から署名要求，証明書発行までの一連の動作をすべてコンソール上で完結させることができます。作成したCAの詳細画面からも作成することができますし，サービス画面トップの「証明書の作成」から作成することもできます。
以下画面ショットは「証明書の作成」から作成した場合です。
更新ルールはなくすこともできます。
最後にサマリーを確認し，「証明書の作成」を選択します。
b. 外部管理（内部CAによって発行され，外部で管理）
鍵ペアはすでに手元にあり，CAに署名だけしてほしい場合に使用します。
手順は簡単です。証明書の名前など基本的な項目を入力した後，OCIコンソールに作成したCSRを入れ，「作成」を選択します。
数秒で作成され，ステータスがアクティブになります。
「バージョン」欄の「コンテンツの表示」より，証明書の内容を取得できます。
c. インポート済
上記の a.，b. は，作成したプライベートCAに関連する証明書の設定でした。最後に，外部の証明書にて署名をしてもらった証明書をOCI Certificatesにインポートする流れです。
ここにて登録した証明書は，失効手続きや証明書の更新をすることはできないですが，ロード・バランサや APIゲートウェイで使用するものを OCI Certificates に入れておきたい場合に主に使用します。
この証明書の格納に必要なものは以下の３つです。いずれも必須項目になります。
- デジタル証明書
- 証明書チェーン
- 秘密鍵
3-2. 証明書を更新する
デフォルトでは，証明書を更新するとそれが現在の証明書バージョンになります。証明書バージョンを直接アクティブにしないまま作成するには，「保留中に設定」のチェックボックスを選択します。
a. 内部管理
内部管理の証明書の場合，証明書更新はすぐ済みます。
b. 外部管理
外部管理の場合は，作成した手順と同様に CSR を上げることで更新を行います。
c. インポート済み
できません。サードパーティのCAが署名してるので当たり前ですが。
なお，”OCI Certificatesに登録した証明書の更新” をすることは可能です。証明書の更新自体は別途サードパーティCAに署名してもらう作業を踏む必要があります。OCI Certificatesサービスを経由して証明書更新作業を行うことはできません。
この更新手順としては作成と同様になります。Let’s Encrypt のような外部のCAに署名してもらい，もらった鍵や証明書をアップロードし直します。また，インポート済みには「保留中に設定」がありませんので，それにも注意します。
ここで更新した場合，紐づいている（アソシエーションとなっている）ロード・バランサなどのサービスにも自動で反映されます。うれしいね。
この更新作業を CLI で行う場合は以下のコマンドになります。
CLIで証明書登録を更新
oci certs-mgmt certificate update-certificate-by-importing-config-details --cert-chain-pem --certificate-id --certificate-pem --private-key-pem
CLI のその他オプションは こちら から確認してください。
3-3. 証明書を失効する
失効させたい証明書バージョンのケバブメニューより「バージョンの取り消し」を選択。
失効理由と失効対象の証明書バージョンを入力することで作業を確定させます。
実行自体は40秒程度で完了しました。
失効が完了すると，失効情報が格納されたオブジェクトストレージのバケットが DER 形式で作成されます。{}を使用している場合，CAのバージョンが置換され命名されます。
3-4. 秘密鍵をエクスポートする
a.の手順にて証明書を作成してもらったはいいものの，秘密鍵をエクスポートしたくなった時があるかもしれません。（c.でインポートした証明書の秘密鍵もこの手順で取得できますが，そもそも証明書の作成時点で手元にあるはずです）
秘密鍵はコンソールからダウンロードできないため，以下のように OCI CLIを使用します。
秘密鍵の取得（証明書と証明書チェーンのおまけ付き）
oci certificates certificate-bundle get --certificate-id --bundle-type CERTIFICATE_CONTENT_WITH_PRIVATE_KEY
デフォルトでは秘密鍵は表示されないため，--bundle-typeにてCERTIFICATE_CONTENT_WITH_PRIVATE_KEYを明示的に指定する必要があります。
その他オプションは こちら を参照ください。
以下は結果の例です
出力例
{
"data": {
"cert-chain-pem": "-----BEGIN CERTIFICATE-----\nMIIJpTCCB42gAwIBAgIUATqBpChXQpnxhmwdaoVW3t4J4bUwDQYJKoZIhvcNAQEL\nBQAwPzEgMB4GA1UEAwwXa29pbjN6IEludGVybmFsIFJvb3QgQ0ExCzAJBgN...xFNJk7J6hg5sjeaHrLeo5sK02\nEvHduOVGcog+B4Vj66vli\n-----END CERTIFICATE-----\n",
"certificate-bundle-type": "CERTIFICATE_CONTENT_WITH_PRIVATE_KEY",
"certificate-id": "ocid1.certificate.oc1.iad.amaaaaaaci3cbmyaumgzsjl5tmplqtbqz7ettuo6rubszi5og6usxjaoxdgq",
"certificate-name": "certificate-private-iad-test01",
"certificate-pem": "-----BEGIN CERTIFICATE-----\nMIIHxTCCBa2gAwIBAgIUY/SyfhZwhvztiZ68z5lXg1EOcNEwDQYJKoZIhvcNAQEL\nBQAwPzEgMB4GA1UEAwwXa29pbjN6IEludGVybmFsIFJvb3QgQ0ExCzAJBgN...SOFkki5KBgJP9CqFOlH3y2yqWKdzMC4z\n-----END CERTIFICATE-----\n",
"private-key-pem": "-----BEGIN PRIVATE KEY-----\nMIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQDGqO+NN5GaqJaR\nvIn8Co+GZ1GgqWzGVT+tyrEGOt3QNi1PZmV4+OimTJDhX88phgYtXz2xDn2fk...cSp6dRQaIUpYqYzHMUsNTpX3HTC4d7H\n-----END PRIVATE KEY-----\n",
"private-key-pem-passphrase": null,
"revocation-status": null,
"serial-number": "570647017032302961345087667198364563456316567761",
"stages": [
"CURRENT",
"LATEST"
],
"time-created": "2025-05-20T05:53:16.942000+00:00",
"validity": {
"time-of-validity-not-after": "2025-08-18T00:00:00+00:00",
"time-of-validity-not-before": "2025-05-20T05:53:16+00:00"
},
"version-name": null,
"version-number": 1
}
}
CAの秘密鍵の場合は OCI Vault にありますね。
特定のリソース・タイプにのみスコープを限定する場合，次のような個別リソース・タイプがあります3
- leaf-certificates
- leaf-certificate-versions
- leaf-certificate-bundles
- certificate-associations
- certificate-authorities
- certificate-authority-versions
- certificate-authority-bundles
- certificate-authority-delegates
- certificate-authority-associations
- cabundles
- cabundle-associations
また，複数の個別リソース・タイプをまとめてスコープ指定できる，集約リソース・タイプも２つが用意されています。
- leaf-certificate-family
- certificate-authority-family
それぞれの包含関係は以下のようになっています。
| 個別リソース・タイプ | 集約リソース・タイプ (leaf-certificate-family) |
集約リソース・タイプ (certificate-authority-family) |
説明 |
|---|---|---|---|
| leaf-certificates | ◯ | ◯ | 各証明書 |
| leaf-certificate-versions | ◯ | ◯ | 各証明書のバージョン |
| leaf-certificate-bundles | ◯ | ◯ | 証明書バンドル |
| cabundles | ◯ | ◯ | CAバンドル |
| cabundle-associations | ◯ | ◯ | CAバンドル関連付け |
| certificate-associations | ◯ | ◯ | 証明書の関連付け |
| certificate-authorities | ◯ | 認証局 | |
| certificate-authority-versions | ◯ | 認証局のバージョン | |
| certificate-authority-bundles | ◯ | 認証局バンドル | |
| certificate-authority-delegates | ◯ | 認証局デリゲート | |
| certificate-authority-associations | ◯ | CA関連付け |
どのようなAPIとマッピングするかはドキュメントを参照ください。
OCI上のクラウド設定やアクティビティに潜むリスクとなるものを自動で検出してくれるサービスとして，Cloud Guardがあります。この Cloud Guard は，OCI Certificates サービスとも連携しており，以下の証明書関連の特定のアクティビティも検知してくれます。
- CAバンドルの更新時
- 証局(CA)バンドルが削除されたとき
- CAバンドルの中間証明書が取り消されたとき
Cloud Guardのディテクタルールに「ロード・バランサのSSL証明書がまもなく期限切れになります」というものがありますが，OCI Certificatesサービスによって発行された証明書の場合，検知されず問題がレポートされない問題があるようです。4
その他，既知の問題も公開されています。
サービス制限は以下のようになっています。5
| リソース | 制限数 |
|---|---|
| テナンシ内のCA | 100（無料アカウントの場合は5） |
| テナンシ内の証明書 | 5000（無料アカウントの場合は150） |
| CAバンドル | 25 |
| 証明書バージョン | 30 |
| 削除予定の証明書バージョン | 30 |
| 特定の証明書ごとの連携数 | 30 |
Views: 0
