Embed Size (px)
Citation preview
WH
ITE PA
PER
:
powered by Symantec
White Paper
サーバ管理者必見！ 失敗しないSSL/TLSサーバ証明書導入のキホン
White Paper : サーバ管理者必見！失敗しない SSL/TLS サーバ証明書導入のキホン
2
Copyright © 2016 Symantec Corporation. All rights reserved. Symantec と Symantec ロ ゴ は、Symantec Corporation または関連会社の米国およびその他の国における登録商標です。その他の会社名、製品名は各社の登録商標または商標です。
合同会社シマンテック・ウェブサイトセキュリティは、本書の情報の正確さと完全性を保つべく努力を行っています。ただし、合同会社シマンテック・ウェブサイトセキュリティは本書に含まれる情報に関して、（明示、黙示、または法律によるものを問わず）いかなる種類の保証も行いません。合同会社シマンテック・ウェブサイトセキュリティは、本書に含まれる誤り、省略、または記述によって引き起こされたいかなる（直接または間接の）損失または損害についても責任を負わないものとします。さらに、合同会社シマンテック・ウェブサイトセキュリティは、本書に記述されている製品またはサービスの適用または使用から生じたいかなる責任も負わず、特に本書に記述されている製品またはサービスが既存または将来の知的所有権を侵害しないという保証を否認します。本書は、本書の読者に対し、本書の内容に従って作成された機器または製品の作成、使用、または販売を行うライセンスを与えるものではありません。最後に、本書に記述されているすべての知的所有権に関連するすべての権利と特権は、特許、商標、またはサービス ･ マークの所有者に属するものであり、それ以外の者は、特許、商標、またはサービス ･ マークの所有者による明示的な許可、承認、またはライセンスなしにはそのような権利を行使することができません。
合同会社シマンテック・ウェブサイトセキュリティは、本書に含まれるすべての情報を事前の通知なく変更する権利を持ちます。
White Paper : サーバ管理者必見！失敗しない SSL/TLS サーバ証明書導入のキホン
3
Contents
概要 4
SSL/TLS（TransportLayerSecurity）の表記について 4
SSL設定 5つのキホン～これだけは確認しよう！～ 4
1.申請内容を確認する 5
2.中間CA証明書をインストールする 6
3.SSLを有効にする 7
4.安全なSSL通信を確保する 7
5.エラーは2種類に分けて対処する 10
まとめ 10
【付録1】チェックリスト：SSLサーバ証明書 申請時編 11
1.SSLサーバ証明書 ～申請からインストールまで～ 11
2.チェックリスト：SSLサーバ証明書申請時編 11
【付録2】チェックリスト：SSLサーバ証明書 インストール編 12
SSLサーバ証明書のインストール方法 12
SSLサーバ証明書の動作検証 12
【付録3】チェックリスト：SSLサーバ証明書 検証編 13
【付録4】SSL接続エラー種別と解決方法 13
【付録5】ルートCA証明書の確認方法 15
White Paper : サーバ管理者必見！失敗しない SSL/TLS サーバ証明書導入のキホン
4
概要
SSL（Secure Sockets Layer）サーバ証明書には、サーバを運営する団体の実在性を証明する機能とウェブサーバとクライアント間の通信を暗号化する機能があります。この機能を用いることで安全なウェブサイトの通信環境を構築し、ウェブサイトの訪問者 に安心して利用してもらうことができるようになります。ただし、これは SSL サーバ証明書を正しく利用すれば・・・の話。SSL サーバ証明書のインストールが適切でないとエラーや警告画面が表示され、逆にウェブサイト訪問者を不安にさせてしまいます。
SSL サーバ証明書の導入は決して難しい作業ではありません。作業内容がわかっていれば、導入と検証に要する時間は短時間で済みます。しかし、実際に SSL サーバ証明書を導入するのは多くの場合、1 年、もしくは複数年に 1 度。手順を忘れた、手順書が見当たらない、など内容を思い出すことからはじめるため、どうしても作業が煩雑になりがちです。結果、トラブルシューティングに予想以上の時間がかかり作業に何日も費やすことになりかねません。
当資料では、このような問題を解決するためにサーバ管理者が見落としがちな点や注意しておくべき点をピックアップしてわかりやすく解説してきます。作業前に一読しておくと、発生しやすいトラブルを回避して導入に関連する時間の浪費を防ぐことができるでしょう。また、巻末の付録には、各種チェックリスト、およびトラブルシューティング集を掲載しています。作業をしながら必要な項目のみ確認していくのもよいでしょう。SSL サーバ証明書の導入手順書として是非ご活用ください。
SSL/TLS（Transport Layer Security）の 表記について
SSL/TLS について、本資料では特段の明記が無い限り、混乱を避けるために一般に普及している「SSL」という呼称を用いています。
SSL プロトコルは、SSL3.0 を元にした TLS1.0 が RFC として定められたのち、現在ではセキュリティの懸念から利用停止が推奨されています。一方 SSL の後継技術である TLS プロトコルは改良を重ね、最新版が TLS1.2 となっています。シマンテックのSSL サーバ証明書は SSL にも TLS にも対応しています。
SSL 設定 5 つのキホン ～これだけは確認しよう！～
実際に SSL サーバ証明書を申請してから SSL を利用可能にするまでの一連の作業における注意点を 5 つのポイントとしてまとめました。実際に作業にとりかかる前にそれぞれのポイントについて理解しておくと、作業をスムーズに行うことができるでしょう。
1 申請内容を確認する
2 中間CA証明書をインストールする
3 SSLを有効にする
4 安全なSSL通信を確保する
5 エラーは2種類に分けて対処する
※ SSL サーバ証明書の申請からインストールまでの手順、およびインストール方法については本資料の【付録】をご参照ください。
White Paper : サーバ管理者必見！失敗しない SSL/TLS サーバ証明書導入のキホン
5
1. 申請内容を確認する
1-1. 申請情報と書類の用意SSL サーバ証明書を認証局に申請する際には、申請団体情報、申請責任者情報、ドメイン情報をシマンテックなどの認証局へ提出します。また、それぞれが正しい情報であることを証明する書類が必要になることがあります。あらかじめ必要な情報と提出書類を準備しておくと、オンライン申請から証明書発行までの時間を短縮することができます。例）主な確認事項（シマンテック SSL サーバ証明書の場合）
・申請団体：サーバ ID を申請する団体名は何か？・申請責任者：申請責任者として登録する担当者は誰か？・ウェブサイト：利用しているドメイン名の所有名義は何か？提出する内容と種類は SSL サーバ証明書の種類（企業認証、ドメイン認証、クライアント認証など）、および申請する団体の属性
（法人、地方公共団体、大学など）やドメインの所有者の状況などにより異なります。多くの証明書を扱うお客様向けにご用意しているエンタープライズ向けサービス（マネージド PKI for SSL）を利用する場合は、手続き方法が異なるので申請前にシマンテックのような認証局ベンダーに確認しましょう。
1-2. CSR の生成CSR（Certificate Signing Request）とは、認証局に署名しもらうための、テキスト形式の署名要求のことです。CSR は、各自のウェブサーバで簡単に作成することができますが、作成する前にあらかじめディスティングイッシュネーム（DN）を決めておく必要があります。ディスティングイッシュネームは [ 証明書の詳細タブ ] のサブジェクトに表示される情報です。ウェブサイト利用者が閲覧する内容ですので、正確に記述する必要があります。部門名 (OU) には、お客様が指定した情報のほかに複数の情報が表示されることがありますのでご注意ください。
【ディスティングイッシュネーム】コモンネーム
（CommonName） SSL暗号化通信を行うサイトのURL
組織（Organization） ウェブサイトを運営する組織の正式団体名部門名
（Organizational Unit） 部門・部署名など、識別名称
市区町村名(Locality） ウェブサイトを運営する組織の 市区町村名
都道府県 (State or Province) ウェブサイトを運営する組織の都道府県名
国名(Country) ISO規定の日本の国コード JP
EV SSL 証明書の場合は、上記の項目に加え決まった固定値、または申請団体の区分による入力情報の違いがありますので特にご注意ください。詳細は下記 URL を参考にしましょう。
https://knowledge.symantec.com/jp/support/ssl-certificates-support/index?page=content&id=SO28014
図 1：証明書のサブジェクト
ディスティングイッシュネームの中でも一番重要な情報はコモンネーム（CN）です。これは、SSL サーバ証明書はホスト名を含む特定のドメイン名で使用するように設定されています。CSR に含まれるコモンネームは、実際に運用するウェブサイトのホスト名と一致していなければならず、間違えているとウェブサイトのホスト名と一致せず SSL 通信時にエラーが発生します。この問題を解消するには、CSR を作り直し、新しい証明書を申請しなければいけませんので、CSR 作成時には充分に注意しましょう。シマンテックの場合は、証明書の有効期間内であれば、無償で 6 回まで再発行が可能です。
【コモンネーム例】
運営するサイト コモンネーム
例） https://www.symantec.com → www.symantec.com
例） https://symantec.com → symantec.com
White Paper : サーバ管理者必見！失敗しない SSL/TLS サーバ証明書導入のキホン
6
2. 中間 CA 証明書をインストールする
2-1. 中間 CA 証明書のインストールブラウザ（HTTP/HTTPS 通信のクライアント）は、ウェブサーバから送付された SSL サーバ証明書の署名、中間 CA 証明書の署名、およびブラウザに保存されているルート CA 証明書を照合してその信頼性を検証します。SSL サーバ証明書は階層構造になっていますから、SSL サーバ証明書と最上位のルート CA 証明書までのパスを正しくたどるためには、中間CA証明書が必要です。SSL サーバ証明書をウェブサーバにインストールする際には、忘れずに中間 CA 証明書もインストールしましょう。
また、認証局ベンダーはセキュリティ対策の一環として新しい中間 CA 証明書を発行、または入れ替えする場合があります。SSLサーバ証明書更新時にも必ず中間 CA 証明書が正しい組み合わせになっていることを確認しましょう。一部の環境では、Internet Explorer 等特定のブラウザで中間 CA 証明書がウェブサーバにインストールされていない場合でも、サーバ証明書の検証が完了する場合があります。これは、一部の環境の Internet Explorerが自動的に中間 CA 証明書をダウンロードしキャッシュする機能を持っているからです。しかし、他のほとんどのブラウザは正しい中間 CA 証明書をサーバ接続時に用意しておかないと、エラーが発生しますのでご注意ください。
（参考）Apache + OpenSSL 中間 CA 証明書のインストール手順
https://knowledge.symantec.com/jp/support/ssl-certificates-support/index?page=content&id=SO23415
2-2. 正しくパスをたどれるか？中間 CA 証明書はすべての製品に共通ではなく、それぞれのSSL サーバ証明書専用の中間 CA 証明書が用意されています。正しい中間 CA 証明書をインストールできていることを確認することが必要です。以下のサイトでは、中間 CA 証明書が正しくインストールされ、且つルート CA 証明書まで正しくたどれているか確認するためのツールをご紹介しています。( 英語 )
https://www.symantec.com/ja/jp/page.jsp?id=crypto-report
2-3. PKCS7 形式の SSL サーバ証明書証明書には複数の形式があります。SSL サーバ証明書申請時に、
「サーバソフトウェア」の項で "Microsoft" を選択した場合、中間 CA 証明書が SSL サーバ証明書とパックされた PKCS8 形式の証明書が発行される場合があります。PKCS7 形式の証明書をインストールした場合は、中間 CA 証明書をインストールする必要はありません。
White Paper : サーバ管理者必見！失敗しない SSL/TLS サーバ証明書導入のキホン
7
3. SSL を有効にする
3-1. ウェブサーバの設定SSL サーバ証明書と中間 CA 証明書をインストールしたら、次にサーバの SSL の設定を確認しましょう。ウェブサーバの種類によっては、SSL を有効にする設定が求められます。詳細は、ウェブサーバのユーザガイドを確認してください。
3-2. HTTPS 専用ポートの指定HTTPS 通信（SSL 機能）の場合は、HTTP と HTTPS の通信を見分けるためにそれぞれ異なるポートを準備します。忘れずにSSL 専用のポート番号（標準：443）を指定し、ポートが正しく設定されていることを確認しましょう。
4. 安全な SSL 通信を確保する
一般的に『SSL を導入すれば安全だ』『SSL を導入したから通信の機密性は確保されている』と考えがちですが、決してそうとは言い切れません。実際には、SSL のサーバ証明書の秘密鍵さえ取得できれば SSL を乗っ取ることができてしまいます。また、SSL 接続時に使われている暗号技術は、「強度」が弱いものから強いものまで様々です。HTTPS 通信のセキュリティを最適化する方法をみてみましょう。
4-1. 秘密鍵さえ取得できれば SSL を乗っ取ることができる !?SSL には、SSL 接続開始時に「公開鍵暗号方式」という暗号化技術が用いられています。この方式では、公開鍵と秘密鍵が 1 ペアとして作動し、それぞれの鍵を用いてデータの暗号化・複合化を行っています（SSL の仕組みは、以下のホームページで詳しくご紹介しています。
http://www.symantec.com/ja/jp/page.jsp?id=how-ssl-works
SSL サーバ証明書の場合、CSR を作成する際にこの鍵ペア（キーペア）を生成します。秘密鍵はサーバに保存され、公開鍵は証明書に組み込まれて広くその通信相手に公開（配布）されます。公開鍵を用いて暗号化されたデータは、その対となる秘密鍵でのみ複合化することができます。つまり、秘密鍵が漏洩すると、理論的には SSL 通信の内容を解読することができます。
秘密鍵の保存場所
「公開鍵暗号方式」を用いている場合、「秘密鍵」（プライベート鍵）は他の誰にも開示してはならず、安全に管理しなければなりません。しかし、厳重に保管しても運用の妨げになるようでは困ります。実際には、ハッカーや攻撃者はウェブサーバやデータベースに直接侵入してデータを盗もうと試みることが多く、SSL の通信内容を解読するためだけに秘密鍵を盗もうと試みるケースは少ないと言われています。運用のしやすさと御社のセキュリティ対策状況を鑑みて保存方法を選択するのがよいでしょう（表 1）。
秘密鍵の保管方法 安全度 メリット デメリット
1 専用のハードウェアを用いて秘密鍵を暗号化して保管する 高 ・ ウェブサーバが侵入を受けた場合でも、秘密鍵を保
護できる ・ 専用のハードウェアを使用するためコストがかかる
2 ウェブサーバ上のファイルに鍵を暗号化して保存する 中 ・ 鍵がパスフレーズによって保護される
・ コストがかからない
・ ウェブサーバを再起動した場合に都度パスフレーズの入力を求められる
・ 暗号化されていない鍵を容易にみつけることができる
3 ウェブサーバ上のファイルに鍵を保存する 低 ・ コストがかからない
・ 運用が楽である・ サーバに侵入された場合、SSL通信内容を解読することがで
きる
表1：秘密鍵の保存場所
White Paper : サーバ管理者必見！失敗しない SSL/TLS サーバ証明書導入のキホン
8
バックアップしたキーペアは、セキュリティ上非常に重要なデータとなることに留意し、物理的にアクセスが制限された場所に HSM
（Hardware Security Module）へ格納した形で保管しておくなど、厳重に管理することをお奨めします。また、ネットワークの通信環境を用いて、鍵の受け渡しする場合には必ず暗号化された環境で行いましょう。
4-2. 秘密鍵漏えいに危険性2014 年 4 月に OpenSSL のバージョン 1.0.1 系における脆弱性（通称「Heartbleed」）が発見されました。OpenSSL とは、オープンソースの暗号ソフトウェアライブラリで Apache ウェブサーバ等で SSL/TLS 通信を行うために使用されます。影響範囲が広く、世界中にあるウェブサーバの相当数がこの脆弱性の対応に追われました。この脆弱性そのものは、SSL サーバ証明書とは無関係です。しかしながら、この脆弱性を悪用した攻撃では、攻撃者は、ウェブサーバ上のメモリを不正に得ることが可能になります。その結果、SSL 通信における秘密鍵や個人情報など、重要な情報の漏えいが引き起こされる懸念があります。
図：HeartBleed の仕組み
弊社が提供している、CryptoReport と呼ばれるツールでは、ウェブサイトの URL を入力することにより、証明書の階層表示とともに、そのウェブサイトが持っている脆弱性についても分析を行い警告を表示します。（英語）
CryptoReport
https://cryptoreport.websecurity.symantec.com/checker/
4-3. 暗号化仕様 (Cipher Suite) の設定SSL 通信中のウェブサーバとブラウザ間の通信で利用される「共通鍵暗号」の暗号化仕様の設定を行いましょう。ウェブブラウザ（クライアント）ではより多くのサーバとの接続を可能とするため、SSL のプロトコルには弱い暗号も含めてさまざまな暗号化仕様（Cipher Suite）が実装されており、それぞれの優先順位を決めています。
2014 年 9 月 に 発 覚 し た、CVE-2014-3556（ 通 称「POODLE」）と呼ばれる脆弱性では、攻撃者はウェブサーバとクライアント間での応答の仕組みを悪用し、実装も古く、解読が可能である、SSL3.0 といわれる暗号設定へプロトコルのバージョンを強制的に下げて接続をさせることにより、通信内容を解読しCookie などの情報を不正に取得するものです。
こうしたことから、ウェブサーバ側でどの暗号化仕様を優先的に利用するのか設定をしないと、SSL 接続ネゴシエーション時に無意識に弱い暗号化仕様が選択されていることが起こりえます。より安全な通信を行うためには、あらかじめサーバ側で「弱い暗号は利用不可」、または「暗号強度の高い順に選択」など、適切な設定を行いましょう。
（参考）独立行政法人 情報処理推進機構（IPA) 公開 SSL サーバ設定状況等の調査報告書
（図表）推奨された暗号アルゴリズムで構成された Cipher Suite https://www.ipa.go.jp/files/000014264.pdf
White Paper : サーバ管理者必見！失敗しない SSL/TLS サーバ証明書導入のキホン
9
4-3. 暗号はいつか解読される !?暗号化アルゴリズムの安全性は、コンピュータの性能向上や暗号解読技術の進歩によって徐々に低下していきます。常に安全な状態を保つために、より強度の高い暗号化技術を取り入れることが求められます。これは、SSL 通信においても同じこと。SSL を導入しているから今もこれからも「安全」なのではなく、現在の技術による安全性はいつか「低下していくこと」を認識しておくことが必要です。また、SSL サーバ証明書を導入する際にも、より強固な署名アルゴリズムを採用したり、中間 CA 証明書やルートCA 証明書も含め対策を講じている認証局を選択するのが好ましいでしょう。
「2010 年問題」
2010 年は、まさに強度の高い暗号化アルゴリズムへの「移行」が進められた時期でした。セキュリティの観点では、より安全な暗号化技術を取り入れていくのが望ましい一方で、SSL/TLS 通信に支えられる情報システムの可用性を損なうことなく移行することが重要です。これらの課題は、「暗号アルゴリズムにおける2010 年問題」として注目され、シマンテックもこれまで積極的にこの問題に取り組んでいます。
「ハッシュアルゴリズムの移行」
2010 年問題への対応で移行を終えた「RSA 1,024bit」の公開鍵暗号方式や、デジタル署名に利用される、ハッシュアルゴリズム SHA-1 は、「80bit の等価安全性を持っている」と評価されています。これらは、このグループに属する暗号アルゴリズムの解読に必要な計算量が２の 80 乗相当である暗号強度ということを意味します。しかしながら、CRYPTO2012 というカンファレンスにおいて、より少ない計算量で解読可能な SHA-1 に対する原像攻撃が発見された旨の論文が発表※１されました。こうして、暗号アルゴリズムはコンピュータの計算性能向上と新たな攻撃手法の発見によって、さらにその安全性が低下していきます。
CRYPTREC（Cryptography Research and Evaluation Committees 暗号技術について調査・検討するプロジェクト）では、SHA-1 はすでに実際に解読されるリスクが高まるなど、推奨すべき状態ではなくなった暗号技術として「運用暗号リスト」に掲載され、互換性維持以外の目的での利用は推奨しないとしています。
一方、112bit 安全性を持つハッシュアルゴリズム SHA-2( 以下、SHA-224、SHA-256、SHA-384、SHA-512 を 総 称して
「SHA-2」と呼びます ) は、前述の CRYPTREC の暗号リストにおいて電子政府推奨暗号リストとして掲載されており、安全性及び実装性能が確認された暗号技術で今後の普及が見込まれると判断されています。すなわち、本当の「2010 年問題」への対応は、「80bit 安全性」のハッシュアルゴリズムである SHA-1 の使
用を中止し、「112bit 以上の安全性」を持つアルゴリズムであるSHA-2 への移行によってはじめて完了すると言えます。※２
これらの背景もあり、２０１３年より各ブラウザ、プラットフォームベンダーは、ハッシュアルゴリズムに SHA-1 を使用した SSL サーバ証明書の利用停止を次々とアナウンスしました。今後、インターネットにおける一般的なセキュリティ要件として「SHA-2」への対応が標準となってゆくでしょう。
Google Chrome における SHA-1 の SSL サーバ証明書に対する警告表示（例）：
※１： New Preimage Attacks Against Reduced SHA-1 http://www.iacr.org/conferences/crypto2012/slides/6-3-Knellwolf.pdf
※２： 2013 年 7 月『CRYPTREC Report 2012 暗号方式委員会報告書』 http://www.cryptrec.go.jp/report/c12_sch_ ウェブ .pdf
本ケースについては、「SSL サーバ証明書の SHA-2 移行ガイドブック‐チェックリスト付き」としてホワイトペーパをご提供しております。ぜひ参考にしてください。
White Paper : サーバ管理者必見！失敗しない SSL/TLS サーバ証明書導入のキホン
10
5. エラーは 2 種類に分けて対処する
SSL サーバ証明書をインストールしたのに、SSL で接続できない、あるいは接続したときにブラウザに警告メッセージが表示されるケースがあります。これらのトラブルの原因は大きくA. サーバ側の設定によるものと、B. クライアント側の設定によるものに切り分けることができます。トラブルが発生した場合にはそれぞれの側面から何らかの設定ミスが無いか確認してみましょう。
5-1. サーバ側の設定まず、インストールの際に見落としている点がなかったか確認します。本資料【付録】を利用してもう一度正しくインストールされているかチェックしましょう。また、エラーには SSL 接続ができない場合と、警告画面が表示される場合の 2 パターンにわかれます。巻末の【付録】では、各種エラー内容とその原因、対処方法について紹介していますので、トラブルシューティングの際に参考にしてください。このセクションでは、よく発生するエラーについてご紹介します。
5-1-1. SSL サーバ証明書以外の要因 － HTTPS のページ構成－
このメッセージはブラウザで表示しようとしているページ内で http（SSL でセキュリティ保護されていない）と https（SSL でセキュリティ保護されている）で参照されているコンテンツが混在している場合に表示されます。
「はい」を選ぶと SSL での保護が効く状態になりますが、一部コンテンツが表示されず、サイト管理者が意図しない表示状態となります。「いいえ」を選ぶとウェブページコンテンツが全て表示されますが、SSL での保護が不十分になり、実質 SSL 接続の意味がなくなってしまいます。
この警告を回避するには、サイト管理者が画像ファイル、CSS、JavaScript などのファイル参 照や、Flash などを参 照する<embed> タグ、<object> タグに記述されている URL などもhttps で記述する必要があります。または、「http」、「https」を含めない相対パスで記述することも一つの方法です。
図 3：エラーメッセージ ( 例）
5-2. クライアント（ブラウザ）側の設定
5-2-1. ルート CA 証明書
SSL を確立するには、SSL サーバ証明書の発行元であるルートCA 証明書があらかじめブラウザに「信頼されたルート CA 証明書」として登録されている必要があります。もし登録されていない場合は、Windows Update などの機能を利用して証明書をブラウザにインストールしましょう。
各クライアントにより搭載されているルート CA 証明書および証明書の追加登録方法は異なります。SSL サーバ証明書インストール後のテストを行う際にはそれぞれ想定するクライアントで SSL 接続が可能か確認しましょう。携帯電話などクライアント利用者自身が、ルート CA 証明書をインストールできない場合もありますのでご注意ください。本資料末尾にある【付録】では、Internet Explorer にて搭載されているルート CA 証明書の確認方法をご紹介しています。
5-2-2. ブラウザのオプション設定
EV SSL 証明書の場合、ブラウザの設定によっては、アドレスバーが緑にならない場合があります。検証する際に用いている検証環境のブラウザ設定を確認しましょう。また、Google Chrome では、EV SSL 証明書の CT 機能が有効になっていない場合、アドレスバーは緑色になりません。
（参考）Internet Explorer で EV 証明書がインストールされたサイトにアクセスしても、アドレスバーが緑色に表示されませんhttps://knowledge.symantec.com/jp/support/ssl-certificates-support/index?page=content&id=SO25544
（参考）Certificate Transparency (CT) についてhttps://knowledge.symantec.com/jp/support/ssl-certificates-support/index?page=content&id=INFO2181
まとめ
SSL サーバ証明書の導入は決して難しいものではありません。導入手順書やチェックリストを事前に準備しておくことで時間をかけずに完了することができます。今回ご紹介した証明書インストール時の留意点やチェックリストを活用して、より効率的な作業を実現しましょう。余分な時間をかけることなくSSL サーバ証明書を導入することができるだけでなく、ウェブサーバに表示されるエラーを事前に解消しておくことで御社のウェブサイトを訪れるユーザに安心感を与えることができるでしょう。
参考文献Simson Garfinkel、Gene Spafford、ウェブセキュリティ、プライバシー＆コマース、第 2 版 2002、株式会社オライリー・ジャパン
White Paper : サーバ管理者必見！失敗しない SSL/TLS サーバ証明書導入のキホン
11
【付録1】チェックリスト ： SSLサーバ証明書 申請時編
1. SSLサーバ証明書 ～申請からインストールまで～
はじめに、SSLサーバ証明書を取得する手順について確認してみましょう。次の表では、シマンテックSSLサーバ証明書を例として証明書の申請からインストールするまでの手順をご紹介いたします。
プロセス 内容 作業区分
1. 申請 申請の準備 SSLサーバ証明書を発行するために必要な情報、書類を準備します。 例） ウェブサーバを運営する団体名（会社名） 団体の英文表記名 申請責任者名、在籍証明書 等
ウェブサーバ担当者
CSRの生成 ウェブサーバでCSR（証明書署名リクエスト：Certificate Signing Request）を作成します。
オンライン申請 シマンテック（認証局）のオンライン申請ページで、SSLサーバ証明書の申請をします。
2. 認証 提出された情報を元に、客観的且つ公平性を保った確認作業（認証）を申請団体に対して行います。
シマンテック
3. 発行 SSLサーバ証明書を発行し、申請者へEメールにて送付します。 シマンテック
4. SSLサーバ 証明書の設定
インストール 作業には主に下記の内容が含まれます。 ・ 発行されたSSLサーバ証明書のインストール ・ SSLサーバ証明書の上位中間CA証明書のインストール ・ キーペアのバックアップ ・ SSLを有効にする設定
ウェブサーバ担当者
検証 様々なブラウザでSSL接続(https://～)が確立しているか、鍵マークが表示されているか、SSLサーバ証明書のプロファイルが正しいか検証します。
シールの設定 ウェブページのSSL通信をより視覚的に強調するために、ノートンTMセキュアドシールを掲載します（任意）。
2. チェックリスト：SSL サーバ証明書申請時編
作業内容 チェック項目 関連するトラブル・影響範囲
新規申請
□ CSRのコモンネームにサイトのホスト名を正しく記載したか？ 「ドメイン名の不一致」というSSL接続エラーが発生する。
□ CSRに正しい組織名を記載したか？特に“K.K.” “Ltd.” なども含め正式な英文表記であるか、スペルミスがないか確認する。
サイトの表記と証明書内の表記が異なるとエンドユーザの信頼性や、企業イメージを損なう原因になる。
□ 秘密鍵のバックアップは行ったか？ インストール前にサーバトラブル等で秘密鍵を破損するとSSLサーバ証明書をインストールできなくなる。
更新申請 □ 作成専用のディレクトリ配下（Apache）もしくは仮サイト（IISなど）を作成してから、秘密鍵・公開鍵を作成しようとしているか？
運用中のSSLサーバ証明書の秘密鍵を上書きし、ウェブサーバのSSL通信が停止してしまう。
White Paper : サーバ管理者必見！失敗しない SSL/TLS サーバ証明書導入のキホン
12
【付録2】チェックリスト ： SSLサーバ証明書 インストール編
作業内容 チェック項目 関連するトラブル・影響範囲
インストール □ SSLサーバ証明書を正しくコピーしてインストールしたか？メールからコピー＆ペーストする際に不要な改行やスペースが含まれていないか？
・ ウェブサーバに、証明書をインストールできない。・ SSLの接続エラーが発生する。
□ ウェブサーバにSSLサーバ証明書に含まれる公開鍵とペアの秘密鍵がインストール（もしくは保存）されているか？
□ 秘密鍵、SSLサーバ証明書、中間CA証明書保存先ファイルパスに誤記はないか？
□ 必要な中間CA証明書をインストールしたか？
□ キーペアのバックアップを行ったか？バックアップさえあれば、ウェブサーバ故障時や災害時、ハードウェアの変更時に新しいサーバ環境に移行することができる。バックアップが無い場合、SSLサーバ証明書の再取得が必要となる。
サーバリプレース □ リプレースする際のサーバは、エクスポートするキーペアのファイルをインポートできるか？
SSLサーバ証明書を新しい環境にインストールできない。
□ キーペアのバックアップは行ったか？キーペア、SSLサーバ証明書を破損した場合は、SSLサーバ証明書の新規申請・再取得が必要となる。
SSLサーバ証明書のインストール方法SSL サーバ証明書のインストール方法は各ウェブサーバアプリケーションにより異なります。シマンテックでは、主なウェブサーバのインストール手順は下記のサイトでご紹介しています。詳細は、ウェブサーバのユーザガイドや、各ベンダーへお問い合わせください。
SSL サーバ証明書のインストール手順 https://knowledge.symantec.com/jp/support/ssl-certificates-support/index?page=content&id=SO24090
SSL サーバ証明書の動作検証
インストールが完了したら必ず検証を行い、エラーや警告がブラウザで表示されないか確認しましょう。警告メッセージや、鍵マーク、緑のアドレスバー（EV SSL 証明書の場合）が表示されないといった事象は、ユーザに対して不信感を与え、機会損失や企業イメージが損なわれる原因となります。
White Paper : サーバ管理者必見！失敗しない SSL/TLS サーバ証明書導入のキホン
13
【付録 3】チェックリスト：SSL サーバ証明書 検証編
SSL サーバ証明書をインストールしたら、各サービスでサポートしている OS 環境下のブラウザにおいて正しくSSL 接続が確立されているか検証します。ブラウザで警告が表示されると、鍵マークやグリーンバー（EV SSL 証明書の場合）が表示されなくなり、ユーザに対して不信感を与え、機会損失や企業イメージが損なわれる原因となります。また、SSL サーバ証明書インストール作業の無用な時間やコストを抑えるためにも、事前に作業内容とチェック項目を作成しておくのがよいでしょう。
次の表では、検証項目の参考一覧です。エラーが発生する場合は、次のセクションを参考にして問題を解決していきましょう。
プロセス チェック項目 関連するトラブル・影響範囲
インストール後検証 □ https://でつながっているか？ SSL接続ができない。接続のURLが（https://）で始まっていれば、SSL暗号化通信中であることが確認できる。また、一般的にSSL接続中はブラウザに施錠した鍵のマークが表示される。□ 鍵マークが表示されているか？
□ 証明書のプロファイルは想定どおりか？ウェブサイトを運営している団体の組織名が正しく表示されていない。ウェブサイトに設定されている鍵マークをクリックし、SSLサーバ証明書を開いて記載されている情報を確認しておくことが必要。
□ サービスをサポートするさまざまなブラウザで接続可能か？ ブラウザにエラー画面が表示される。＊
□ （EV SSL証明書の場合）ウェブサイトのアドレスが緑色のバーになるか？
EV SSL証明書の特徴である緑色のバーが正しく表示されない。
□ クロスルートの証明書が正しくチェーンしているか？
SSL接続ができない。クロスルート形式が用いられている証明書では、それぞれの階層構造
（3階層、または4階層）で正しく検証されるか、確認する必要がある。ブラウザのルートCA証明書を追加・削除して検証する。
＊SSL サーバ証明書によってサポートしているブラウザが異なります。
【付録 4】 SSL 接続エラー種別と解決方法
次の表では、SSL に関連するトラブルの原因と解決策について事象別にまとめています。
エラー内容 原因 解決策
証明書をインストールできない（IIS） ・ SSLサーバ証明書の保存方法が不完全。
・ 送付されたSSLサーバ証明書の（----- BEGIN CERTIFICATE ----） から （----- END CERTIFICATE -----） までをテキストで保存する。
・ SSLサーバ証明書インストール先の仮想サイトを削除してしまった。
・ CSRを生成し保留中になっている仮想サイトを誤って削除してしまった場合は、CSRの生成からやり直す。
・ CSRを生成した仮想サイトと異なるサイトにインストールしようとしている。 ・ CSRを生成した仮想サイトであることを確かめる。
証明書をインストールできない（Apache）
・ 指定したSSLサーバ証明書と秘密鍵ファイルの組み合わせが正しくない。
・ 正しい設定ファイルを指定する。＜SSLCertificateKeyFile＞ 申請したCSRの秘密鍵ファイルのパスとファイル名を指定する。＜SSLCertificateFile＞ サーバID(証明書)ファイルのパスとファイル名を指定する。
ウェブサイトに鍵マークが表示されない ・ サーバIDのインストールが正しく完了していない。 ・ ウェブサーバで現在有効になっている証明書のプロファイルを
確認し正しくインストールされているか検証する。
・ フレーム分割しているページ構成で、一部に非SSLページが含まれている。
・ フレーム内のすべてのコンテンツをSSL通信に切り替える。ページ構成を変更する。
・ ページ内に非SSLリンク設定が設定されている。 ・ 絶対パスでリンク指定されていないか確認する。
White Paper : サーバ管理者必見！失敗しない SSL/TLS サーバ証明書導入のキホン
14
エラー内容 原因 解決策
httpsで接続できない ・ SSLのポート番号（標準：443）が正しく設定されていない。 ・ SSLのポートやネットワーク設定を確認する。
・ 対象となるサイトが動作していない。 ・ サービスの動作状況を確認する。
・ ブラウザが提示する暗号化仕様とウェブサーバ側の暗号化仕様が一致していない。
・ ウェブサーバのアプリケーションが利用する暗号仕様の設定を見直す。
・ ウェブサーバに中間CA証明書が正しくインストールされていない。 ・ 中間証明書をウェブサーバにインストールする。
・ クライアントにルートCA証明書が搭載されていない。 ・ クライアントにルートCA証明書をインストールする。・ クライアントの製造元に問い合わせる。
EV SSL証明書アドレスバーが緑色にならない
・ EV SSL証明書に対応していないブラウザである。 ・ ブラウザのバージョンを確認する。また携帯電話では緑色のバーに対応しておりません。
・ インターネット環境に接続できないテスト環境でウェブサーバと接続確認している。
・ インターネットに接続できる回線で接続確認する。（フィッシング情報や証明書の失効情報をダウンロードできる環境の必要があります）
・ ルートCA証明書が搭載されていない。 ・ ルートCA証明書をインストールする。
・ （Internet Explorer 7の場合）ブラウザの「フィッシング詐欺検出機能」の自動的なウェブサイトの確認機能が無効になっている。
・ Internet Explorer 7.x を起動し、メニューバーから[ツール]→[フィッシング詐欺検出機能]→[自動的なWebサイトの確認を有効]をクリックする。
エラーが発生する【警告メッセージ】・ セキュリティ証明書の名前が
サイト名と一致しません。・ CSRで指定されているコモンネームがブラウザのURLと異なる。 ・ 正しいコモンネームでSSLサーバ証明書を再取得する。
【警告メッセージ】・ 有効期限が切れています。 ・ SSLサーバ証明書の有効期限が切れている。 ・ 更新したSSLサーバ証明書が正しくインストールされているか
確認する。
・ クライアントの時間が正しく設定されていない。 ・ クライアントの時間設定を確認する。
【警告メッセージ】・ このWebサイトのセキュリテ
ィ証明書には問題があります。
・ クライアントにルートCA証明書が登録されていないため、SSLサーバ証明書の検証できない。
・ クライアントにルートCA証明書をインストールする。・ 信頼されている認証局から発行される証明書を新たに取得する。
・ 中間証明書がインストールされていない。 ・ 中間証明書をインストールする。
【警告メッセージ】・ このページにはセキュリティ
で保護されている項目と保護されていない項目が含まれています https (SSL)のコンテンツと、httpのコンテンツが1つのウェブペ
ージに混合しているため。
・ すべてのコンテンツをhttps (SSL)で表示させる。注意：フルパス(絶対パス)の場合は、必ずhttpsと記述する。ウェブコンテンツに直接記載されているリンク先がhttpのものをhttpsに変更する。【警告メッセージ】
セキュリティで保護されたWebページコンテンツのみを表示しますか？
携帯電話【警告メッセージ】・ この接続先は安全でない可能
性があります。
・ ウェブサーバにインストールされているSSL サーバ証明書の有効期限が切れている。 ・ インストールしたSSLサーバ証明書の有効期間を確認する。
・ 中間CA証明書がサーバにインストールされていない。 ・ 中間CA証明書をインストールする。
・ SSLサーバ証明書のコモンネームとURLの接続先が一致していない。
・ CSRで指定したコモンネームを確認する。注意：一部携帯端末では、コモンネームの 大文字・小文字の一致までを確認している場合があります。
多くのエラーは、インストール時の作業や設定方法を見直すことで解決することができます。作業前後に、内容の漏れがないか確かめて、検証時のエラー発生数を削減しましょう！
White Paper : サーバ管理者必見！失敗しない SSL/TLS サーバ証明書導入のキホン
15
合同会社シマンテック・ウェブサイトセキュリティhttps://www.jp.websecurity.symantec.com/〒107-0052 東京都港区赤坂1-11-44赤坂インターシティTel:0120-707-637E-mail:[email protected]
Copyright © 2016 Symantec Corporation. All rights reserved.シマンテック（Symantec）、ノートン（Norton）、およびチェックマークロゴ（the Checkmark Logo）は米国シマンテック・コーポレーション（Symantec Corporation）またはその関連会社の米国またはその他の国における登録商標、または、商標です。その他の名称もそれぞれの所有者による商標である可能性があります。製品の仕様と価格は、都合により予告なしに変更することがあります。 本カタログの記載内容は、2016年3月現在のものです。
【付録 5】ルート CA 証明書の確認方法
ルート CA 証明書の確認
証明書の最上位に位置するルート CA 証明書は、ブラウザベンダ独自の基準で選定され、出荷時にインストールされています。PCブラウザで、現在搭載されているルート CA 証明書を確認するには、ブラウザのツール、オプションからアクセスすることができます。
＊ その他クライアントの搭載状況についてはメーカもしくは販売元にお問い合わせください。
Internet Explorer の場合1. [ コントロールパネル ] もしくはブラウザのメニューか
ら [ インターネットオプション ] を開きます。
2. [コンテンツ]タブの、[証明書]ボタンをクリックします。「証明書」ウィンドウが表示されます。
3. [ 信頼されたルート証明機関 ] タブに移動ののち、内容を確認したい電子証明書を選択し、[ 表示 ] ボタンをクリックします。
WPSSLKIHON2010_1603
