HTTPSと電子証明書が守る範囲と、鍵マークが示さないこと

ブラウザのアドレス欄に鍵のような印が出ていると、そのサイトは安全だと受け取りがちです。しかしHTTPSが守るのは通信の中身と接続先のドメイン名であり、そのサイトの運営者が誠実かどうかまでは保証しません。実際、偽のサイトもHTTPSを使えます。本記事は、HTTPSと電子証明書が何を守るのかを整理したうえで、認証局による信頼の仕組みとブラウザの検証手順を説明し、鍵マークにまつわる誤解を解きほぐします。守る範囲と守らない範囲を分けて理解すると、警告やドメイン名の見方も判断できるようになります。

HTTPSが守るのは通信の暗号化と接続先ドメインの確認#

HTTPSは、Webのやり取りに使うHTTPをTLSという仕組みで保護したものです。総務省の解説によれば、SSL/TLSはデータを暗号化して送受信し、あわせて電子証明書によって接続先がその証明書を持つ相手であることを確かめ、なりすましを防ぐ役割を持ちます。利用者の端末とWebサーバの間でやり取りされる入力内容や応答は暗号化されるうえ、途中で書き換えられれば検知できる仕組みになっているため、同じ通信経路にいる第三者が中身を読み取ったり改ざんしたりすることが難しくなります。

暗号化と改ざん検出に並ぶもう一つの柱が、接続先のドメインの確認です。ブラウザは接続したサーバから電子証明書を受け取り、その証明書に書かれているドメイン名が、利用者がアクセスしようとしているドメイン名と一致するかを検証します。これが合致すれば、「いま通信している相手は、少なくともこのドメイン名に対して正規に発行された証明書を持つサーバである」と確かめられます。逆に言えば、HTTPSが守るのは、通信の中身が暗号化され改ざんされないことと、接続先がその証明書どおりのドメインであることに限られます。

ここで守られない範囲を先に押さえておきます。HTTPSは、そのドメインの持ち主が善良であることや、表示される内容が真実であることまでは関知しません。暗号化された安全な経路を使って、偽の情報を届けることも技術的には可能です。守る対象は「通信」と「接続先ドメインの一致」であり、「サイトの中身や運営者の正当性」ではない点が、後で述べる誤解の出発点になります。

電子証明書と認証局による信頼の仕組み#

電子証明書がドメインの確認に使えるのは、証明書を第三者である認証局(CA)が発行し、その内容を保証しているからです。サーバの運営者は、自分が管理するドメインについて認証局に証明書の発行を申請します。認証局は申請者がそのドメインを実際に管理していることを確認したうえで証明書を発行します。CA/Browser Forumのベースライン要件は、認証局が公的に信頼される証明書を発行する際に満たすべき最低限の基準を定めており、ドメインの管理権の確認はその中核に位置づけられています。

ただし、認証局が確認する内容には水準の違いがあります。広く使われるドメイン認証(DV)型の証明書では、認証局はドメインの管理権だけを確認し、運営する組織の実在性までは確かめません。組織の実在性まで確認する証明書も存在しますが、いずれの場合も認証局が保証するのは「証明書に書かれた相手の身元(の確認できた範囲)」であって、その相手が利用者に対して誠実に振る舞うことではありません。DV型は申請の手間が小さく無償でも取得できるため、正規サイトだけでなく偽サイトでも利用されます。

認証局そのものを誰が信頼するのかという問題は、信頼の連鎖で解かれます。ブラウザやOSには、信頼の起点となるルート証明書があらかじめ組み込まれています。サーバが提示する証明書は、ルート証明書から中間証明書を経て発行されており、ブラウザはこの連鎖をたどって署名を順に検証します。連鎖の起点であるルートが信頼できる前提のもとで各段の署名が正しく確かめられれば、末端のサーバ証明書も信頼できると判断します。

SSL/TLSが暗号化と電子証明書による相手の確認を担う点は総務省の解説(総務省)を、認証局が満たす基準とドメイン管理権の確認はCA/Browser Forumのベースライン要件(CA/Browser Forum)を参照しました。

ブラウザが証明書を検証する手順#

ブラウザはサーバから証明書を受け取ると、いくつかの条件を順に確かめてから接続を成立させます。利用者が意識しなくても、接続のたびに自動で実行されます。確認する主な項目は次のとおりです。

失効の確認方法はブラウザによって異なります。CRL(失効リスト)やOCSPといった仕組みのほか、Chromeは緊急性の高い失効を独自のリスト(CRLSet)で扱い、接続のたびのオンライン失効確認は一般には行わないとしています。失効確認の扱いは一様ではないと理解しておくとよいでしょう。

これらの検証のいずれかが満たされないと、ブラウザは接続を中断して警告を出します。たとえば連鎖の起点が信頼されたルートに行き着かない証明書(自己署名の証明書など)では、発行元を信頼できないという警告が表示されます。ここで確認されているのは、あくまで証明書の正しさとドメインの一致であり、サイトの内容の良し悪しではありません。

鍵マークが示すものと示さないもの#

長らくブラウザは、検証に成功したHTTPS接続を鍵のアイコンで示してきました。この表示が、多くの利用者に「鍵マーク=安全なサイト」という受け取り方を生んだことが問題になりました。Googleは2023年5月のChromiumブログで、調査の対象者の89パーセントが鍵アイコンの意味を誤解していたと述べ、Chrome 117(2023年9月)から鍵アイコンを、設定を連想させる中立的な「チューン」アイコンへ置き換えました。鍵がサイトの信頼性を示すという思い込みを断ち、HTTPSが当たり前の状態であることを前提に表示を見直したものです。

鍵マークや中立的なアイコンが示すのは、これまで述べたとおり、通信が暗号化されていることと、接続先が証明書に書かれたドメインと一致することの二点に限られます。示さないのは、そのサイトの運営者が正規の事業者であることや、表示される内容が信用できることです。偽サイトであっても、自分が用意したドメインに対して証明書を取得すれば、鍵マークの出るHTTPS接続を成立させられます。

この誤解が危ういのは、フィッシングが実在する組織になりすまして認証情報を盗む手口だからです。フィッシング対策協議会は、フィッシングを実在する組織を装って利用者からパスワードやクレジットカード番号などを詐取する行為と説明しています。攻撃者は本物そっくりの見た目のサイトを、自分のドメインでHTTPS化して用意します。鍵マークを安全の証と捉えていると、暗号化されている事実を信頼の根拠と取り違え、見た目に引きずられて偽サイトに気づけなくなります。

あわせて読みたい

フィッシングの手口と対策の基本。個人と組織でできることを徹底解説

証明書の警告が出たときの意味#

証明書の警告は、検証の手順のどこかで条件が満たされなかったことを知らせる信号です。代表的な警告には次の意味があります。

• 有効期限が切れている：証明書の有効期間を過ぎている状態です。サイト側の更新漏れのこともあれば、端末の日時が大きくずれていて期間内と判定できない場合もあります。
• ドメインが一致しない：証明書に書かれたドメイン名が、接続しているドメイン名と合っていない状態です。設定の誤りのこともあれば、別のサイトの証明書が使われている場合もあります。
• 発行元を信頼できない：連鎖の起点が、ブラウザの信頼するルート証明書に行き着かない状態です。自己署名の証明書や、通信を途中で割り込んで観測しようとする機器が原因になることがあります。

これらの警告は、暗号化や接続先の確認という前提のどれかが崩れていることを意味します。原因が善意の設定ミスである場合もありますが、警告画面の見た目だけからは、攻撃による割り込みと区別できません。警告を安易に無視して先へ進むと、確認されないままの相手と通信したり、割り込んだ第三者へ情報を渡したりする危険があります。心当たりのないサイトで警告が出たときは、そのまま入力を続けずに接続を見送る判断が安全側に働きます。

利用者が確かめるべきはドメイン名#

鍵マークがサイトの正当性を保証しない以上、利用者が頼りにできるのは、接続先のドメイン名そのものです。証明書はドメインに対して発行されるため、アドレス欄に表示されているドメイン名が、本来アクセスしたい正規のドメインと一致しているかを確かめることが、偽サイトを見分ける手がかりになります。攻撃者は正規のドメインに似せた紛らわしい文字列を使うため、末尾の組織名にあたる部分まで含めて確認します。

HTTPSと電子証明書は、通信を暗号化し接続先のドメインを確かめるという土台を提供します。その土台の上で、表示されているドメイン名が正しいかを利用者自身が確かめることで、はじめて偽サイトを避ける助けになります。暗号化の有無を信頼の基準にするのではなく、誰と通信しているのかをドメイン名で見極める習慣が、フィッシングへの実際的な防御につながります。

通信を保護するTLSや暗号化の仕組みをより詳しく知りたい場合は、暗号化の基礎をまとめた記事もあわせて参照してください。

あわせて読みたい

暗号化の基礎。共通鍵・公開鍵・ハッシュ・TLSはどう情報を守るのか

ドメイン名がIPアドレスに変換される名前解決の安全性については、別の記事で扱っています。

あわせて読みたい

DNSの名前解決とその安全性を支える技術