はじめに
業務で社内システムの Web アプリを HTTPS 化する機会がありました。その際、アプリエンジニアとしては見落としがちな SSL 証明書の前提知識で思わぬところにハマってしまったので、その経験を共有したいと思います。
実は私も最初は「HTTPS 化ってサーバーに SSL 証明書を設定すれば完了でしょ？」と考えていました。しかし、実際はそんなに単純な話ではありませんでした。
本記事では、次の点を中心にお伝えします。
「大手認証局の証明書を使えば、ルート証明書はデフォルトで入っているから安心」と思っていたら、イントラネット SSL は例外だった。
インフラやネットワークに詳しい方にとっては当たり前のことかもしれません。しかし、アプリケーション層の開発がメインだと、「大手の証明書を使用すれば大丈夫という思い込みで設計を進めがちなのでは？」という思いから本テーマについてまとめています。
HTTPS 通信の基本的な仕組み
まずは前提知識として、HTTPS 通信がどのように安全性を担保しているのか、簡単に振り返ってみましょう。
この中で重要なのが 「証明書の検証」 です。
証明書チェーンの仕組み
ここで重要なのが、SSL 証明書は単体で信頼されるわけではないという点です。実際には、証明書チェーンという階層構造で信頼性が担保されています。
クライアントは、
- ルート CA 証明書が自分の端末に存在するか
- そこから証明書チェーンが正しくつながっているか
を検証します。
つまり ルート CA が信頼できない場合、HTTPS 通信は拒否される のです。
私が陥った誤解：「証明書をサーバーに置けば完了」
実際に HTTPS 化作業を進めた際、私は次のような流れで進めました。
- サーバーに SSL 証明書を設定
- ブラウザから HTTPS でアクセス
- ❌ 証明書エラーが表示されて接続できない…
「サーバー設定は間違っていないはずなのに、なぜ？」と悩みました。実は、問題の本質はクライアント側の証明書の信頼関係にあったのです。
パブリック CA とイントラネット SSL、何が違う？
パブリック CA(一般的な SSL 証明書)
まず、一般的に使われる SSL 証明書について説明します。
GlobalSign、DigiCert、Let's Encrypt などの大手認証局(CA)が発行する証明書は、ルート CA 証明書が Windows、macOS、Linux などの OS やブラウザに最初から組み込まれています。
つまり、利用者は何も意識しなくても、すでに「信頼できる証明書の一覧」が端末に入っている状態です。
そのため、以下のような流れでスムーズに HTTPS 化できます。
- サーバーに証明書を設定
- 利用者は追加作業なしでブラウザから安全にアクセス可能
一般的な Web サイトの HTTPS 化なら、これで完結します。だから「大手の証明書を使えば問題ない」と考えるのは自然なことです。
イントラネット SSL(社内システム向け証明書)
ところが、社内システム向けに使われるイントラネット SSL は、この「大手認証局なら安心」という前提が通用しない特殊なケースです。
- 大手認証局が発行している証明書だが、パブリック CA とは異なる独自のルート CAを使用
- その独自ルート CA は、OS やブラウザにはデフォルトで登録されていない
この場合、
利用者の端末にルート証明書を配布・インストールしない限り HTTPS は成立しない
という前提になります。
実際にハマった経緯
私が最初に立てていた計画は、こうでした。
最初の見込み
- 大手認証局(GlobalSign)の証明書を使えば問題ない
- ルート証明書は既にユーザー端末にデフォルトで入っているはず
- → 利用者側で特別な作業は不要で、スムーズに HTTPS 化できる
通常のパブリック CA なら、この理解で正しいはずでした。
現実
調査を進めていく中で、以下の事実が判明しました。
- 今回使用する証明書はイントラネット SSLだった
- 大手認証局が発行しているが、独自のルート CA を使用している
- その独自ルート CA は OS やブラウザにデフォルトでは入っていない
- → 全利用者の端末にルート証明書を配布する必要がある
つまり、「大手の証明書なら安心」という前提が、イントラネット SSL では通用しなかったのです。
イントラネット SSL の運用が難しい理由
ルート証明書を全ユーザー端末に配布する――。文字にすると簡単そうですが、実際はかなりハードルが高い作業でした。
具体的な課題
- 利用者の端末数が多い（数百〜数千台規模）
- 端末管理の方法が部署や拠点ごとに異なる
- 一括配布の仕組みが整っていないケースもある
- 場合によっては利用者自身に作業してもらう必要がある
結果的に発生する作業
- 各部署・拠点ごとの配布手順の調整
- 利用者からの問い合わせ対応
- 「証明書エラーで開けません」というトラブル対応
こうした運用負荷が想定以上に高くなることが、事前に理解できていませんでした。
今回の学び：HTTPS は「サーバー側だけ」の話ではない
今回の経験で一番の学びは、次の点でした。
HTTPS は、サーバー・クライアント・運用の 3 つが揃って初めて成立する
アプリケーション開発をメインにしていると、どうしても意識が以下に集中します。
- Web サーバーの設定
- アプリケーションコードの実装
しかし実際には、以下の観点も含めて検討しないと、本番運用で問題が発生します。
- クライアント端末がその証明書を信頼できるか
- 必要なルート CA がどこに存在するか
- 証明書の配布・管理をどう行うか
これらを設計段階で考慮しておくことが重要です。
まとめ
今回の経験を通じて学んだポイントをまとめます。
技術的なポイント
- 大手認証局の証明書でも、イントラネット SSL は特殊
- パブリック CA はルート証明書がデフォルトで OS に入っているが、イントラネット SSL は独自のルート CAを使用
- そのため、クライアント端末にルート証明書を別途配布する必要がある
運用面でのポイント
- 利用者数が多いほど、証明書配布が大きな課題になる
- 設計段階でクライアント側の信頼関係まで考慮する必要がある
- 運用コストを過小評価しないこと
最後に
アプリケーション開発をメインにしていると、SSL 証明書周りは馴染みが薄い領域かもしれません。しかし、認証やセキュリティを扱う以上、こうした前提知識は避けて通れません。
同じように社内 Web アプリの HTTPS 化を検討されている方の参考になれば幸いです。