【OpenShift 4.14】Ingressのカスタム証明書設定とSAN・チェーン証明書の注意点まとめ
OpenShift Container Platform（OCP）では、セキュアな通信を実現するためにデフォルトで証明書が組み込まれています。しかし、企業のセキュリティポリシーや証明書統合管理の観点から、独自に用意した証明書（カスタム証明書）をIngressに設定したいというケースも少なくありません。
本記事では、OpenShift 4.14 環境においてカスタム証明書を導入する際に注意すべき点、特に「SANの必須化」と「チェーン証明書の必要性」に加え、証明書適用時の設定にはまったので記録として残します。
1. SANなし証明書はエラーに
verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead
OpenShift 4.10以降（Kubernetes 1.23ベース）では、Subject Alternative Name（SAN）なしの証明書はTLS検証時にエラーとなります。これはKubernetes本体がCommon Name（CN）フィールドの使用を非推奨とした仕様変更に基づくものです。
実際に、以下のようなエラーが oc get co コマンドで表示されるケースがあります：verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead
対応策：SAN付きのCSRを作成する
OpenSSLでSAN付きのCSRを生成するには、以下のような openssl.cnf を用意し、コマンドを実行します：
# openssl.cnf[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[ v3_req ]
subjectAltName = @alt_names
[alt_names]
DNS.1 = example.apps.ocp.local DNS.2 = *.apps.ocp.local
CSR作成
openssl req -new -key tls.key -out tls.csr \
-subj “/C=JP/ST=Tokyo/L=Chiyoda/O=ExampleOrg/CN=*.apps.ocp.local” \
-config openssl.cnf
2. チェーン証明書が必要なケース
多くの企業では、中間CAとルートCAを経由した証明書チェーンを採用しています。OpenShiftにこれらを適用する際、必ずチェーン構成の証明書として結合しておく必要があります。
チェーン証明書の作成
$ cat server.crt intermediate.crt rootCA.crt > fullchain.crt
この fullchain.crt を Ingress 用のカスタム証明書として利用します。これを怠ると、通信先のクライアント（WebブラウザやクライアントPod）側で証明書検証が失敗します。
3. 証明書適用時のクラスタ影響
カスタム証明書の適用は基本的に以下の2ステップに分かれます：
ステップ1：CA証明書の設定（proxy/cluster変更）
proxy/clusterオブジェクトにカスタムCAを設定- ノードに設定を反映するため、MachineConfigPoolによるローリングアップデート（＝ノード再起動)が発生
- このため、クラスターの安定運用時に実施が必要
ステップ2：Ingress証明書の設定
ingresscontroller/defaultにカスタム証明書を設定- この設定変更により、
router-defaultPodが再起動される
oc patch ingresscontroller default -n openshift-ingress-operator \
–type=merge -p \
‘{“spec”:{“defaultCertificate”:{“name”:”custom-ingress-cert”}}}’
4. カスタム証明書適用の手順概要
- SAN付きでCSRを作成し、CAへ署名依頼
- サーバ証明書＋中間証明書＋ルート証明書で
fullchain.crtを作成 - 以下のようなSecretを作成：
oc create secret tls custom-ingress-cert \
–cert=fullchain.crt –key=tls.key \
-n openshift-ingress
proxy/clusterにCAを設定し、クラスタへ反映ingresscontroller/defaultをpatchし、カスタム証明書を指定router-defaultPodの再起動後、証明書が反映されることを確認oc get coコマンドですべてのクラスターオペレーターが正常であることを確認- （追加）WEBコンソールに接続する端末にCA証明書を設定し、コンソール接続時に警告が出ないことを確認
5. よくあるトラブルと回避策
| トラブル内容 | 原因 | 対応策 |
|---|---|---|
| 認証エラー発生 | SANなし証明書 | SANありの証明書で再発行 |
| ブラウザで警告が出る | チェーン証明書でない | fullchain形式に統合する |
| クラスタの負荷が増える | proxy変更によりノード再起動 | メンテナンス時間帯に適用 |
| 証明書反映されない | Secret名の指定ミス | oc describe で設定を確認 |
まとめ
OpenShiftにカスタム証明書を導入する際には、SANを必ず設定し、チェーン証明書を用いることが今や前提条件です。さらに、証明書の適用はクラスタ全体に影響を与える可能性があるため、適用タイミングと手順を慎重に選定する必要があります。
OCPはセキュアかつ柔軟なプラットフォームですが、こうした証明書の扱いには一定の専門性が求められます。運用チームとしては、証明書の正しい作成・適用・更新管理まで一連の流れを理解し、確実にメンテナンスできる体制を整えておくことが重要です。
コメント