【原因/対策】SSLエラー/セキュリティ証明書エラー警告が表示される理由と対処

セキュリティ証明書(デジタル証明書やSSL証明書、サーバ証明書などとも呼ばれます)でエラー警告がされた場合の対処法です。

症状

IEやEdgeの場合、「このWebサイトのセキュリティ証明書には問題があります」や「このサイトは安全ではありません」と表示される。(下記はIE11のケース)

Chromeの場合、「この接続ではプライバシーが保護されません」と表示される。

Firefoxの場合、「安全な接続ではありません」と表示される。

原因

以下5つが考えられます。

  1. Webサーバ側にインストールされている「SSL証明書」に記載されているCommonName(コモンネーム)属性値が、ブラウザのURLと異なっている
  2. Webサーバ側にインストールされている「SSL証明書」のルート証明書がクライアント側でインストールされておらず、信頼できる状態ではない
  3. Webサーバから中間証明書が提示されず、ルート証明書が分からず、信頼できる状態ではない
  4. Webサーバ側にインストールされている「SSL証明書」の有効期限が過ぎている
  5. Webサーバ側にインストールされている「SSL証明書」の有効期限は過ぎていないが、(秘密鍵の流出の可能性などの理由で)発行者の手によって失効されている

1. Common NameとURLの相違

証明書の『コモンネーム』もしくは『サブジェクト代替名』というパラメータに記載の FQDN (example.com 等のドットで区切られたホスト名) が、ブラウザに入力した URL と異なる場合にエラーとなります。

例えば先程の画面キャプチャでの例では、証明書エラーはいずれも、コモンネームが google.co.jp であるのに対し、ブラウザに入力したのが「https://172.217.24.131」であるためです。

これに関してはわざわざnslookupでIPアドレスを調べ、「https://172.217.24.131」と打ったためこのようになっています。(そういう意味ではこれは『クライアント側がgoogleの意図していないアクセス方法でアクセスしている』のが問題なのですが。)

ですが例えば DNSキャッシュポイズニング等の攻撃により、偽サイトへ誘導されるようなケースでは、https://rakuten.co.jp という URL を打ったのに、違う IP アドレスの偽サイトに行ってしまった場合であっても、偽サイト制作者は「rakuten.co.jp」というコモンネームの証明書は公的機関からは発行されない (審査で落とされる) ので、ほぼ間違いなくエラーが出ます。

VeriSign 等の証明書を発行する機関は発行する前に、申請者が rakuten.co.jp のドメインを保有していることを色々な手段で確認します。

つまり、エラーが出ている、ということは、そのサーバが偽サイトの可能性があることを示しています

Edgeの場合、DLG_FLAGS_SEC_CERT_CN_INVALID というエラーコードが表示されたらこれが該当しますし、Chrome の場合は NET::ERR_CERT_COMMON_NAME_INVALID というエラーコードが該当します。

対処策概要

一番簡単なのは、サイトの管理者に問い合わせをして下さい。

それが難しければ、証明書の『コモンネーム』や『サブジェクト代替名』を確認し、URLをそれに変えてアクセスして見て下さい。

また、ホテル等の無線ではまずWeb画面で認証や同意をさせるために「httpリダイレクト」を使ってその画面に飛ばす構成を取ることが多いです。このとき、ブラウザの起動時ページがhttpsで始まるサイトになっている場合、httpリダイレクトによりこのエラーが表示されます。

このようなケースでは、どのサイトでもよいので、httpで始まるサイトへアクセスしてみて下さい。その際、認証画面や同意を取る画面が出てくるようであれば、認証・同意などを行った後であれば、その後はこの警告画面は出てこないはずです。

対処策詳細

Googleのサイトの証明書は以下のようになっております。「詳細」タブの「サブジェクト」の項目をクリックすると、下に「CN=*.google.com」と出ています。これがコモンネーム(CommonName)の項目です。*は任意の文字列(ワイルドカード)です。

さらに「サブジェクト代替名」を見ると、DNS Name としてたくさん URL が並んでいますが、これらも CommonName と同等と解釈されるため、これのいづれかに合致すればエラーは表示されません。

2. クライアント側でルート証明書がインストールされていない

証明書は階層構造になっており、そのトップにはルート証明機関 (ルート CA) が発行しているルート証明書があります。

サーバ証明書は中間証明機関 (中間 CA) がそれを保証し、その中間証明機関はルート証明機関が保証しますが、ルート証明機関は保証する人がいませんので、自分で自分を保証します、という自己署名証明書である「ルート証明書」を発行します。

一方クライアントは、OS やブラウザなどにあらかじめインストールされている「ルート証明書」を頼りに、そのルート証明機関を信用するか否かを決めます。(後から個別にルート証明書をインストールすることもできます)

上図 Google の例では、ルート証明書は「証明のパス」にある「GeoTrust Global CA」になります。これが OS に最初からインストールされているはずです。確認は IE のインターネットオプションの「コンテンツ」の「証明書」をクリックし、「信頼されたルート証明機関」のリストで行えます。

なので、その SSL 証明書のトップにあるルート証明書が、クライアントにインストールされていない場合は、その SSL 証明書自体も信用できないものと解釈し、冒頭のエラーを表示させます。

このエラーは、本来は信用すべきルート証明書が入っていない場合にも該当します。例えば、会社独自の証明機関 (CA) を立てて、その社内の web サーバに SSL 証明書を発行、インストールし、ActiveDirectory の機能等でクライアントにルート証明書をインストールしている場合、ドメイン内のクライアントは問題ありませんが、ドメインに入っていないクライアントがアクセスした場合は、ルート証明書がインストールされていないので冒頭のエラーが表示されます

Edge の場合、DLG_FLAGS_INVALID_CA というエラーコードが表示されたらこれが該当しています。

対処策概要

Web サーバ管理者が分かるのであれば、Web サーバ管理者に確認した上で、ルート証明書をクライアントにインストールします。

Web サーバ管理者が不明なのであればアクセスしないのが無難ですが、どうしても見たい場合は自己責任で『続行する』ボタンを押します。

対処策詳細

ルート証明書をインストールするには、まずルート証明書をファイル化します。

先程の『証明のパス』の最上位にあるルート証明書をダブルクリックし、ルート証明書を表示します。

次に、『詳細』タブにある『ファイルにコピー』をクリックし、名前をつけて保存します。これがルート証明書のファイルです。

次に、先程の証明書の確認手順と同様、IEのインターネットオプションの「コンテンツ」の「証明書」をクリックし、「信頼されたルート証明機関」のところでインポートをクリックし、先程のルート証明書のファイルを選択し、案内に従ってインポートします。

3. 中間証明書が無いため、ルート証明書が不明

通常、Web サーバは、SSL 証明書と一緒に中間証明書もクライアントに提示するのですが、あまりスキルの無い人が立てた Web サーバでは、中間証明書のインストールが抜けていたり等で、https アクセス時に中間証明書が提示されない場合があります。

その場合クライアントは、その SSL 証明書がどのルート証明書に属するものかが分からないためエラーになります。

対処策概要

Web サーバ管理者に連絡し、Web サーバに中間証明書をインストールしてもらうようお願いしましょう。

もしくは、ルート証明書のインストールと似た手順で、中間証明書をクライアントにインストールすることでも対処できます。

対処策詳細

中間証明書をファイル化し、IEのインターネットオプションの「コンテンツ」の「証明書」をクリックし、「中間証明機関」のところでインポートをクリックし、先程の中間証明書のファイルを選択し、案内に従ってインポートします。

4. 有効期間が切れている

証明書には有効期間が存在します。単純にその期間が切れている場合もこのエラーが表示されます。証明書の「全般」タブに有効期間が記載されています。

対処策

Web サーバ管理者に連絡し、証明書を更新してもらいましょう。

5. 発行者の手によって失効されている

ERROR_INTERNET_SEC_CERT_REVOKED といった表記がある場合はこれが該当していると思われます。

デジタル証明書においては秘密鍵が流出した場合はそのセキュリティ効果が無意味になります。そのため、そのような場合、管理者はそのデジタル証明書を CRL というリストに載せ、『その証明書はセキュリティ上問題になりそうだから失効したよ』ということを知らせます。

証明書には CRL の URL (http://〜等) が記載されており、証明書の検証時にはこの CRL をダウンロードして失効の是非を確認します。これは、その証明書だけでなく中間証明書やルート証明書にも同様に失効の確認が行われます。

もしこの類のエラーが出た場合は、(秘密鍵の漏れた証明書を悪用されているケースも考えられますが、それよりも) Web サーバの管理者が知らないところでその証明書を発行した中間 CA なりルート CA が中間証明書やルート証明書を失効した可能性があります。

対処策

サーバの管理者に状況を伝え、確認しましょう。

補足

  • 『このセキュリティ証明は信頼された証明機関から発行されていません』という表示がある場合は、原因 2 or 3 のケースのどちらかになります。
  • どんな原因にせよ、この警告を無視して続行したとしても、通信の暗号化は実行されますので、通信相手以外は盗聴は不可です。問題なのは、通信相手が正しいかどうか、ということです。

IT/インフラエンジニアの地位とスキル向上のために

関連記事

IT 技術の進化はとどまることを知りません。矢継ぎ早に新たな技術が出てきたり、数年前の技術が時代遅れになったりと、IT エンジニアは勉強し続ける運命のようです。 それをどう思うかはあなた次第。 ビジネスの基本は『付加価値を与える[…]

IMG
関連記事

nesuke の考える NW エンジニアの2つの道 ネットワークエンジニアには 2 つの道があります。 1 つはネットワーク構築一筋で、L4 までをひたすらきっちりと構築していく道。 もう 1 つはネットワークを軸として深堀し[…]

IMG