JPRS トピックス & コラム https://△△△.jp No.023 今改めて知っておきたい、サーバー証明書の基礎知識 ∼サーバー証明書の役割とその種類∼ インターネットにおいて安全で機密性の高い通信を実現するために Web サーバーに設定される 「サーバー証明書」の概要について解説します。 ■ サーバー証明書が求められる背景 受け取ったデータの内容が欠落しておらず、 かつ第三者による改 ざんが行われていないことを確認する「完全性の確保」 です。 電子商取引（EC） やネットバンキングなど、 インターネットは PKIにおける認証局は階層構造となっており、 信頼の起点（ト さまざまな経済活動に利用されるようになりました。 現在では税 ラストアンカー） となる「ルート認証局」 と、 ルート認証局の「子」 金の電子申告や国勢調査の回答など、 国や政府の重要な手続きに としてつながり、 サーバー証明書を発行する「下位認証局（中間 もインターネットが利用されるようになっています。 認証局） 」 が存在します（図1） 。 その一方、 本物のWebサイトに似せた偽サイトに利用者を誘 導し、 利用者が誤って入力した情報の盗み取りを試みる「フィッ シング」 の事例が多数報告されています。 最近のフィッシングで は銀行の口座情報やクレジットカード情報など、 経済的価値の高 い情報が狙われており、 差出人のメールアドレスの詐称や本物の メールとほぼ同じ内容の偽メールを送りつけるなど、 偽サイトへ の誘導の手口も巧妙化しています。 フィッシングによる被害を防止し、 安全で機密性の高い通信を 行うためには「通信相手のサイトは意図した通りの、 正当な相手 が運営しているものであると利用者自身が確認できる」 「通信相 手以外の第三者は通信内容を知ることができない」 「通信相手か 図 1 PKI における認証の仕組み ら受け取ったデータは相手が送信した通りのもので、 途中で失わ Webをはじめ、 インターネット上の暗号通信のプロトコルと れたり改ざんされたりしていない」 の三つを実現するための仕組 し て 広 く 使 わ れ て い る の が「SSL（Secure Sockets Layer） みが必要になります。 TLSの通信では、 「公 /TLS（Transport Layer Security） 」 です（*1）。 Webブラウザーのアドレスバーの鍵（南京錠） マークをクリッ 開鍵暗号」 と「共通鍵暗号」 という二つの暗号方式が組み合わせ クすると示される「サーバー証明書」 は、 これら三つの項目の解 て使われます（図2） 。 決に使われます。 サーバー証明書では通信の当事者ではない第三 者が「お墨付き」 を与える形で、 通信相手の身元を確認します。 サーバー証明書をはじめとする電子証明書（より正確には公開 鍵 証 明 書） は、 「Public Key Infrastructure（PKI：公 開 鍵 基 盤） 」 と呼ばれる仕組みにより運用されています。 PKIでは、 サーバー証明書は「認証局」 と呼ばれる第三者機関に より発行されます。 認証局は現実世界における役所のように組織 や個人の実在性を確認し、 確認した相手に証明書を発行します。 ■ サ ー バ ー 証 明 書 が 果 た す 三 つ の 役 割 と SSL/TLS の仕組み サーバー証明書には、 大きく三つの役割があります。 一つ目は、 通信相手の身元を証明し、 なりすましを防止する「認証」 、 二つ目 は、 通信を第三者による盗聴から保護する「暗号化」 、 三つ目は、 掲載内容は2016年7月現在のものです。 図２ TLS を用いた暗号通信の流れ （*1）SSLの最初の仕様は1995年に開発され、インターネットの普及と共に広く使われるように なりました。その後、SSLの後継プロトコルとしてTLSが標準化されましたが、SSLという 名称は現在も広く使われています。なお、SSLの仕様には致命的な脆弱性が発見されており、 TLSへの移行が強く推奨されています。本コラムでは以降「TLS」を使用します。 Copyright © 2016 株式会社日本レジストリサービス JAPAN REGISTRY SERVICES 今改めて知っておきたい、サーバー証明書の基礎知識 多くのサーバー証明書は下位認証局が発行します。一方、PC を、電話調査や登記簿確認など何らかの手段で確認した上で発 やスマートフォンにインストールされているWebブラウザーに 行されます。その点でDV証明書よりも一段上の信頼性が確保さ は、一定の基準を満たした認証局のルート証明書があらかじめ れていると言えます。 インストールされています。TLS通信を行う際には、インストー そして、金融機関など、より高い信頼性が求められる組織では、 ルされているルート証明書と受け取ったサーバー証明書との間 業界の統一基準に基づく厳密な認証を経て発行されるEV証明書 に構築された信頼の連鎖を、Webブラウザー側で検証する仕組 が用いられるケースが増えています。EV証明書が導入された みになっています。 Webサイトにアクセスすると、Webブラウザーのアドレスバー もし、攻撃者が偽のサーバー証明書を使ってWebサーバーの が緑色になり、組織名がその横に表示されます。 偽装を試みた場合、 真正性の認証ができないためWebブラウザー この辺りの状況は、ドメイン名と同様であると言えるでしょ にエラーメッセージが表示され、ユーザーにその旨の注意を促 う。メールアドレスを入力するだけで登録可能なドメイン名も します。こうしたメッセージは、サーバー証明書の有効期間の満 あれば、厳密な登録要件が定められていたり、組織の住所などの 了、信頼の連鎖から外れた認証局で発行されたサーバー証明書 確認を経た上で発行されるドメイン名もあります。 （例えば、Webサーバーの管理者自身が発行した自己署名証明書） 一方、認証局の運用の不備によりセキュリティ上の問題が引 を用いた場合などにも表示されます。 き起こされたケースも、これまでにいくつか報告されています。 Webサーバーの管理者はこうしたエラーが発生することのな 2011年にはオランダの認証局であったDigiNotarが外部から いよう、注意深くサーバー証明書の設定や更新を行うことが求 攻撃を受け、偽のサーバー証明書が発行される事件が発生し められます。インターネット上でしばしば「エラーや警告のメッ ました。 セージが出ても問題はありませんので無視して次に進んでくだ こうした事柄を踏まえ、サーバー証明書の発行を受ける際に さい」といった操作を案内するサポート情報を見かけることが は料金だけでなく、各認証局の管理体制や運用状況なども事前 ありますが、こうした案内は攻撃者が用意した悪意を持つWeb に確認しておくとよいでしょう。 サーバーを見抜くヒントを無視してしまう癖をつけてしまうこ ■ 今後の展望 とになり、望ましくありません。 ■ 3種類のサーバー証明書 パフォーマンスの向上やデータ転送量の効率化などを狙って 現実世界の身分証明書には、社員証や学生証のように民間組 TLSは重要な役割を果たしています（*2）。仕様上は必須ではあり 織が発行するものから、住民票や免許証、パスポートのように公 ま せ ん が、Google ChromeやMozilla Firefoxな ど い く つ か の 的機関が発行するもの、それも比較的手軽に発行できるものか Webブラウザーでは、暗号化された通信路上、つまりTLS上での ら、厳密な本人確認手続きが求められるものまでさまざまな種類 みHTTP/2をサポートすると表明しており、事実上、TLSが必須 があります。どのように実在性の認証を行っているか、その厳密 になると考えられています。 さに応じて、証明書自体の信頼度も変わってくることになります。 また、米Googleでは検索エンジンの順位決定の要素の一つと サーバー証明書にもそれと同様に、いくつかの種類がありま して、Webコンテンツすべての通信をTLSによる暗号通信で行 す。 具 体 的 に はDomain Validation（DV） 、Organization う「常時SSL（*3）」の有無を加味すると表明しています。技術面で Validation（OV） 、Extended Validation（EV）の三つです。 の理由に加え、いわゆるSEO対策という観点からも、今後常時 DV証明書は名前の通り、当該ドメイン名の登録者であること SSL化が進んでいくと考えられます。 のみを確認します。DV証明書は比較的手軽に発行できますが、 こうした動きからもTLSによる通信、そしてその実現に不可 証明書をインストールしたWebページを表示する際に組織名が 欠なサーバー証明書がインターネットにおいて果たす役割は、 表示されません。また、そのドメイン名の登録者であることを確 今後ますます重要になっていくでしょう。 標準化されたHTTPの新バージョンであるHTTP/2においても、 認するだけですので、正規の組織に類似したドメイン名を用い た（フィッシングに悪用される恐れのある）Webサイトに対して も、発行は可能ということになります。 （*2）前述した通りSSLには致命的な脆弱性が発見されており、HTTP/2ではTLSのみが使わ 一方、OV証明書は、その組織が確かに存在すること（実在性） （*3）正しくは「常時TLS」 。 「JPRS トピックス＆コラム」バックナンバー https//jprs.jp/related-info/guide/ れます。 Copyright © 2016 株式会社日本レジストリサービス
© Copyright 2024 ExpyDoc
