サーバー証明書完全ガイド：TLS/SSLの仕組み・発行・更新・運用を徹底解説

2025年11月20日 最終更新日時 : 2025年11月20日 エバープレイ編集部

サーバー証明書とは — 概要と役割

サーバー証明書（サーバー証明、サーバ証明書）は、ウェブサーバーやメールサーバーなどが自らの正当性を証明し、通信を暗号化するために使われるデジタル証明書です。一般にTLS（旧称：SSL）プロトコルと組み合わせて利用され、ブラウザやクライアントとサーバー間の通信を第三者による盗聴や改ざんから守ります。

基本構造と技術的要素

  • 公開鍵基盤（PKI）と鍵ペア：証明書は公開鍵（public key）と、その公開鍵が特定の主体（例：example.com）に属することを示す情報を含みます。対応する秘密鍵（private key）はサーバー側で厳重に保護します。

  • 署名と認証局（CA）：信頼できる認証局（CA: Certificate Authority）が発行することで、その証明書が有効であると第三者（ブラウザ等）が検証できます。CAは中間証明書（intermediate）を使ってルート（root）までの証明書チェーンを構築します。

  • 証明書チェーン：クライアントはサーバーが送る「サーバー（葉）証明書 → 中間証明書 → ルート証明書（信頼ストア内）」というチェーンを辿って検証します。ルート証明書はOSやブラウザの信頼ストアに登録されている必要があります。

  • 有効期間と失効：証明書には有効開始日と有効期限があり、期限切れになると無効とみなされます。失効（revocation）はCRLやOCSPなどの仕組みで通知されます。

証明書の種類（発行ポリシー）

  • ドメイン認証（DV: Domain Validation）：ドメインの所有／制御を確認するのみで発行される最も簡易な証明書。短期間で自動発行されることが多い（例：Let's Encrypt）。

  • 組織認証（OV: Organization Validation）：ドメインに加えて申請組織の実在性を確認して発行。企業サイト等で用いられることが多い。

  • 拡張認証（EV: Extended Validation）：より厳格な身元確認が行われる。かつてブラウザUIで企業名を強調表示するなどの専用表示があったが、現在は表示差が縮まっている。

SAN、ワイルドカード、CN について

証明書は複数ドメインを一枚でカバーするために SAN（Subject Alternative Name） フィールドを持ちます。CN（Common Name）は歴史的にホスト名を示すため使われてきましたが、現在はSANが優先されます。ワイルドカード証明書（*.example.com）は一段階下のサブドメインをまとめてカバーします（例：www.example.com は可、api.dev.example.com は不可）。

発行と更新の実務

  • CSR（Certificate Signing Request）作成：サーバー側で秘密鍵とCSRを生成し、CSRをCAに提出して証明書を発行してもらいます。例（OpenSSL）：

    openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048
openssl req -new -key server.key -out server.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

  • インストール：サーバーに証明書ファイルと中間証明書、秘密鍵を配置し、ウェブサーバー（Apache/Nginx）やロードバランサ、CDNに設定して再起動します。

  • 自動更新：有効期限に備えて自動更新が推奨されます。Let's Encrypt は Certbot 等のクライアントで自動化できます。期限切れはサービス停止やブラウザ警告の原因になります。

検証の流れ（ブラウザ側）

  • クライアントはサーバーの証明書を受け取り、署名チェーンを構築して信頼できるルートに到達するか確認する。
  • 証明書の有効期限内であることを確認する。
  • ホスト名（例：example.com）が証明書のSANに含まれているかを確認する。
  • 失効情報（CRL/OCSP）をチェックする。OCSPステープリングが使われている場合はサーバーがCAのOCSP応答を提示する。

失効（Revocation）とその課題

失効の伝達方法には従来のCRL（Certificate Revocation List）とOCSP（Online Certificate Status Protocol）がありますが、CRLはファイルサイズと更新遅延の問題があり、OCSPはリアルタイム問い合わせによる遅延やプライバシー問題が指摘されます。OCSPステープリングはサーバーがCAから取得したOCSPレスポンスをクライアントに添付する方式で、性能とプライバシーの改善に寄与します。さらに「Must-Staple」拡張を使うとステープル必須を宣言できます。

セキュリティ上のベストプラクティス

  • 鍵長はRSA 2048bit以上、可能ならECC（secp256r1）を検討する。
  • 署名アルゴリズムは SHA-256 以上（SHA-1 は廃止済み）。
  • TLS バージョンは TLS 1.2 と TLS 1.3 を許可し、古い TLS 1.0/1.1 は無効化する。
  • 前方秘匿性（ECDHE）を有効にし、弱い暗号スイート（RC4、3DES、NULL）を無効化する。
  • OCSPステープリング、HSTS（HTTP Strict Transport Security）、HTTPS リダイレクトを有効化する。
  • 秘密鍵はファイルシステム上でも厳重に保護し、可能ならHSMやクラウドKMSを使用する。
  • 自動更新と監視を設定して期限切れや設定ミスを防ぐ。

特殊な用途・拡張

  • ワイルドカード証明書：多数のサブドメインがある場合に便利だが、一枚の秘密鍵破損で多くのサービスが影響を受けるというリスクがある。
  • マルチドメイン（SAN）証明書：複数のドメイン名を一つの証明書でカバーできる。
  • 相互 TLS（mTLS）：クライアント証明書を使ってサーバーがクライアントを認証する。API や社内システムで利用される。
  • Certificate Transparency（CT）：発行された公開証明書をログに記録することで、不正発行の検出を容易にする仕組み。多くのブラウザがCTログを参照する。

運用上の注意点とよくあるトラブル

  • 中間証明書の設定漏れ：チェーン不備でブラウザ警告になる。
  • 秘密鍵の漏洩：直ちに証明書を失効させ、再発行する必要がある。
  • 有効期限切れ：更新の自動化とアラートが必須。
  • ホスト名不一致：SAN への未登録やCN のみ存在する設計ミスが原因。
  • 古い暗号設定：セキュリティ弱体化やブラウザ互換性問題の発生。

実務で使うコマンド例（確認用）

証明書の内容を確認する（PEM形式）：

openssl x509 -in server.crt -text -noout

CSRを表示する：

openssl req -in server.csr -noout -text

秘密鍵から公開鍵を表示する：

openssl pkey -in server.key -pubout -outform PEM

まとめ

サーバー証明書は、安全なインターネット通信の基盤を成す重要な要素です。適切な発行元の選定、鍵と証明書の安全な管理、最新の暗号設定と自動更新の仕組みを整えることが、サービスの可用性とセキュリティを保つ鍵となります。近年は自動化された短期間の証明書（例：Let's Encrypt）やTLS 1.3の普及でセキュリティ基準が上がっていますが、運用ミスや設定漏れは依然として大きな事故源です。定期的な監査とベストプラクティスの導入を推奨します。

参考文献

カテゴリー
IT
前の記事
ハイド（HYDE）完全ガイド：L'Arc〜en〜CielからVAMPSまでの全貌と音楽性New!!
2025年11月20日
次の記事
ハイドの音楽を深く味わうレコードガイド：Roentgen〜Faith〜VAMPSまで、盤の差と聴き方でコレクションを極めるNew!!
2025年11月20日