ホームページのSSL証明書に苦戦した話

はじめに

少し前に、個人事業の名刺代わりとなるホームページを、AWSを使って構築しました。構成はサーバーレスを中心としたシンプルなものです。
Route53でドメインを管理し、CloudFrontでリクエストを受け、Lambdaで簡単な処理を行い、静的コンテンツはS3から配信する構成です。

SSL証明書については、使い慣れていたLet's EncryptのDV証明書を取得し、ACMにインポートしてCloudFrontに適用していました。当時は「暗号化さえできていれば問題ない」と、それほど深く考えていませんでした。

証明書の種類による違いを意識したことはなく、無料で手軽に発行できるという理由だけでLet's Encryptを選んでいたのです。

「会社のパソコンから見られません」

サイト公開後、知人に確認してもらったところ、こんな連絡が届きました。

会社のパソコンからサイトを開こうとしたら、セキュリティソフトにブロックされて表示されませんでした

自宅のPCやスマートフォンでは問題なく表示されていたため、最初は原因が見当もつきませんでした。調べていくうちに、行き着いた先は証明書の種類でした。

原因調査:証明書の種類による違い

SSL/TLS証明書には、大きく3つの検証レベルがあります。

種類	検証内容	コスト	主な用途
DV証明書 (Domain Validation)	ドメインの所有権のみ	低価格	個人サイト 検証環境
OV証明書 (Organization Validation)	ドメイン所有権+ 組織の実在性	中価格帯	企業サイト全般
EV証明書 (Extended Validation)	組織の実在性を厳格に確認	高価格帯	金融系サイトなど

Let's Encryptは、無料かつ自動化された仕組みでドメインの所有権のみを検証するDV証明書だけを発行するCAです。手軽さが魅力で個人サイトでは広く使われていますが、運営組織の実在性は保証されていません。

実はこの「手軽さ」こそが、今回の問題の一因でした。企業が導入しているセキュアWebゲートウェイなどのセキュリティ製品は、アクセス先のリスク判定材料の一つとして証明書の検証レベルを利用していることがあります。

DV証明書は誰でも自動的に取得できてしまうため、フィッシングサイトにも好んで使われる傾向があり、その結果「リスクが相対的に高い」と判定され、ブロック対象になってしまうケースがあるのです。

対応:OV証明書への切り替え

有償のOV証明書を認証局から取得し、ACMにインポートしてCloudFrontに適用し直しました。
ACMが自動発行できるパブリック証明書はDV相当のみのため、OV/EV証明書を使う場合は、外部の認証局が発行した証明書をACMにインポートする手順が必要です。

切り替え後、問題があった会社のパソコンからも無事にサイトが表示されることを確認できました。

おわりに

SSL証明書は「暗号化できればよい」というだけのものではなく、閲覧環境によっては検証レベル自体が信頼性の指標として扱われることを痛感しました。

個人サイトであればDV証明書でも十分ですが、企業のホームページを公開する際は、閲覧者が安心してアクセスできるよう、OVあるいはEV証明書の利用を強くお勧めします。