自己署名ワイルドカード証明書の設計指針 – 内部 PKI と秘密鍵の境界

内部システムで TLS を使う場合、自己署名証明書や内部 CA を使って証明書を発行することがあります。その中でもワイルドカード証明書は、*.example.com のように複数のホスト名を 1 枚で扱えるため、運用をかなり楽にできます。

ただし、自己署名または内部 CA の証明書とワイルドカード証明書を組み合わせると、便利さと引き換えに秘密鍵の影響範囲が大きくなります。この記事では、自己署名ワイルドカード証明書を内部システムで使う場合の設計指針を整理します。

自己署名証明書と内部 CA を分けて考える

まず、言葉を分けておきます。よく「自己署名証明書」と呼ばれますが、実運用ではサーバー証明書そのものを自己署名するより、内部 CA を作り、その CA でサーバー証明書を署名する構成の方が扱いやすくなります。

内部システムで継続的に使うなら、設計対象は「1 枚の自己署名証明書」ではなく、内部 CA、サーバー証明書、秘密鍵、配布先、更新方法を含む小さな PKI として考えるべきです。

ワイルドカード証明書の適用範囲

ワイルドカード証明書は便利ですが、どこまでも広く使えるわけではありません。*.example.com は web.example.com や ldap.example.com には使えますが、a.b.example.com のような 2 階層下の名前には一致しません。

複数の名前を 1 枚にまとめたい場合は SAN、つまり Subject Alternative Name に複数の DNS 名を入れます。ただし、SAN を増やすことは、技術的な適用範囲を広げるだけでなく、秘密鍵が漏れたときの影響範囲も広げます。

便利さよりも秘密鍵の影響範囲を見る

ワイルドカード証明書の最大の問題は、証明書そのものではなく秘密鍵の共有範囲です。1 枚の証明書を多くのサービスに配るということは、同じ秘密鍵を多くの場所に配置するということです。

判断基準は「同じドメイン配下か」ではありません。同じ秘密鍵を共有してよい責務かです。DNS 名の近さではなく、運用責任、機密度、復旧単位、利用者の範囲で境界を引く方が安全です。

内部システムでの分け方

内部システムでは、ドメイン構造と証明書の境界を揃えたくなります。しかし、実際には役割で分けた方が事故に強くなります。

OpenSSL で SAN 付きワイルドカード証明書を作る例

内部 CA がある前提で、ワイルドカード名を SAN に入れる例です。実運用では、秘密鍵の保管場所、権限、更新手順、配布方法を別途設計します。

cat > wildcard-openssl.cnf <<'EOF'
[ req ]
default_bits       = 4096
prompt             = no
default_md         = sha256
distinguished_name = dn
req_extensions     = req_ext

[ dn ]
CN = *.int.example.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = *.int.example.com
DNS.2 = int.example.com
EOF

openssl genrsa -out wildcard.int.example.com.key 4096
openssl req -new   -key wildcard.int.example.com.key   -out wildcard.int.example.com.csr   -config wildcard-openssl.cnf

CSR を内部 CA で署名するときも、SAN が証明書に反映されているかを確認します。

openssl x509 -in wildcard.int.example.com.crt -noout -text | grep -A2 "Subject Alternative Name"

LDAPS では名前解決と証明書名が重要になる

Active Directory や LDAP サーバーで LDAPS を使う場合、証明書の CN / SAN と接続先名が一致している必要があります。IP アドレスで接続する、別名で接続する、DNS 名と証明書名がずれている、といった状態では検証に失敗しやすくなります。

そのため、LDAPS 用の証明書は「とりあえずワイルドカードでよい」と考えるより、接続名、DNS、証明書、信頼 CA をセットで設計するべきです。特に認証基盤は他の内部 Web サービスよりも影響範囲が大きいため、専用証明書に分ける判断も十分にあります。

運用で決めておくこと

証明書は作って終わりではありません。むしろ運用で破綻しやすいのは、有効期限、更新、配布、失効、棚卸しです。

• 証明書と秘密鍵の配置先を一覧化する
• 有効期限を短めにし、更新を自動化する
• 秘密鍵を配布する経路を限定する
• CA 秘密鍵はサーバー証明書の秘密鍵より厳格に保護する
• 利用していない証明書を残さない
• 証明書名、DNS 名、接続名を一致させる
• 認証基盤、管理系、一般アプリを同じ鍵で混ぜない

まとめ

自己署名ワイルドカード証明書は、内部システムを素早く TLS 化するには便利です。しかし、便利だからといって 1 枚の証明書を広く使い回すと、秘密鍵漏洩時の影響範囲が大きくなります。

設計上の本質は、どの DNS 名に使えるかではなく、どの責務まで同じ秘密鍵で束ねてよいかです。内部 CA、SAN、DNS、LDAPS、配布先、更新方法をまとめて設計できれば、自己署名ワイルドカード証明書は内製インフラにとって有用な道具になります。

参考

• OpenSSL – openssl-req
• OpenSSL – openssl-x509
• RFC 6125 – Service Identity Verification

Related posts:

EAP-TLS と EAP-TTLS 何が違う？ CentOS 7 SSL 証明書 – 自己署名 CA と内部向け TLS の基本 CentOS 7 Apache TLS 設定 – 自己署名証明書で HTTPS 化する CentOS 8 easy-rsa を使用した SSL 証明書の作成 VyOS OpenVPN Site-to-Site TLS 設定と MTU の考え方 Ubuntu 22.04 update-ca-certificates – 内部 CA と自己署名証明書を信頼する Ubuntu 22.04 Apache TLS – 内部 CA 証明書で HTTPS を有効化する Apache の中間証明書の指定方法が変わった Ubuntu 22.04 389 Directory Server #2 – TLS 有効化と LDAPS 設定 Redmine メール送信時の certificate verify failed Chrome でのみ TLS 証明書エラーが発生 OpenVPN tls-auth を活用したセキュリティ強化