狠狠撸

狠狠撸Share a Scribd company logo

Wp sslandroot certificate

?
?
Yoshida Yuri
Yoshida Yuri
Convert to study guideBETA

Transform any presentation into a summarized study guide, highlighting the most important points and key insights.

1 of 17
Download to read offline
WHITE PAPER いまさら聞けない、 SSL サーバ証明書と ルート証明書の関係 暗号アルゴリズム 2010 年問題対応される サイト運営者　必見！
WHITE PAPER Copyright ?2010 VeriSign Japan K.K. All rights reserved. シマンテック（Symantec） ノートン 、 （Norton）およびチェックマークロゴ 、 （the Checkmark Logo）は米国シマンテック コーポレーション ? （Symantec Corporation）またはその関連会社の米国またはその他の国における登録商標、または、商標です。 ベリサイン（VeriSign）、ベリサイン?トラスト（VeriSign Trust）、およびその他の関連するマークは米国 VeriSign, Inc. またはその関連会社の米国ま たはその他の国における登録商標、または、商標です。 その他の名称もそれぞれの所有者による商標である可能性があります。 日本ベリサイン株式会社は、本書の情報の正確さと完全性を保つべく努力を行っています。ただし、日本ベリサイン株式会社は本書に含まれる情報に関して、 （明示、黙示、または法律によるものを問わず）いかなる種類の保証も行いません。日本ベリサイン株式会社は、本書に含まれる誤り、省略、または記述によっ て引き起こされたいかなる（直接または間接の）損失または損害についても責任を負わないものとします。さらに、日本ベリサイン株式会社は、本書に記 述されている製品またはサービスの適用または使用から生じたいかなる責任も負わず、特に本書に記述されている製品またはサービスが既存または将来の 知的所有権を侵害しないという保証を否認します。本書は、本書の読者に対し、本書の内容に従って作成された機器または製品の作成、使用、または販売 を行うライセンスを与えるものではありません。最後に、本書に記述されているすべての知的所有権に関連するすべての権利と特権は、特許、商標、また はサービス ? マークの所有者に属するものであり、それ以外の者は、特許、商標、またはサービス ? マークの所有者による明示的な許可、承認、またはラ イセンスなしにはそのような権利を行使することができません。 日本ベリサイン株式会社は、本書に含まれるすべての情報を事前の通知なく変更する権利を持ちます。 2
WHITE PAPER Contents 概要 4 第 1 章　暗号化通信で必須となる、 SSL サーバ証明書とルート証明書 5 HTTPS 通信の開始方法 5 SSL サーバ証明書とルート証明書の関係 5 第 2 章　暗号化通信における信頼の要、ルート証明書 6 クライアントに登録されるルート証明書 6 認証局（ルート証明書）を登録する基準 7 第 3 章　登録された認証局（ルート証明書）のメンテナンス 8 PC ブラウザにおける認証局（ルート証明書）のメンテナンス 8 携帯電話や家電?組み込み機器における認証局（ルート証明書）の メンテナンス 8 携帯電話（NTT docomo）を例に見る登録された 認証局（ルート証明書） 8 第 4 章　最後に 10 付録　ベリサインが提供する SSL サーバ証明書 11 ベリサイン グローバル?サーバ ID EV（サーバタイプ：共通） 12 ベリサイン セキュア?サーバ ID EV（サーバタイプ：共通） 13 ベリサイン グローバル?サーバ ID（サーバタイプ：新仕様 ※1） 14 ベリサイン グローバル?サーバ ID（サーバタイプ：旧来仕様 ※2） 15 ベリサイン セキュア?サーバ ID（サーバタイプ：新仕様 ※3） 16 ベリサイン セキュア?サーバ ID（プラットフォーム：旧来仕様 ※4） 17
WHITE PAPER 概要 不景気を反映した消費スタイルの価格?ポイントサービス志向な どにより、今までホームセンターで買っていたような日用品まで E コマースで購入されるようになってきました。とくに、昨今では、 携帯電話やスマートフォンなどのモバイル EC 市場が全体を牽引 する形となり、景気の低迷にもかかわらず消費者向け E コマース 市場が依然として急成長しています。 この市場の成長スピードと連動してウェブサイト構築に求められる のが、開発スピードです。最近のウェブサイトの開発期間は 2ヶ月、 3 ヶ月という短いサイクルが求められ、一つのトラブルがスケジュー ル全体の致命的な遅延に繋がりかねません。また、そうした短期 間で開発されたシステムに対しては、十分なテスト時間が設けら れず、いざサイトをオープンしたとたんに、トラブルが発生するの です。 「ウェブサイトに接続しようとすると、セキュリティの警告がでるの はなぜ？」 「新しい携帯電話からは通信できるけど、古い携帯電話だと接続 できないはなぜ？」 最近のウェブサイトは、外部システムとの連携が前提で構築され、 こうした複雑化したシステムで発生するトラブルの原因は、ネット ワークからアプリケーション、システム連携など様々な要因が考え られます。ウェブサイト構築にとって一つでもその要因を排除する ことが理想です。このホワイトペーパでは、前述のようなトラブル が発生する原因について、SSL（Secure Sockets Layer）暗号 化通信の技術的な仕組みを通して解説していきます。この仕組み を理解することによって、トラブル発生時に何が原因であるのか、 より具体的にイメージしながら対応することができ、また、事前に 問題回避するこ もできるよ と うになるでしょう。 4
WHITE PAPER 第 1 章　暗号化通信で必須となる、 SSL サーバ証明書とルート証明書 https://www.～ HTTPS 通信の開始方法 クライアントのブラウザ ウェブサーバ HTTPS 通信を開始する際に、クライアント（ウェブブラウザや携 帯電話など）とウェブサーバ間では、どのような処理が行われて ①暗号化仕様交渉 いるのでしょうか？ ベリサインの ルート 確認 SSLサーバ 証明書 OK! ②SSLサーバ証明書送付 証明書 クライアントとウェブサーバの間では、下記の手順①～④および 図 1 のようなやり取りが行われます。 共通鍵 共通鍵 ③共通鍵生成 40bit～256bit 40bit～256bit ① クライ トがセキュアなウェブサイ アン ト（https:// ～）へアクセ スし、SSL 暗号化通信で接続を要求します。このときクライア ④暗号化データ通信開始 ントは、自身が使用可能な暗号化の仕様（暗号方式、鍵長、 圧縮方式）をウェブサーバへ伝えます。ウェブサーバは、クラ イアントから提示された暗号化使用から実際に利用するものを 選択して、クライ トへ通知します。 アン 図 1.　SSL 暗号化通信開始時のウェブサーバとクライアントのやり取りのイメージ ② ウェブサーバは、自分の身分を証明する SSL サーバ証明書を HTTPS 通信が開始される短い時間の中で、ルート証明書は、ウェ クライアントへ送ります。クライアントは SSL サーバ証明書を ブサーバから送られてく SSL サーバ証明書の信頼性を判断す る 受け取り、クライ トに「信頼される認証局」と アン してあらかじ る重要な役割を果たしていることがわかるでしょう。 め登録されている認証局（CA）の証明書（これをルート証明 書と呼ぶ）を用いて SSL サーバ証明書の署名検証を行います。 またクライアントは、SSL サーバ証明書からウェブサーバの公 開鍵を取得します。 SSL サーバ証明書とルート証明書の関係 SSL サーバ証明書は、ウェブサイトを運営している団体のいわゆる ③ 正しくルート証明書へのチェーンを辿って署名検証が完了す 「電子的な身分証明書」です。これを確認することで、認証済 ると、クライアントはウェブサーバの公開鍵を用いてプリマスタ みの安全なサイトなのか、それとも身元の確認が取れない危険な シークレット（共通鍵を生成する基となる乱数データ）を暗号 サイトなのかを見極めることができます。 化し、ウェブサーバへ送付します。ウェブサーバは自分の秘 密鍵を用いて、プリマスタシークレットを復号します。 SSL サーバ証明書は、ベリサインのような「認証局事業者」に申 請し、その事業者が設定する認証を受けて発行してもらう必要が ④ ③で共有されたプリマスタシークレットを基にクライアントと あります。SSL サーバ証明書には、 サーバの運営者である組織名、 ウェブサーバで同じ共通鍵を生成および共有し、以降のセッ 証明書を発行した認証局の名前、ウェブサーバの公開鍵や証明 ションではこの共通鍵を用いて暗号化?復号して通信を行い 書の有効期間が明記されており、さらに認証局事業者の署名が ます。 付いています。 認証局事業者の署名とは、SSL サーバ証明書のハッシュ値を認 証局の秘密鍵で暗号化したデータです。クライ トは、 サー アン SSL バ証明書を受け取ると、クライアントに登録されている認証局の 証明書（ルート証明書）を用いて、この認証局の署名を復号し ます。復号したデータが、SSL サーバ証明書のハッシュ値と一致 すれば、第三者によって改ざんされたものでない、正しく認証局 事業者が発行した SSL サーバ証明書であることが確認できます。 5
WHITE PAPER 第 2 章　暗号化通信における信頼の要、 Sub ルート証明書 jec CN t =w O= ww .exa OU Exa mp le J mp le.c om クライアントに登録されるルート証明書 =M apa クライアントに登録されているルート証明書のリストは、PC の Issu ark nK etin .K. er gD epa 利用者（運営者）情報 CN rtm O= = Ve riSig n In ent 場 合は簡 単に確 認することができます。Microsoft Internet Ver tern 有効 期限 iSig n atio nal Serv Explorer の場合、メニューの「ツール」から、「インターネット er C オプション（O）、 」「コンテンツ」「証明書」「信頼されたルー 、 、 201 A- 0/3 Clas /1 - s3 201 2/3 /1 発行者（認証局）情報 ト証明書機関」を辿ることで、登録された認証局（ルート証明書） の一覧を確認することができます。 利用者 公開鍵 認証局署名 図 2.　SSL サーバ証明書の概略 このようにウェブサーバから送られてく SSL サーバ証明書が、 る 信頼できる証明書かを署名検証するキーポイ ト ン となるのがクライ アントに登録されている認証局の証明書（ルート証明書）である ことがわかるでしょう。 認証局の証明書（ルート証明書）が存在しないと、ウェブサーバ から送られてく SSL サーバ証明書の認証局の署名が検証でき る ずに、下記のようなエラーが発生します。 ウェブサイトに接続しよ とする う と、セキュリティの警告がでる 新しい携帯電話からは通信できるけど、古い携帯電話だと接続で きない 次の章では、クライ トに登録されているルート証明書に関する アン 概説と、上記エラーの原因であるクライアントがルート証明書を 登録する基準について解説します。 図 3.　Internet Explorer に登録されたルート証明書の確認方法 ルート証明書は、自分自身で電子署名をした電子証明書を発行し ているという特徴があります。図 3. の例で言うと、発行先と発行 者が同じであることで確認することができます。ブラウザベンダー や携帯電話の提供者であるキャリア、家電?組み込み機器メーカ などが、このようなルート証明書を組込むにあたっては、独自に 厳密な審査を行っています。このプロセスに合格して初めて「信 頼できるルート認証局」として登録されるというルールが採用され 6
WHITE PAPER ているので、私たちはこれを用いた SSL 通信を「信頼」できると ここで紹介されている監査基準の一つであるWebTrustについて、 言えます。 もう少し詳しく解説します。米国公認会計士協会（AICPA）及 びカナダ勅許会計士協会（CICA）が定めた、オンラインにおけ 次節では、ブラウザベンダーなどが実施する厳密な審査とは、ど る電子商取引を対象とした保証サービスを WebTrust のサービス のような基準に基づくものなのかについて、マイクロソフトが公開 として定義されています。その中でも、認証局の信頼性を保証す している内容を例に説明します。 るサービス して WebTrust for CA という と ものがあり、認証局が その原則と規準に準拠しているかどうかを監査法人が検証し、準 認証局（ルート証明書）を登録する基準 拠が確認された認証局に対して検証報告書が発行します。また、 ベリサインのような認証局は、業務を適切に行うために、CP ブラウザベンダーやキャリア、家電?組み込み機器メーカなどは、 （Certificate Policy：証明書ポリシー）と CPS（Certification このような監査結果を確認することによって、各認証局を「信頼 Practice Statement：認証局運用規程）を作成し、この文書に できるルート認証局」として登録しています。 従って業務を遂行しています。CP/CPS は、認証サービスにおけ 次の章では、クライ トに組み込まれたルート証明書が、どのよ アン る認証局の義務と責任、運用方法、電子証明書の適用範囲など うな形でメンテナンスされるのか、そしてメンテナンスができない を電子証明書の利用者や検証者へ告知することで認証局の社会 場合には、 どのような状況がもたらされるのかについて解説します。 的信頼性を向上させると共に、係争発生時の責任の明確化する ための重要な文書です。一般的に、このような文章は公開されて いますが、実際に認証局が業務を適切に行っているか、また発 行される電子証明書を信頼してよいかを、電子証明書の利用者 を含む外部の利害関係者が判断することはできません。そこで登 場するのが「監査」というキーワードです。 外部の利害関係者が、認証局や発行された電子証明書を信頼で きるかどうかを判断するうえで、認証局の業務に精通し、認証局 から独立した第三者による監査が行われているかどうかが、ブラ ウザベンダーなどが「信頼できるルート認証局」として登録する 重要な基準となっています。たとえば、マイクロソフトでは、登録 基準として、どのような監査を満たす必要があるかをウェブで公開 しています。 マイクロソフ ルート証明書プログラム ト http://technet.microsoft.com/ja-jp/library/cc751157.aspx 一般要件（抜粋） CA は監査を完了し、監査結果をマイクロソフトに 12 か月ごとに提 出する必要があります。監査は、 拡張キー使用法 (EKU) の割り当てで、 マイクロソフトにより有効とされる PKI 階層を対象とする必要があり ます。マイクロソフトが有効にするすべての証明書の使用は定期的に 監査される必要があります。監査レポートは監査の対象となっている 特定の種類の証明書を発行するサブ CA を含むすべての範囲の PKI 階 層を文書化する必要があります。適格な監査には次が含まれます。 ? CA 監査者（監査機関）について認可されている WebTrust により 完了された WebTrust for Certificate Authorities v1.0 またはそ れ以降（英語情報） 。 ? ETSI TS 101 456 v1.2.1 またはそれ以降（英語情報） ? ETSI TS 102 042 v1.1.1 またはそれ以降（英語情報） 、または ? CA 監査者（監査機関）について認可されている WebTrust か、 CA と同じ管轄の査定人についての法律やポリシーにより運営さ れている監査機関のいずれかにより完了された ISO 21188:2006 （英語情報） “Public key infrastructure for financial services - Practices and policy framework”。 ※ CA： Certificate Authority　認証局 7
WHITE PAPER 第 3 章　登録された認証局（ルート証明書） 携帯電話（NTT docomo）を例に見る のメンテナンス 登録された認証局（ルート証明書） 携帯電話において、どのようなルート証明書がリストに登録され クライ トの出荷時に組み込まれた認証局（ルート証明書）は、 アン ているかは、携帯電話の提供者である各キャリアのホームページ 定期的にメンテナンス（更新）をする必要があります。その理由 で公開されています。 としては、新しい暗号アルゴリズムを採用したルート証明書の追 加や、危殆化した暗号アルゴリズムを使用しているルート証明書 （参考）各キャリアの SSL/TLS 通信に関する携帯電話仕様に の削除を行う とを目的と こ してメンテナンスが実行されます。 ついて （1）NTT docomo PC ブラウザにおける認証局（ルート証明書）の http://www.nttdocomo.co.jp/service/imode/make/ メンテナンス content/ssl/spec/index.html#taiou PC ブラウザなどでは出荷時に組み込まれた認証局（ルート証明 書）に対して、定期的にオンラインでメンテナンス（更新）が実 （2）au by KDDI 行することができます。 http://www.au.kddi.com/ezfactory/tec/spec/ssl.html （参考）代表的なブラウザベンダーのルート証明書の更新方法 （3）SoftBank Mobile （1）マイクロソフ ルート証明書の更新プログラムが提供されて ト http://creation.mb.softbank.jp/web/web_ssl.html います。 （2）Mozilla Firefox ブラウザのバージョンアップにより自動的に ルート証明書が更新されます。 NTT docomo で公開されている各携帯端末に登録されている ルート証明書の一覧から抜粋した内容を表 2 に示します。これを 見ると分かるように、発売時期などによって登録されているルート 証明書の種類や登録数が異なっていることが確認できます。 携帯電話や家電?組み込み機器における認証局 （ルート証明書）のメンテナンス PC に比べて、携帯電話や家電?組み込み機器には、場合によっ ては、以下のような制限があるので、SSL サーバ証明書の選択 には注意が必要です。 （1）ルート証明書のオンラインアップデート機能が提供されてい ない （2）デバイスのメモリー容量の関係で限られたルート証明書のみ しか登録できない （3）最新の暗号アルゴリズムは取り扱えない つまり出荷時に組み込まれた認証局（ルート証明書）のみが、信 「 頼できるルート認証局」として登録され、SSL 暗号化通信を実現 することができます。 以下では、 NTT docomoが公開しているルー ト証明書の一覧を例にして、SSL サーバ証明書の選択の注意点 を詳細に解説します。 8
WHITE PAPER 表 2．各携帯端末（抜粋）に登録されているルート証明書の一覧 機種名 発売日 登録されているルート証明書 L-04B 2010 年 6 月 25 日 VeriSign クラス 3 Primary CA ルート証明書 VeriSign クラス 3 Primary CA ルート証明書 G2 L-03B 2010 年 3 月 12 日 Equifax Secure Certificate Authority Equifax Secure eBusiness CA-1 GeoTrust Global CA GTE CyberTrust Global Root L-02B 2009 年 12 月 18 日 Baltimore CyberTrust Root GlobalSign Root CA GlobalSign Root CA-R2 Valicert Class 3 Policy Validation Authority VeriSign クラス 3 Primary CA ルート証明書 VeriSign クラス 3 Primary CA ルート証明書 G2 Equifax Secure Certificate Authority Equifax Secure eBusiness CA-1 GeoTrust Global CA GTE CyberTrust Global Root Baltimore CyberTrust Root L-01B 2010 年 3 月 26 日 GlobalSign Root CA GlobalSign Root CA-R2 Valicert Class 3 Policy Validation Authority RSA Security 2048 V3 Security Communication RootCA1 AddTrust External CA Root AAA Certificate Services COMODO Certificate Authority VeriSign クラス 3 Primary CA ルート証明書 VeriSign クラス 3 Primary CA ルート証明書 G2 Equifax Secure Certificate Authority FOMA 901i 2004 年 12 月 24 日 Equifax Secure eBusiness CA-1 GeoTrust Global CA GTE CyberTrust Global Root Baltimore CyberTrust Root VeriSign クラス 3 Primary CA ルート証明書 FOMA 900i 2004 年 2 月 29 日 VeriSign クラス 3 Primary CA ルート証明書 G2 GTE CyberTrust Global Root 前述のように、携帯電話や家電?組み込み機器においては、場 クラス 3 Primary CA ルート証 明 書と VeriSign クラス 3 合によっては「信頼できるルート認証局」としてルート証明書 Primary CA ルート証明書 G2）は搭載率 100% に達している が登録されるのは出荷されるタイミングのみです。ベリサインの ことが分かり、この高いルート証明書の普及率が、携帯電話対 ルート証明書（VeriSign クラス 3 Primary CA ルート証明書 応率業界 No.1 を維持しているゆえんです。 と VeriSign クラス 3 Primary CA ルート証明書 G2）は、古 くは 2001 年の携帯電話から「信頼できるルート認証局」とし て登録されています。ここに、ベリサインが SSL 暗号化通信の 対応率として業界 No.1 を維持している理由があります。例え ば、携帯電話におけるルート証明書搭載率を表した資料に株 式会社ケータイラボラ リー『第三世代携帯端末 ルート証明書 ト 搭載状況 調査結果と分析』（2010 年 3 月 1 日、参考 URL： http://www.ktai-labo.com/pdf/ssl_free_report.pdf） が あ ります。この資料によるとベリサインのルート証明書（VeriSign 9
WHITE PAPER 第 4 章　最後に ウェブサイト構築作業において SSL サーバ証明書の導入は、つ い片手間に考えてしまうかもしれません。そのため、SSL サーバ 証明書の選定では、価格や発行スピードで選んでしまいがちです が、その結果としてサービス運用中に思わぬトラブルが発生する 可能性があります。 こういった ラブルを避けるためにも、 ト 今回ご紹介した認証局（ルー ト証明書）の役割について理解したうえで、SSL サーバ証明書 を選定、導入することで、予期しないトラブルを未然に防ぐことが できるでしょう。 10
WHITE PAPER 付録　ベリサインが提供する SSL サーバ証明書 本稿が想定する読者にあたるウェブサイト運営者の SSL サーバ証明書の選定業務の中で、 ベリサインから提供されるSSL サーバ証明書が、 どのルート証明書から発行されているかを正しく把握し、自社のサービス要件にあった証明書を選択いただくために、それぞれの SSL サー バ証明書とルート証明書の関係を解説します。 ベリサインが提供する SSL サーバ証明書には、以下の 4 種類があります。しかしながら、暗号アルゴリズム 2010 年問題の対応によりベ リサイ グローバル?サーバ ID とベリサイ セキュア?サーバ ID に対して、2010 年 10 月に仕様変更いたしました。さらに、申請者 ン ン が選択する「サーバタイプ」によって、発行される SSL サーバ証明書に対応する認証局（ルート証明書）が異なります。 以下では、それぞれの SSL サーバ証明書に対応する認証局（ルート認証局）を図解します。 （1）ベリサイ グローバル?サーバ ID EV ン （2）ベリサイ セキュア?サーバ ID EV ン （3）ベリサイ グローバル?サーバ ID ン （4）ベリサイ セキュア?サーバ ID ン 凡例 証明書の種類 証明書の仕様 証明書の関係 ルート認証局証明書 認証局の名称 署名検証のパス （End-Entity から上位の認証局へ 中間認証局証明書 向かってチェーンを送る） （クロスルート証明書含む） 署名アルゴリズムおよび鍵長 エンドエンティティ証明書 クロスルート方式の場合の 署名検証のパス 中間認証局証明書 11
WHITE PAPER ベリサイン グローバル?サーバ ID EV（サーバタイプ：すべて共通） 階層 ベリサイン グローバル?サーバ ID EV（サーバタイプ：すべて共通） ルート証明書 VeriSign Class 3 Public Class 3 Public Primary Primary Certification Authority Certification Authority - G5 署名アルゴリズム：sha1RSA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 鍵長：1024 bit － － 中間証明書 VeriSign Class 3 Public Primary Certification Authority - G5 署名アルゴリズム：sha1RSA 新しい PC ブラウザ 携帯電話等の 鍵長：2048 bit （IE7 等）の検証パス 検証パス 二階層目中間 CA 証明書 （すべての証明書共通） VeriSign Class 3 Extended Validation SSL SGC CA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 三階層目中間 CA 証明書 （ベリサイン グローバル サーバ ID EV 専用） ? SSL サーバ証明書 SSL サーバ証明書 （End Entity） 12
WHITE PAPER ベリサイン セキュア?サーバ ID EV（サーバタイプ：すべて共通） 階層 ベリサイン セキュア?サーバ ID EV（サーバタイプ：すべて共通） ルート証明書 VeriSign Class 3 Public Class 3 Public Primary Primary Certification Authority Certification Authority - G5 署名アルゴリズム：sha1RSA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 鍵長：1024 bit － － 中間証明書 VeriSign Class 3 Public Primary Certification Authority - G5 署名アルゴリズム：sha1RSA 新しい PC ブラウザ 携帯電話等の 鍵長：2048 bit （IE7 等）の検証パス 検証パス 二階層目中間 CA 証明書 （すべての証明書共通） VeriSign Class 3 Extended Validation SSL SGC CA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 三階層目中間 CA 証明書 （ベリサイン セキュア?サーバ ID EV 専用） SSL サーバ証明書 SSL サーバ証明書 （End Entity） 13
WHITE PAPER ベリサイン グローバル?サーバ ID（サーバタイプ：新仕様 ※1） 階層 ベリサイン グローバル?サーバ ID（サーバタイプ：新仕様） ルート証明書 VeriSign Class 3 Public Class 3 Public Primary Primary Certification Authority Certification Authority - G5 署名アルゴリズム：sha1RSA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 鍵長：1024 bit － － 中間証明書 VeriSign Class 3 Public Primary Certification Authority - G5 署名アルゴリズム：sha1RSA 新しい PC ブラウザ 携帯電話等の 鍵長：2048 bit （IE7 等）の検証パス 検証パス 二階層目中間 CA 証明書 （すべての証明書共通） VeriSign Class 3 Extended Validation SSL SGC CA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 三階層目中間 CA 証明書 （ベリサイン グローバル?サーバ ID 専用） SSL サーバ証明書 SSL サーバ証明書 （End Entity） ※ 1：ストアフロントをご利用のお客様は、 「マイクロソフト」と「マイクロソフト以外のサーバ」の 2 種類を選択した場合に発行されます。 　　　ベリサイン マネージド PKI for SSL をご利用のお客様は、「Old Premium SSL」以外を選択した場合に発行されます。 14
WHITE PAPER ベリサイン グローバル?サーバ ID（サーバタイプ：旧来仕様 ※2） 階層 ベリサイン グローバル?サーバ ID（サーバタイプ：旧来仕様） ルート証明書 Class 3 Public Primary Certification Authority 署名アルゴリズム：sha1RSA 鍵長：1024 bit － 中間証明書 VeriSign International Server CA - Class 3 署名アルゴリズム：sha1RSA 鍵長：1024 bit ベリサイン グローバル?サーバ ID 中間 CA 証明書 SSL サーバ証明書 SSL サーバ証明書 （End Entity） ※ 2：ストアフロントをご利用のお客様は、 「旧来仕様（1024bit）- マイクロソフト」と「旧来仕様（1024bit）- マイクロソフト以外」の 2 種類を選択した場合に発行されます。 　　　ベリサイン マネージド PKI for SSL をご利用のお客様は、 「Old Premium SSL」を選択した場合に発行されます。 15
WHITE PAPER ベリサイン セキュア?サーバ ID（サーバタイプ：新仕様 ※3） 階層 ベリサイン セキュア?サーバ ID（サーバタイプ：新仕様） ルート証明書 VeriSign Class 3 Public Class 3 Public Primary Primary Certification Authority Certification Authority - G5 署名アルゴリズム：sha1RSA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 鍵長：1024 bit － － 中間証明書 VeriSign Class 3 Public Primary Certification Authority - G5 署名アルゴリズム：sha1RSA 新しい PC ブラウザ 携帯電話等の 鍵長：2048 bit （IE7 等）の検証パス 検証パス 二階層目中間 CA 証明書 （すべての証明書共通） VeriSign Class 3 Extended Validation SSL SGC CA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 三階層目中間 CA 証明書 （ベリサイン セキュア?サーバ ID 専用） SSL サーバ証明書 SSL サーバ証明書 （End Entity） ※ 3：ストアフロントをご利用のお客様は、 「マイクロソフト」と「マイクロソフト以外のサーバ」の 2 種類を選択した場合に発行されます。 　　　ベリサイン マネージド PKI for SSL をご利用のお客様は、 階層 中間 CA 1024bit（IIS 用） 「3 」と「3 階層 中間 CA 1024bit（IIS 以外）」の 2 種類を選択した場合に発行 されます。 16
WHITE PAPER ベリサイン セキュア?サーバ ID（プラットフォーム：旧来仕様 ※4） 階層 ベリサイン セキュア?サーバ ID（プラットフォーム：旧来仕様） ルート証明書 Class 3 Public Primary Certification Authority 署名アルゴリズム：sha1RSA 鍵長：1024 bit － 中間証明書 VeriSign International Server CA - Class 3 署名アルゴリズム：sha1RSA 鍵長：1024 bit ベリサイン セキュア?サーバ ID 中間 CA 証明書 SSL サーバ証明書 SSL サーバ証明書 （End Entity） ※ 4：ストアフロントをご利用のお客様の場合、 「旧来仕様（1024bit）- マイクロソフト」と「旧来仕様（1024bit）- マイクロソフト以外」の 2 種類があります。 　　　ベリサイン マネージド PKI for SSL をご利用のお客様の場合、 階層 中間 CA 1024bit（IIS 用） 「3 」と「3 階層 中間 CA 1024bit（IIS 以外）」の 2 種類があります。 Copyright ?2010 VeriSign Japan K.K. All rights reserved. シマンテッ （Symantec）ノート （Norton）およびチェ クマークロゴ ク 、 ン 、 ッ （the Checkmark Logo） は米国シマンテッ ? ク コーポレーション 日本ベリサイン株式会社 （Symantec Corporation） またはその関連会社の米国またはその他の国における登録商標、 または、商標です。 ベリサイ （VeriSign）ベリサイ ? ラ ト ン 、 ン ト ス （VeriSign Trust）およびその他の関連するマークは米国VeriSign, Inc.またはその関連会 、 https://www.VeriSign.co.jp/ 社の米国またはその他の国における登録商標、 または、 商標です。 〒 104-0028　 京都中央区八重洲 2-8-1 東 その他の名称もそれぞれの所有者によ る商標である可能性があり ます。 Tel : 03-3271-7017 17 WPROOT2010_1011 E-mail : websales@verisign.co.jp

More Related Content

Wp sslandroot certificate

  • 1. WHITE PAPER いまさら聞けない、 SSL サーバ証明書と ルート証明書の関係 暗号アルゴリズム 2010 年問題対応される サイト運営者　必見！
  • 2. WHITE PAPER Copyright ?2010 VeriSign Japan K.K. All rights reserved. シマンテック（Symantec） ノートン 、 （Norton）およびチェックマークロゴ 、 （the Checkmark Logo）は米国シマンテック コーポレーション ? （Symantec Corporation）またはその関連会社の米国またはその他の国における登録商標、または、商標です。 ベリサイン（VeriSign）、ベリサイン?トラスト（VeriSign Trust）、およびその他の関連するマークは米国 VeriSign, Inc. またはその関連会社の米国ま たはその他の国における登録商標、または、商標です。 その他の名称もそれぞれの所有者による商標である可能性があります。 日本ベリサイン株式会社は、本書の情報の正確さと完全性を保つべく努力を行っています。ただし、日本ベリサイン株式会社は本書に含まれる情報に関して、 （明示、黙示、または法律によるものを問わず）いかなる種類の保証も行いません。日本ベリサイン株式会社は、本書に含まれる誤り、省略、または記述によっ て引き起こされたいかなる（直接または間接の）損失または損害についても責任を負わないものとします。さらに、日本ベリサイン株式会社は、本書に記 述されている製品またはサービスの適用または使用から生じたいかなる責任も負わず、特に本書に記述されている製品またはサービスが既存または将来の 知的所有権を侵害しないという保証を否認します。本書は、本書の読者に対し、本書の内容に従って作成された機器または製品の作成、使用、または販売 を行うライセンスを与えるものではありません。最後に、本書に記述されているすべての知的所有権に関連するすべての権利と特権は、特許、商標、また はサービス ? マークの所有者に属するものであり、それ以外の者は、特許、商標、またはサービス ? マークの所有者による明示的な許可、承認、またはラ イセンスなしにはそのような権利を行使することができません。 日本ベリサイン株式会社は、本書に含まれるすべての情報を事前の通知なく変更する権利を持ちます。 2
  • 3. WHITE PAPER Contents 概要 4 第 1 章　暗号化通信で必須となる、 SSL サーバ証明書とルート証明書 5 HTTPS 通信の開始方法 5 SSL サーバ証明書とルート証明書の関係 5 第 2 章　暗号化通信における信頼の要、ルート証明書 6 クライアントに登録されるルート証明書 6 認証局（ルート証明書）を登録する基準 7 第 3 章　登録された認証局（ルート証明書）のメンテナンス 8 PC ブラウザにおける認証局（ルート証明書）のメンテナンス 8 携帯電話や家電?組み込み機器における認証局（ルート証明書）の メンテナンス 8 携帯電話（NTT docomo）を例に見る登録された 認証局（ルート証明書） 8 第 4 章　最後に 10 付録　ベリサインが提供する SSL サーバ証明書 11 ベリサイン グローバル?サーバ ID EV（サーバタイプ：共通） 12 ベリサイン セキュア?サーバ ID EV（サーバタイプ：共通） 13 ベリサイン グローバル?サーバ ID（サーバタイプ：新仕様 ※1） 14 ベリサイン グローバル?サーバ ID（サーバタイプ：旧来仕様 ※2） 15 ベリサイン セキュア?サーバ ID（サーバタイプ：新仕様 ※3） 16 ベリサイン セキュア?サーバ ID（プラットフォーム：旧来仕様 ※4） 17
  • 4. WHITE PAPER 概要 不景気を反映した消費スタイルの価格?ポイントサービス志向な どにより、今までホームセンターで買っていたような日用品まで E コマースで購入されるようになってきました。とくに、昨今では、 携帯電話やスマートフォンなどのモバイル EC 市場が全体を牽引 する形となり、景気の低迷にもかかわらず消費者向け E コマース 市場が依然として急成長しています。 この市場の成長スピードと連動してウェブサイト構築に求められる のが、開発スピードです。最近のウェブサイトの開発期間は 2ヶ月、 3 ヶ月という短いサイクルが求められ、一つのトラブルがスケジュー ル全体の致命的な遅延に繋がりかねません。また、そうした短期 間で開発されたシステムに対しては、十分なテスト時間が設けら れず、いざサイトをオープンしたとたんに、トラブルが発生するの です。 「ウェブサイトに接続しようとすると、セキュリティの警告がでるの はなぜ？」 「新しい携帯電話からは通信できるけど、古い携帯電話だと接続 できないはなぜ？」 最近のウェブサイトは、外部システムとの連携が前提で構築され、 こうした複雑化したシステムで発生するトラブルの原因は、ネット ワークからアプリケーション、システム連携など様々な要因が考え られます。ウェブサイト構築にとって一つでもその要因を排除する ことが理想です。このホワイトペーパでは、前述のようなトラブル が発生する原因について、SSL（Secure Sockets Layer）暗号 化通信の技術的な仕組みを通して解説していきます。この仕組み を理解することによって、トラブル発生時に何が原因であるのか、 より具体的にイメージしながら対応することができ、また、事前に 問題回避するこ もできるよ と うになるでしょう。 4
  • 5. WHITE PAPER 第 1 章　暗号化通信で必須となる、 SSL サーバ証明書とルート証明書 https://www.～ HTTPS 通信の開始方法 クライアントのブラウザ ウェブサーバ HTTPS 通信を開始する際に、クライアント（ウェブブラウザや携 帯電話など）とウェブサーバ間では、どのような処理が行われて ①暗号化仕様交渉 いるのでしょうか？ ベリサインの ルート 確認 SSLサーバ 証明書 OK! ②SSLサーバ証明書送付 証明書 クライアントとウェブサーバの間では、下記の手順①～④および 図 1 のようなやり取りが行われます。 共通鍵 共通鍵 ③共通鍵生成 40bit～256bit 40bit～256bit ① クライ トがセキュアなウェブサイ アン ト（https:// ～）へアクセ スし、SSL 暗号化通信で接続を要求します。このときクライア ④暗号化データ通信開始 ントは、自身が使用可能な暗号化の仕様（暗号方式、鍵長、 圧縮方式）をウェブサーバへ伝えます。ウェブサーバは、クラ イアントから提示された暗号化使用から実際に利用するものを 選択して、クライ トへ通知します。 アン 図 1.　SSL 暗号化通信開始時のウェブサーバとクライアントのやり取りのイメージ ② ウェブサーバは、自分の身分を証明する SSL サーバ証明書を HTTPS 通信が開始される短い時間の中で、ルート証明書は、ウェ クライアントへ送ります。クライアントは SSL サーバ証明書を ブサーバから送られてく SSL サーバ証明書の信頼性を判断す る 受け取り、クライ トに「信頼される認証局」と アン してあらかじ る重要な役割を果たしていることがわかるでしょう。 め登録されている認証局（CA）の証明書（これをルート証明 書と呼ぶ）を用いて SSL サーバ証明書の署名検証を行います。 またクライアントは、SSL サーバ証明書からウェブサーバの公 開鍵を取得します。 SSL サーバ証明書とルート証明書の関係 SSL サーバ証明書は、ウェブサイトを運営している団体のいわゆる ③ 正しくルート証明書へのチェーンを辿って署名検証が完了す 「電子的な身分証明書」です。これを確認することで、認証済 ると、クライアントはウェブサーバの公開鍵を用いてプリマスタ みの安全なサイトなのか、それとも身元の確認が取れない危険な シークレット（共通鍵を生成する基となる乱数データ）を暗号 サイトなのかを見極めることができます。 化し、ウェブサーバへ送付します。ウェブサーバは自分の秘 密鍵を用いて、プリマスタシークレットを復号します。 SSL サーバ証明書は、ベリサインのような「認証局事業者」に申 請し、その事業者が設定する認証を受けて発行してもらう必要が ④ ③で共有されたプリマスタシークレットを基にクライアントと あります。SSL サーバ証明書には、 サーバの運営者である組織名、 ウェブサーバで同じ共通鍵を生成および共有し、以降のセッ 証明書を発行した認証局の名前、ウェブサーバの公開鍵や証明 ションではこの共通鍵を用いて暗号化?復号して通信を行い 書の有効期間が明記されており、さらに認証局事業者の署名が ます。 付いています。 認証局事業者の署名とは、SSL サーバ証明書のハッシュ値を認 証局の秘密鍵で暗号化したデータです。クライ トは、 サー アン SSL バ証明書を受け取ると、クライアントに登録されている認証局の 証明書（ルート証明書）を用いて、この認証局の署名を復号し ます。復号したデータが、SSL サーバ証明書のハッシュ値と一致 すれば、第三者によって改ざんされたものでない、正しく認証局 事業者が発行した SSL サーバ証明書であることが確認できます。 5
  • 6. WHITE PAPER 第 2 章　暗号化通信における信頼の要、 Sub ルート証明書 jec CN t =w O= ww .exa OU Exa mp le J mp le.c om クライアントに登録されるルート証明書 =M apa クライアントに登録されているルート証明書のリストは、PC の Issu ark nK etin .K. er gD epa 利用者（運営者）情報 CN rtm O= = Ve riSig n In ent 場 合は簡 単に確 認することができます。Microsoft Internet Ver tern 有効 期限 iSig n atio nal Serv Explorer の場合、メニューの「ツール」から、「インターネット er C オプション（O）、 」「コンテンツ」「証明書」「信頼されたルー 、 、 201 A- 0/3 Clas /1 - s3 201 2/3 /1 発行者（認証局）情報 ト証明書機関」を辿ることで、登録された認証局（ルート証明書） の一覧を確認することができます。 利用者 公開鍵 認証局署名 図 2.　SSL サーバ証明書の概略 このようにウェブサーバから送られてく SSL サーバ証明書が、 る 信頼できる証明書かを署名検証するキーポイ ト ン となるのがクライ アントに登録されている認証局の証明書（ルート証明書）である ことがわかるでしょう。 認証局の証明書（ルート証明書）が存在しないと、ウェブサーバ から送られてく SSL サーバ証明書の認証局の署名が検証でき る ずに、下記のようなエラーが発生します。 ウェブサイトに接続しよ とする う と、セキュリティの警告がでる 新しい携帯電話からは通信できるけど、古い携帯電話だと接続で きない 次の章では、クライ トに登録されているルート証明書に関する アン 概説と、上記エラーの原因であるクライアントがルート証明書を 登録する基準について解説します。 図 3.　Internet Explorer に登録されたルート証明書の確認方法 ルート証明書は、自分自身で電子署名をした電子証明書を発行し ているという特徴があります。図 3. の例で言うと、発行先と発行 者が同じであることで確認することができます。ブラウザベンダー や携帯電話の提供者であるキャリア、家電?組み込み機器メーカ などが、このようなルート証明書を組込むにあたっては、独自に 厳密な審査を行っています。このプロセスに合格して初めて「信 頼できるルート認証局」として登録されるというルールが採用され 6
  • 7. WHITE PAPER ているので、私たちはこれを用いた SSL 通信を「信頼」できると ここで紹介されている監査基準の一つであるWebTrustについて、 言えます。 もう少し詳しく解説します。米国公認会計士協会（AICPA）及 びカナダ勅許会計士協会（CICA）が定めた、オンラインにおけ 次節では、ブラウザベンダーなどが実施する厳密な審査とは、ど る電子商取引を対象とした保証サービスを WebTrust のサービス のような基準に基づくものなのかについて、マイクロソフトが公開 として定義されています。その中でも、認証局の信頼性を保証す している内容を例に説明します。 るサービス して WebTrust for CA という と ものがあり、認証局が その原則と規準に準拠しているかどうかを監査法人が検証し、準 認証局（ルート証明書）を登録する基準 拠が確認された認証局に対して検証報告書が発行します。また、 ベリサインのような認証局は、業務を適切に行うために、CP ブラウザベンダーやキャリア、家電?組み込み機器メーカなどは、 （Certificate Policy：証明書ポリシー）と CPS（Certification このような監査結果を確認することによって、各認証局を「信頼 Practice Statement：認証局運用規程）を作成し、この文書に できるルート認証局」として登録しています。 従って業務を遂行しています。CP/CPS は、認証サービスにおけ 次の章では、クライ トに組み込まれたルート証明書が、どのよ アン る認証局の義務と責任、運用方法、電子証明書の適用範囲など うな形でメンテナンスされるのか、そしてメンテナンスができない を電子証明書の利用者や検証者へ告知することで認証局の社会 場合には、 どのような状況がもたらされるのかについて解説します。 的信頼性を向上させると共に、係争発生時の責任の明確化する ための重要な文書です。一般的に、このような文章は公開されて いますが、実際に認証局が業務を適切に行っているか、また発 行される電子証明書を信頼してよいかを、電子証明書の利用者 を含む外部の利害関係者が判断することはできません。そこで登 場するのが「監査」というキーワードです。 外部の利害関係者が、認証局や発行された電子証明書を信頼で きるかどうかを判断するうえで、認証局の業務に精通し、認証局 から独立した第三者による監査が行われているかどうかが、ブラ ウザベンダーなどが「信頼できるルート認証局」として登録する 重要な基準となっています。たとえば、マイクロソフトでは、登録 基準として、どのような監査を満たす必要があるかをウェブで公開 しています。 マイクロソフ ルート証明書プログラム ト http://technet.microsoft.com/ja-jp/library/cc751157.aspx 一般要件（抜粋） CA は監査を完了し、監査結果をマイクロソフトに 12 か月ごとに提 出する必要があります。監査は、 拡張キー使用法 (EKU) の割り当てで、 マイクロソフトにより有効とされる PKI 階層を対象とする必要があり ます。マイクロソフトが有効にするすべての証明書の使用は定期的に 監査される必要があります。監査レポートは監査の対象となっている 特定の種類の証明書を発行するサブ CA を含むすべての範囲の PKI 階 層を文書化する必要があります。適格な監査には次が含まれます。 ? CA 監査者（監査機関）について認可されている WebTrust により 完了された WebTrust for Certificate Authorities v1.0 またはそ れ以降（英語情報） 。 ? ETSI TS 101 456 v1.2.1 またはそれ以降（英語情報） ? ETSI TS 102 042 v1.1.1 またはそれ以降（英語情報） 、または ? CA 監査者（監査機関）について認可されている WebTrust か、 CA と同じ管轄の査定人についての法律やポリシーにより運営さ れている監査機関のいずれかにより完了された ISO 21188:2006 （英語情報） “Public key infrastructure for financial services - Practices and policy framework”。 ※ CA： Certificate Authority　認証局 7
  • 8. WHITE PAPER 第 3 章　登録された認証局（ルート証明書） 携帯電話（NTT docomo）を例に見る のメンテナンス 登録された認証局（ルート証明書） 携帯電話において、どのようなルート証明書がリストに登録され クライ トの出荷時に組み込まれた認証局（ルート証明書）は、 アン ているかは、携帯電話の提供者である各キャリアのホームページ 定期的にメンテナンス（更新）をする必要があります。その理由 で公開されています。 としては、新しい暗号アルゴリズムを採用したルート証明書の追 加や、危殆化した暗号アルゴリズムを使用しているルート証明書 （参考）各キャリアの SSL/TLS 通信に関する携帯電話仕様に の削除を行う とを目的と こ してメンテナンスが実行されます。 ついて （1）NTT docomo PC ブラウザにおける認証局（ルート証明書）の http://www.nttdocomo.co.jp/service/imode/make/ メンテナンス content/ssl/spec/index.html#taiou PC ブラウザなどでは出荷時に組み込まれた認証局（ルート証明 書）に対して、定期的にオンラインでメンテナンス（更新）が実 （2）au by KDDI 行することができます。 http://www.au.kddi.com/ezfactory/tec/spec/ssl.html （参考）代表的なブラウザベンダーのルート証明書の更新方法 （3）SoftBank Mobile （1）マイクロソフ ルート証明書の更新プログラムが提供されて ト http://creation.mb.softbank.jp/web/web_ssl.html います。 （2）Mozilla Firefox ブラウザのバージョンアップにより自動的に ルート証明書が更新されます。 NTT docomo で公開されている各携帯端末に登録されている ルート証明書の一覧から抜粋した内容を表 2 に示します。これを 見ると分かるように、発売時期などによって登録されているルート 証明書の種類や登録数が異なっていることが確認できます。 携帯電話や家電?組み込み機器における認証局 （ルート証明書）のメンテナンス PC に比べて、携帯電話や家電?組み込み機器には、場合によっ ては、以下のような制限があるので、SSL サーバ証明書の選択 には注意が必要です。 （1）ルート証明書のオンラインアップデート機能が提供されてい ない （2）デバイスのメモリー容量の関係で限られたルート証明書のみ しか登録できない （3）最新の暗号アルゴリズムは取り扱えない つまり出荷時に組み込まれた認証局（ルート証明書）のみが、信 「 頼できるルート認証局」として登録され、SSL 暗号化通信を実現 することができます。 以下では、 NTT docomoが公開しているルー ト証明書の一覧を例にして、SSL サーバ証明書の選択の注意点 を詳細に解説します。 8
  • 9. WHITE PAPER 表 2．各携帯端末（抜粋）に登録されているルート証明書の一覧 機種名 発売日 登録されているルート証明書 L-04B 2010 年 6 月 25 日 VeriSign クラス 3 Primary CA ルート証明書 VeriSign クラス 3 Primary CA ルート証明書 G2 L-03B 2010 年 3 月 12 日 Equifax Secure Certificate Authority Equifax Secure eBusiness CA-1 GeoTrust Global CA GTE CyberTrust Global Root L-02B 2009 年 12 月 18 日 Baltimore CyberTrust Root GlobalSign Root CA GlobalSign Root CA-R2 Valicert Class 3 Policy Validation Authority VeriSign クラス 3 Primary CA ルート証明書 VeriSign クラス 3 Primary CA ルート証明書 G2 Equifax Secure Certificate Authority Equifax Secure eBusiness CA-1 GeoTrust Global CA GTE CyberTrust Global Root Baltimore CyberTrust Root L-01B 2010 年 3 月 26 日 GlobalSign Root CA GlobalSign Root CA-R2 Valicert Class 3 Policy Validation Authority RSA Security 2048 V3 Security Communication RootCA1 AddTrust External CA Root AAA Certificate Services COMODO Certificate Authority VeriSign クラス 3 Primary CA ルート証明書 VeriSign クラス 3 Primary CA ルート証明書 G2 Equifax Secure Certificate Authority FOMA 901i 2004 年 12 月 24 日 Equifax Secure eBusiness CA-1 GeoTrust Global CA GTE CyberTrust Global Root Baltimore CyberTrust Root VeriSign クラス 3 Primary CA ルート証明書 FOMA 900i 2004 年 2 月 29 日 VeriSign クラス 3 Primary CA ルート証明書 G2 GTE CyberTrust Global Root 前述のように、携帯電話や家電?組み込み機器においては、場 クラス 3 Primary CA ルート証 明 書と VeriSign クラス 3 合によっては「信頼できるルート認証局」としてルート証明書 Primary CA ルート証明書 G2）は搭載率 100% に達している が登録されるのは出荷されるタイミングのみです。ベリサインの ことが分かり、この高いルート証明書の普及率が、携帯電話対 ルート証明書（VeriSign クラス 3 Primary CA ルート証明書 応率業界 No.1 を維持しているゆえんです。 と VeriSign クラス 3 Primary CA ルート証明書 G2）は、古 くは 2001 年の携帯電話から「信頼できるルート認証局」とし て登録されています。ここに、ベリサインが SSL 暗号化通信の 対応率として業界 No.1 を維持している理由があります。例え ば、携帯電話におけるルート証明書搭載率を表した資料に株 式会社ケータイラボラ リー『第三世代携帯端末 ルート証明書 ト 搭載状況 調査結果と分析』（2010 年 3 月 1 日、参考 URL： http://www.ktai-labo.com/pdf/ssl_free_report.pdf） が あ ります。この資料によるとベリサインのルート証明書（VeriSign 9
  • 10. WHITE PAPER 第 4 章　最後に ウェブサイト構築作業において SSL サーバ証明書の導入は、つ い片手間に考えてしまうかもしれません。そのため、SSL サーバ 証明書の選定では、価格や発行スピードで選んでしまいがちです が、その結果としてサービス運用中に思わぬトラブルが発生する 可能性があります。 こういった ラブルを避けるためにも、 ト 今回ご紹介した認証局（ルー ト証明書）の役割について理解したうえで、SSL サーバ証明書 を選定、導入することで、予期しないトラブルを未然に防ぐことが できるでしょう。 10
  • 11. WHITE PAPER 付録　ベリサインが提供する SSL サーバ証明書 本稿が想定する読者にあたるウェブサイト運営者の SSL サーバ証明書の選定業務の中で、 ベリサインから提供されるSSL サーバ証明書が、 どのルート証明書から発行されているかを正しく把握し、自社のサービス要件にあった証明書を選択いただくために、それぞれの SSL サー バ証明書とルート証明書の関係を解説します。 ベリサインが提供する SSL サーバ証明書には、以下の 4 種類があります。しかしながら、暗号アルゴリズム 2010 年問題の対応によりベ リサイ グローバル?サーバ ID とベリサイ セキュア?サーバ ID に対して、2010 年 10 月に仕様変更いたしました。さらに、申請者 ン ン が選択する「サーバタイプ」によって、発行される SSL サーバ証明書に対応する認証局（ルート証明書）が異なります。 以下では、それぞれの SSL サーバ証明書に対応する認証局（ルート認証局）を図解します。 （1）ベリサイ グローバル?サーバ ID EV ン （2）ベリサイ セキュア?サーバ ID EV ン （3）ベリサイ グローバル?サーバ ID ン （4）ベリサイ セキュア?サーバ ID ン 凡例 証明書の種類 証明書の仕様 証明書の関係 ルート認証局証明書 認証局の名称 署名検証のパス （End-Entity から上位の認証局へ 中間認証局証明書 向かってチェーンを送る） （クロスルート証明書含む） 署名アルゴリズムおよび鍵長 エンドエンティティ証明書 クロスルート方式の場合の 署名検証のパス 中間認証局証明書 11
  • 12. WHITE PAPER ベリサイン グローバル?サーバ ID EV（サーバタイプ：すべて共通） 階層 ベリサイン グローバル?サーバ ID EV（サーバタイプ：すべて共通） ルート証明書 VeriSign Class 3 Public Class 3 Public Primary Primary Certification Authority Certification Authority - G5 署名アルゴリズム：sha1RSA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 鍵長：1024 bit － － 中間証明書 VeriSign Class 3 Public Primary Certification Authority - G5 署名アルゴリズム：sha1RSA 新しい PC ブラウザ 携帯電話等の 鍵長：2048 bit （IE7 等）の検証パス 検証パス 二階層目中間 CA 証明書 （すべての証明書共通） VeriSign Class 3 Extended Validation SSL SGC CA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 三階層目中間 CA 証明書 （ベリサイン グローバル サーバ ID EV 専用） ? SSL サーバ証明書 SSL サーバ証明書 （End Entity） 12
  • 13. WHITE PAPER ベリサイン セキュア?サーバ ID EV（サーバタイプ：すべて共通） 階層 ベリサイン セキュア?サーバ ID EV（サーバタイプ：すべて共通） ルート証明書 VeriSign Class 3 Public Class 3 Public Primary Primary Certification Authority Certification Authority - G5 署名アルゴリズム：sha1RSA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 鍵長：1024 bit － － 中間証明書 VeriSign Class 3 Public Primary Certification Authority - G5 署名アルゴリズム：sha1RSA 新しい PC ブラウザ 携帯電話等の 鍵長：2048 bit （IE7 等）の検証パス 検証パス 二階層目中間 CA 証明書 （すべての証明書共通） VeriSign Class 3 Extended Validation SSL SGC CA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 三階層目中間 CA 証明書 （ベリサイン セキュア?サーバ ID EV 専用） SSL サーバ証明書 SSL サーバ証明書 （End Entity） 13
  • 14. WHITE PAPER ベリサイン グローバル?サーバ ID（サーバタイプ：新仕様 ※1） 階層 ベリサイン グローバル?サーバ ID（サーバタイプ：新仕様） ルート証明書 VeriSign Class 3 Public Class 3 Public Primary Primary Certification Authority Certification Authority - G5 署名アルゴリズム：sha1RSA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 鍵長：1024 bit － － 中間証明書 VeriSign Class 3 Public Primary Certification Authority - G5 署名アルゴリズム：sha1RSA 新しい PC ブラウザ 携帯電話等の 鍵長：2048 bit （IE7 等）の検証パス 検証パス 二階層目中間 CA 証明書 （すべての証明書共通） VeriSign Class 3 Extended Validation SSL SGC CA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 三階層目中間 CA 証明書 （ベリサイン グローバル?サーバ ID 専用） SSL サーバ証明書 SSL サーバ証明書 （End Entity） ※ 1：ストアフロントをご利用のお客様は、 「マイクロソフト」と「マイクロソフト以外のサーバ」の 2 種類を選択した場合に発行されます。 　　　ベリサイン マネージド PKI for SSL をご利用のお客様は、「Old Premium SSL」以外を選択した場合に発行されます。 14
  • 15. WHITE PAPER ベリサイン グローバル?サーバ ID（サーバタイプ：旧来仕様 ※2） 階層 ベリサイン グローバル?サーバ ID（サーバタイプ：旧来仕様） ルート証明書 Class 3 Public Primary Certification Authority 署名アルゴリズム：sha1RSA 鍵長：1024 bit － 中間証明書 VeriSign International Server CA - Class 3 署名アルゴリズム：sha1RSA 鍵長：1024 bit ベリサイン グローバル?サーバ ID 中間 CA 証明書 SSL サーバ証明書 SSL サーバ証明書 （End Entity） ※ 2：ストアフロントをご利用のお客様は、 「旧来仕様（1024bit）- マイクロソフト」と「旧来仕様（1024bit）- マイクロソフト以外」の 2 種類を選択した場合に発行されます。 　　　ベリサイン マネージド PKI for SSL をご利用のお客様は、 「Old Premium SSL」を選択した場合に発行されます。 15
  • 16. WHITE PAPER ベリサイン セキュア?サーバ ID（サーバタイプ：新仕様 ※3） 階層 ベリサイン セキュア?サーバ ID（サーバタイプ：新仕様） ルート証明書 VeriSign Class 3 Public Class 3 Public Primary Primary Certification Authority Certification Authority - G5 署名アルゴリズム：sha1RSA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 鍵長：1024 bit － － 中間証明書 VeriSign Class 3 Public Primary Certification Authority - G5 署名アルゴリズム：sha1RSA 新しい PC ブラウザ 携帯電話等の 鍵長：2048 bit （IE7 等）の検証パス 検証パス 二階層目中間 CA 証明書 （すべての証明書共通） VeriSign Class 3 Extended Validation SSL SGC CA 署名アルゴリズム：sha1RSA 鍵長：2048 bit 三階層目中間 CA 証明書 （ベリサイン セキュア?サーバ ID 専用） SSL サーバ証明書 SSL サーバ証明書 （End Entity） ※ 3：ストアフロントをご利用のお客様は、 「マイクロソフト」と「マイクロソフト以外のサーバ」の 2 種類を選択した場合に発行されます。 　　　ベリサイン マネージド PKI for SSL をご利用のお客様は、 階層 中間 CA 1024bit（IIS 用） 「3 」と「3 階層 中間 CA 1024bit（IIS 以外）」の 2 種類を選択した場合に発行 されます。 16
  • 17. WHITE PAPER ベリサイン セキュア?サーバ ID（プラットフォーム：旧来仕様 ※4） 階層 ベリサイン セキュア?サーバ ID（プラットフォーム：旧来仕様） ルート証明書 Class 3 Public Primary Certification Authority 署名アルゴリズム：sha1RSA 鍵長：1024 bit － 中間証明書 VeriSign International Server CA - Class 3 署名アルゴリズム：sha1RSA 鍵長：1024 bit ベリサイン セキュア?サーバ ID 中間 CA 証明書 SSL サーバ証明書 SSL サーバ証明書 （End Entity） ※ 4：ストアフロントをご利用のお客様の場合、 「旧来仕様（1024bit）- マイクロソフト」と「旧来仕様（1024bit）- マイクロソフト以外」の 2 種類があります。 　　　ベリサイン マネージド PKI for SSL をご利用のお客様の場合、 階層 中間 CA 1024bit（IIS 用） 「3 」と「3 階層 中間 CA 1024bit（IIS 以外）」の 2 種類があります。 Copyright ?2010 VeriSign Japan K.K. All rights reserved. シマンテッ （Symantec）ノート （Norton）およびチェ クマークロゴ ク 、 ン 、 ッ （the Checkmark Logo） は米国シマンテッ ? ク コーポレーション 日本ベリサイン株式会社 （Symantec Corporation） またはその関連会社の米国またはその他の国における登録商標、 または、商標です。 ベリサイ （VeriSign）ベリサイ ? ラ ト ン 、 ン ト ス （VeriSign Trust）およびその他の関連するマークは米国VeriSign, Inc.またはその関連会 、 https://www.VeriSign.co.jp/ 社の米国またはその他の国における登録商標、 または、 商標です。 〒 104-0028　 京都中央区八重洲 2-8-1 東 その他の名称もそれぞれの所有者によ る商標である可能性があり ます。 Tel : 03-3271-7017 17 WPROOT2010_1011 E-mail : websales@verisign.co.jp