はじめに
近年、内部システムでも TLS（Transport Layer Security）が前提条件となりました。API、Web サービス、Kubernetes 内のサービス間通信、監視系、レジストリ、LDAP、データベース接続まで、暗号化は「前提」です。
一方で、内部向けに自己署名証明書（Self-Signed）を運用するケースは依然多く、発行・更新・配置は煩雑です。そこで便利なのが「自己署名ワイルドカード証明書」。*.example.com のように広い範囲を 1 枚でカバーできますが、自己署名の性質とワイルドカードの広さが重なり、リスクも肥大化します。
本稿では、利点 → リスク → DNS と証明書の適用範囲（技術的制約）→ 実運用の設計指針（役割境界）の順に整理します。
メリット: 内部環境では強力な省力化
- 証明書管理の負担軽減
サブドメインが増えても、サービスごとに個別発行せずにすばやく HTTPS 化できる。 - ACME 非依存の自動化
自己署名なら ACME 前提でなくても Ansible / CI/CD で更新を完全自動化しやすい（有効期限・鍵長などを自前統制）。 - コストゼロで広範カバー
商用 CA 費用がかからず、内部の多数サービスを一括で保護しやすい。
デメリット: 集中による脆弱化
- 秘密鍵漏洩の影響が大きい
1 つの秘密鍵を複数サービスで共有するため、1 サービスの侵害＝同じ証明書を使う全体が危険という構造を持つ。さらに自己署名では、CA 秘密鍵の漏洩＝内部 PKI 全崩壊に直結。 - 更新・失効の影響半径が広い
有効期限切れや入替え時、関連システムを一斉更新する必要が生じやすい。 - “使い回し”が境界を曖昧にする
役割の異なるシステムを 1 枚の証明書で束ねると、侵害時の巻き込み範囲（ブラスト半径）が拡大。
ドメインとワイルドカード証明書の適用範囲（技術的制約）
まず、「技術的にどこまで同じ証明書が“使える”か」を明確にします。
*.example.comはapi.example.comやauth.example.comに適用できる。*.int.example.comと*.core.example.comは別ラベルのため、同一ワイルドカードではカバー不可。- 異なるサブドメインを跨いで使うには SAN（Subject Alternative Name）に個別列挙が必要。
- ただし SAN を増やすほど“技術的には使えるが、攻撃面積も広がる” 点は忘れてはいけない。
- 上位ワイルドカード（例：
*.comや*.example.comを何でもかんでも使い回す発想）はアンチパターン。
設計指針: 実運用では「役割（責務・目的）」で境界を引く
全く目的が異なるシステムでも、同一のドメインを使用する場合があります。この時、ワイルドカード証明書として共有する場合、片方が侵害されたときもう片方も巻き込まれることを許容するという意思決定です。したがって、共有可否はドメインではなく役割で判断します。
- 役割・権限・機密度・更新頻度・運用者が異なるなら分ける。
例：- VPN（VPN サーバーの証明書: 利用者は VPN に接続することが目的）
- 業務アプリ（Web サーバーの証明書: 利用者は業務アプリを使用することが目的）
- まとめても良いのは、同じ運用者・同じ責務・同じリスク許容度で小さく閉じる範囲だけ。
その場合も、有効期限短縮・頻繁ローテーション・配布経路の厳格化（コード化）・利用在庫の可視化をセットで。
この考え方は商用の正式な証明書でも同じです。
まとめ
- 技術的制約（DNS/SAN）は「どこまで使えるか」を決める。
- 設計判断（役割境界）は「どこまで使ってよいか」を決める。
- 自己署名ワイルドカードは内部運用を劇的に楽にする一方、集中に伴う脆弱化を招きやすい。
- 同じ鍵で束ねて許容できる範囲だけ共有、他は分離。
領域を明確に分け、鍵の共有範囲を最小化できれば、自己署名ワイルドカード証明書は内製インフラに非常に適したツールになります。
自己署名ワイルドカード証明書の設計指針