📑

なぜPCによってSSL証明書が動いたり動かなかったりするのか？中間証明書を理解する

に公開
SSL
証明書
tech

はじめに

ある日、自社内ではサーバーを問題なく使えるのに、一部のお客さんからはサーバーに接続できない時が頻繁に起こるとクレームが寄せられました。初めはセキュリティが厳しい企業のネットワークによるものだと考え、あまり深く考えておりませんでしたが、よくよく調べてみるとSSL証明書周りで接続エラーになっていることを発見しました。エラーを元に調査を進めていくと中間証明書をサーバーが返していないためSSLのエラーが起こっていました。

この記事では、この謎をきっかけに学んだ SSL/TLS証明書の仕組みと中間証明書の役割 をまとめます。

SSL証明書の基本構造

SSL証明書は「公開鍵基盤（PKI）」という仕組みで成り立っています。
証明書はピラミッドのように階層構造になっており、主に3種類あります。

  • ルート証明書
    信頼の起点。各OSやブラウザに最初から組み込まれている。
  • 中間証明書
    ルートとサーバーをつなぐ橋渡し。普段はこれが署名を行う。複数ある場合もあります。
  • サーバー証明書
    実際に example.com のようなドメインに発行される証明書。

ルート証明書が中間証明書を証明し、中間証明書がサーバー署名書を証明するといった具合です。
もし、ルート証明書が誰かしらに改竄された日には、悪意あるサーバーを信頼してしまうので要注意です。

なぜ中間証明書が必要なのか？

「ルート証明書で全部署名すればいいのでは？」と思うかもしれません。
実はそれができないのには理由があります。

  1. ルート証明書は最重要なのでオフラインで厳重管理
    → 普段は使わず、漏洩を防ぐために金庫で眠っている。
  2. リスク分散
    → 中間CAごとに失効できる。ルート全体を失効する必要がない。
  3. 更新しやすい
    → ルートは20年以上の有効期限。中間は数年ごとに更新して暗号方式を世代交代できる。
  4. 用途の分離
    → Web用、コード署名用など、役割に応じて中間CAを分けられる。

つまり、中間証明書は「ルートを守る盾」であり「運用を柔軟にする仕組み」でもあります。

なぜPCによって動いたり動かなかったりするのか？

サーバーが中間証明書を返さない場合、挙動はPCや環境によって変わります。

  • キャッシュされている場合
    → 以前アクセスしたサイトで使った中間証明書を覚えているので動く
  • OSやブラウザに組み込み済みの場合
    → 一部の中間証明書は最初から入っている
  • AIA Fetch が有効な場合
    → 証明書に書かれたURLから自動で中間証明書を取得してくれる

逆にこれらがない場合は「信頼できません」とエラーになります。
だからこそサーバー側では 必ず fullchain.pem（サーバー＋中間証明書セット）を返す必要がある のです。

CA証明書とルート証明書

  • ルート証明書
    各OSやブラウザが持つ「信頼の起点」。数百本単位であらかじめインストールされている。
  • CA証明書
    認証局（CA）が発行する証明書の総称で、ルートや中間が含まれる。
  • 危険性
    悪意あるルート証明書がPCに入ってしまうと、その端末は偽の証明書でも信頼してしまう。
    → これは「中間者攻撃（MITM）」につながる。

実際の確認方法（openssl）

証明書の動作確認には openssl コマンドが便利です。

  • サーバーから証明書チェーンを確認

    openssl s_client -connect example.com:443 -showcerts

  • 証明書の詳細を確認

    openssl x509 -in cert.pem -text -noout

  • 有効期限の確認

    openssl x509 -enddate -noout -in cert.pem

まとめ

  • SSL証明書は「ルート → 中間 → サーバー」の3層構造で成り立つ

  • 中間証明書はセキュリティと運用のために必須

  • サーバーが中間証明書を返さないと、環境によって動いたり動かなかったりする

  • 確実にエラーを防ぐには fullchain.pem を設定すること

今回の学びで、なぜ不安定な動作が起きていたのかがクリアになりました。
証明書の仕組みを理解すると「なぜ？」が解けて気持ちいいですね。

Discussion