1. はじめに
CISの証明書の種類は色々あって若干混乱するため、整理するのが目的です。
本記事はEdge用途の証明書について紹介します。
Origin用途の証明書については、こちらを参照してください。
また、以下の説明を読む前に、イマドキの証明書は全部マルチドメイン証明書を読んでおくと、理解が深まると思います。
2. Edge用証明書の種類とその作り方
通信の流れ
ブラウザ -> Edge(Reverse Proxy: CISの実体) -> Origin(Web Server)
ブラウザとEdge間の通信を暗号化するためには、Edgeに証明書が必要になります。Plan比較の資料によると、Edge用に利用できる証明書には、以下の4種類があります。
- Universal wildcard（単にUniversalと記載されることもあり）
- Dedicated wildcard（単にDedicatedと記載されることもあり）
- Dedicated custom
- Uploaded custom
なお、複数証明書が存在する際の優先度は、Uploaded custom, Dedicated custom, Dedicated wildcard, Universal wildcardの順になります。
https://cloud.ibm.com/docs/cis?topic=cis-manage-your-ibm-cis-for-optimal-security#certificate-prioirity-at-our-edge
以下は、CISで管理登録したドメイン名がcertest.tkであるという前提で記載します。下記の表からわかるように、組織(O)情報や組織単位(OU)情報などを自社のものに合わせてカスタマイズした証明書を作成したい場合は、ちゃんと証明書を購入してUpload customを利用する必要がありそうです。
| Universal wildcard | Dedicated wildcard | Dedicated custom | Upload custom | |
|---|---|---|---|---|
| 作成方法 | デフォルトで作成される。削除はできない。しかし、Security -> AdvancedからUiversal wildcardを利用できないようにする（無効にする）ことは可能。
|
Customer PortalのSecurity -> TLSから注文可能("Add up to 50 custom hostnames"を選択しない）。
|
Customer PortalのSecurity -> TLSから注文可能("Add up to 50 custom hostnames"を選択する）。
|
証明書業者から購入したサーバー証明書とそのPrivate keyをCISにuploadする（自己署名証明書は不可）。 Bundle methodについての説明はこちら 
|
| CN(Common Name) | sni.cloudflaressl.com | certest.tk | certest.tk | 利用者が自身で定義可能 |
| 組織情報 | Cloudflare, Inc | Cloudflare, Inc | Cloudflare, Inc | 利用者が自身で定義可能 |
| SAN | 「certest.tk」, 「∗.certest.tk」, 「sni.cloudfalressl.com」の３つ | 「certest.tk」, 「∗.certest.tk」の2つ | 「certest.tk」と注文時に指定したFQDN（ワイルドカード利用可能）。ただし、「certest.com」のような全く別のドメインの登録は不可であり、あくまで「certest.tk」の下位階層のみが登録可能。 | 利用者が自身で定義可能 |
| 証明書の更新 | CISが自動更新 | CISが自動更新 | CISが自動更新 | 利用者責任で更新 |
3. 証明書情報出力例
3-1. Universal wildcard
3-2. Dedicated wildcard
3-3. Dedicated custom
