セキュリティ証明書のエラー警告が表示される

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

スポンサーリンク
スポンサーリンク

症状

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

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

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

スポンサーリンク

原因

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

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

1. Common NameとURLの相違

例えば先程の画面キャプチャでの例では、証明書エラーはいづれも、「https://google.co.jp/」とアクセスすべきサイトを、わざわざnslookupでIPアドレスを調べ、「https://172.217.24.131」と打ったために出ています。

そういう意味ではこれは『クライアント側がgoogleの意図していないアクセス方法でアクセスしている』のが問題なのですが、例えばDNSキャッシュポイズニング等の攻撃により、偽サイトへ誘導されるようなケースでは、https://rakuten.co.jpというURLを打ったのに、違うIPアドレスの偽サイトに行ってしまった場合であっても、偽サイト制作者は「rakuten.co.jp」というコモンネームの証明書は公的機関からは発行されない(審査で落とされる)ので、ほぼ間違いなくエラーが出ます。つまり、エラーが出ている、ということは、そのサーバが偽サイトの可能性があることを示しています。Edgeの場合、DLG_FLAGS_SEC_CERT_CN_INVALID というエラーコードが表示されたらこれが該当しています。

対処策概要

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

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

対処策詳細

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サーバ管理者に連絡し、証明書を更新してもらいましょう。

補足

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

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク
スポンサーリンク