よくある質問

お問合せの多い質問についてお答えいたします。

SSLについて
暗号を使いたいだけなので、サーバ証明書は不要なのですが。
なぜ、自社の信用を証明してもらう必要があるのでしょうか。

導入について
コモンネームとはなんですか。
いま利用しているレンタルサーバサービスで利用できますか。
共用型レンタルサーバなどのバーチャルホスト環境で利用できますか。
なぜ「名前ベースのバーチャルホスト」ではSSLを利用できないのでしょうか。
SMTP/POP over SSL や FTP over SSLにも使えますか。
サーバを移転することになりました。サーバ証明書は移転できますか。
サーバのIPアドレスが変更になります。サーバ証明書はどうなりますか。
ホスト名が変更になる場合、サーバ証明書はどうなりますか。
同じサーバの別ドメインのサーバ証明書を利用することはできますか。
コモンネームを変更できますか。
ひとつのサーバ証明書で複数のサブドメインに対応することができますか?
マルチドメイン(SANs)証明書とワイルドカード証明書の違いは?

サービス内容と発行手続きについて
証明書はキャンセルできますか。
途中解約はできますか。
SSLサーバ証明書が発行されるまで、どれくらいの期間がかかりますか?
99.9%のブラウザに対応とのことですが、具体的には?
EV SSL規格とはどのような規格ですか
EV SSL対応のブラウザにはどんなものがありますか。
EV SSLは、結局のところ、どんなメリットがあるのでしょうか。
携帯端末の対応について
SSLアクセラレータを使用しています。サーバ証明書はひとつでいいのでしょうか。
待機系サーバにも証明書は必要でしょうか。
サーバ証明書が不要になりました。別のドメイン用に切り替えできますか。
コモンネームにはどのドメインを指定すればいいのでしょうか。
申請承認メールの配信先は自由に指定できるのでしょうか。
メール認証だけで、審査になるのでしょうか。
D-U-N-S Numberとは
D-U-N-S Numberは必須でしょうか。
コモンネームを間違えてしまいました。
証明書の種類を間違えて申し込んでしまいました。

技術的なQ&A
ブラウザが警告を表示します。
「SNI(Server Name Indication)」 とは何ですか?
暗号強度(128ビット/256ビット)とは何を表しているのでしょうか。
暗号強度が複数ありますが、実際にはどれが使われるのでしょうか。
どのルート証明書が使われるのか教えてください。

SSLについて
暗号を使いたいだけなので、サーバ証明書は不要なのですが。

SSLでは、サーバ証明書は暗号化を行うために必須ですし、認証されたサーバ証明書でなければ、暗号を”破る”ことは可能です。

SSLサーバ証明書の目的は以下のの2つです。
■ 暗号化に必要な鍵を安全に送ること
■ クライアントがサーバより受け取った鍵が、正しく本物のサーバから送られていることを保証すること

特に2番目の役割が重要と考えられます。
SSLで使用されている暗号はきわめて強力で、正面からこれを破ることは大変困難です。
しかし、通信相手に成りすまし、自分宛にデータを送らせることができれば、どんなに強力な暗号が使われていたとしても、容易に通信内容を知ることができます。
サーバ証明書と暗号化は別物という誤解が広まってしまっていますが、サーバ証明書による通信相手の確認は、暗号を”破られない”ためにこそ必要なのです。

なぜ、自社の信用を証明してもらう必要があるのでしょうか。

これもよくある誤解のひとつです。SSLでは、なりすましでないことの証明を、以下の2点を確認することで行います。
■ そのサイトのドメイン名と証明書のコモンネームが一致すること。
■ ブラウザにインストールされたルート証明書からそのサイトのサーバ証明書まで、認証のパスがつながること。

この仕組みが正しく働くためには、ルート証明書を所有する(または、ルート証明書とパスの繋がる中間証明書を所有する)組織が、そのサイトのために発行したサーバ証明書を利用しなければなりません。確かに、サーバ証明書の発行にあたって審査がありますので、結果的にサイト運営者の信用についてもある程度保証をするような形にはなりますが、どちらかといえば副産物的なものです。


導入について
コモンネームとはなんですか。

SSLによる暗号化通信を行うサイトのドメイン名です。 SSL Webサイトの場合、URLに含まれるドメイン名の部分になります。
ブラウザなどのSSLクライアントは、指定したドメイン名とサーバ証明書のコモンネームを比較し、一致するか確認します。
一致しなければSSLクライアントは警告メッセージを表示します。

▼ コモンネームの例(SSL接続の際のURL : コモンネーム)
https://www.ssl-secure.jp/:www.ssl-secure.jp
https://ssl-secure.jp/ : ssl-secure.jp
https://ssl.shop.ssl-secure.jp/ : ssl.shop.ssl-secure.jp
https://ssl.shop.ssl-secure.jp/order/ : ssl.shop.ssl-secure.jp

同一サーバ上に存在するサイトであっても、コモンネームごと(ドメインごと)に異なるサーバ証明書を使わなければなりません。
たとえば https://ssl-secure.jp/ と https://www.ssl-secure.jp/ ではサーバ証明書は別になります。

いま利用しているレンタルサーバサービスで利用できますか。

独自ドメインに対するSSL対応をうたっているサービスであれば、技術的には、どこのレンタルサーバサービスでもご利用になれます。
ただし、レンタルサーバ会社によっては、ユーザが自分で用意したSSLサーバ証明書のインストールができない、または認めていない、または制約がある場合もあります。不明な場合は個々のレンタルサーバ会社にお問い合わせください。

共用型レンタルサーバなどのバーチャルホスト環境で利用できますか。

共用型レンタルサーバでも利用できます。ご利用のレンタルサーバ会社にお問合わせください。

なぜ「名前ベースのバーチャルホスト」ではSSLを利用できないのでしょうか

SNI(Server Name Indication)に対応できるのであれば、「名前ベースのバーチャルホスト」でも利用可能です。
→ 「SNIとはなんですか

SSLは、HTTPでの通信が始まる前に開始されます。したがって、この時点で、どのバーチャルホストに接続するか(どのバーチャルホストのサーバ証明書と秘密鍵を使用するのか)がわかっていなければなりません。
ところが「名前ベースのバーチャルホスト」は、接続するバーチャルホストを、HTTPが始まってから指定します。そのため、SSL開始時点では接続先のバーチャルホストが判別できません。
「IPベースのバーチャルホスト」の場合は、どのIPアドレスに接続してきたかによってバーチャルホストを判別します。接続先IPアドレスはSSLが開始される前にわかるので、バーチャルホストごとにSSLが使用できます。
これはWebサーバやブラウザ、サーバ証明書の種類にかかわらず当てはまる問題です。

SMTP/POP over SSL や FTP over SSLにも使えますか。

はい、使えます。

サーバを移転することになりました。サーバ証明書は移転できますか。

ホスト名が変更にならないのであれば、SSLサーバ証明書はそのまま移転できます。秘密鍵も忘れずに移転してください。 ただし、移転に伴い、ホスト名も変更になる場合は、これまでのサーバ証明書は使えません。新規発行となります。 何らかの理由で移転ができない場合、再発行が可能です。お問い合わせフォームからお申し付けください。
※ホスト名が変更になる場合も再発行の対象外となります。

サーバのIPアドレスが変更になります。サーバ証明書はどうなりますか。

そのまま使用することができます。再発行の必要はありません。

ホスト名が変更になる場合、サーバ証明書はどうなりますか

ホスト名が変更になる場合は、SSLサーバ証明書の新規発行が必要です(再発行の対象にはなりません)。
ただし、ワイルドカード証明書をご利用で、サーバは変更せず、サブドメイン名が変更になるだけの場合は、現在の証明書をそのまま使用できます。

同じサーバの別ドメインのサーバ証明書を利用することはできますか。

出来ません。 ドメイン名と異なるコモンネームのサーバ証明書を使用した場合、アクセスするとブラウザが警告を表示します。 現在のほとんどのブラウザの仕様では、警告を表示しても無視することが可能です。しかし、警告を無視させるような運用は、万一なりすましサイトが出現しても本物のサイトとの区別をつけることが難しくなりますので、別ドメインのサーバ証明書を使用することや、ブラウザの警告を無視するように促すことは絶対に避けてください。

コモンネームを変更できますか。

出来ません。万一、コモンネームを間違えて申し込まれた場合は、速やかにご連絡ください。一度発行されたサーバ証明書はキャンセルできません。

ひとつのサーバ証明書で複数のサブドメインに対応することができますか?

出来ません。たとえば example.jp で取得したサーバ証明書を www.example.jp でも使う、ということはできません。それぞれ別々に証明書を取得する必要があります。
もしも多数のサブドメインをSSL下で運用したい場合は、ワイルドカード証明書がお得です。

マルチドメイン(SANs)証明書とワイルドカード証明書の違いは?

マルチドメイン(SANs)証明書はSAN(Subject Alternative Name)フィールドに複数のドメイン名(FQDN)を追加することで、最大5つの異なるドメイン、サブドメインをSSLサーバー証明書で保護できます。
証明書のブランドにより追加可能なコモンネームが異なります。

・ QuickSSL Premium SAN(DV)ドメインとそのサブドメイン4つ、合計5つ
・ True BusinessID SAN(OV)ドメインと異なるドメイン、サブドメインを合計で5つ
・ True BusinessID SAN EV(EV)ドメインと異なるドメイン、サブドメインを合計で5つ
※合計で5個以上を必要とされる場合は、お問い合わせ下さい。

ワイルドカード(Wildcard)証明書は、同一のドメイン配下の複数の異なるサブドメイン(FQDN)に対し、いくつでも一つのSSLサーバー証明書で保護できます。
すべての証明書ブランドで同一機能です。


サービス内容と発行手続きについて
証明書はキャンセルできますか。

一度発行された証明書はキャンセル出来ません。
お申込み後にキャンセルを希望される場合は、証明書が発行される前に速やかにご連絡ください。

途中解約はできますか。

出来ません。有効期限があることで「期間契約」と誤解されることがありますが、どちらかといえば「返品のできない物品購入」に近いので、「解約」という考え方が当てはまりません。

SSLサーバ証明書が発行されるまで、どれくらいの期間がかかりますか?

証明書により異なります。また、以下の日数は入金を確認してからの目安です。

ドメイン認証(DV)
(JPRS証明書以外)
カード決済:15分以内
銀行振込:2営業日以内
ドメイン認証(DV)
(JPRS証明書)
カード決済:2営業日以内
銀行振込:2営業日以内
企業認証(OV) カード決済:2営業日〜1週間程度
銀行振込:2営業日〜1週間程度
EV認証(EV) カード決済:1週間〜4週間程度
銀行振込:1週間〜4週間程度
99.9%のブラウザに対応とのことですが、具体的には?

以下は対応するPC向けWebブラウザの一例です。
携帯端末の対応状況は「携帯端末の対応について」をご覧ください。

■ COMODO
Microsoft Internet Explorer 5.01 以上
Netscape 4.77 以上
Google Chrome Liteを含むすべてのバージョン
Firefox 1.0 以上
Mozilla 0.6 以上
Konqueror (KDE)
AOL 5 以上
Opera 7.0 以上
Safari 1.2 以上
Camino バージョン1.0以上
Microsoft Windows Mobile/ CE 6.0 以上
NetFront Browser v3.4 以上
RIM Blackberry v4.2.1 以上
KDDI Openwave v6.2.0.12 以上
Opera Mini v3.0
Google Checkout
Sun Java v1.4.1 以上
Safari(iPhone iPod touch) 1.0 以上
Dolphin Brouzer
その他多数

■ JPRS
Windows Internet Explorer 8 以上
Opera 9.5 以上
Firefox 12.0 以上
Firefox ESR 52系
Mac OS X 10.6.7以上
Google Chrome (IEと同様 Windows XP SP3以降となります)

EV SSL規格とはどのような規格ですか

EV(EV) SSL規格はCA/ブラウザフォーラムが策定した、サーバ証明書発行時の審査内容を定めた世界統一規格です。 一般に、サーバ証明書は、認証局が審査の上で発行します。
この審査は、サイトや運営者の実在や、証明書の申請者がサイトに対して正当な権限を有していることの確認が目的です。 従来、この審査内容は認証局や証明書の種類によりまちまちでした。
しかし、これまで、ユーザが、いまアクセスしているサイトのサーバ証明書について、「誰が」「誰に」「どのような基準で」発行したか確認するのには、それなりの知識と手間を必要としました。 そこで、EV SSL規格では、まず、審査基準を統一しました。審査内容は、従来行われていた審査方法と比べてもっとも厳格です。
さらに、WebサイトがEV SSL規格準拠のサーバ証明書で保護されていることが、ブラウザ上で一目で識別できるようになりました(対応ブラウザが必要です)。 厳格な実在審査と、わかりやすい表示により、近年特に問題とされている、サイトの成りすまし、いわゆる「フィッシング詐欺」に対して大きな効果を発揮することが期待されています。 なお、規格の定めるところにより、EV SSL規格準拠のサーバ証明書の発行には、組織の実在性確認のため、公的書類の提出等をお願いすることとなります。 EV SSLは、以下の組織・団体のみが申請できます。個人、個人事業者、任意団体は取得することができません。

▼ 日本に登記のある法人・団体
(一般企業、財団法人、国立大学法人、学校法人、社団法人、組合、相互会社、その他法人などの単位)
中央省庁および国の機関/地方公共団体およびその機関

【参考】
CA/Browser Forum 日本電子認証協議会(JCAF) JCAF: EVCガイドライン日本語版

※ EV SSLは強力な「実在証明」になりますが、依然として「企業の信用保証」にはなりません。これはEVCガイドライン(リンク先は日本語版)にも明記されています(「B.EV証明書の基本概念」>「2.EV証明書の目的」>「(c)除外される目的」)。

EV SSL対応のブラウザにはどんなものがありますか。

2008年11月19日現在、以下のブラウザが対応しています。
・ Internet Explorer 7以降
・ Mozilla Firefox 3以降
・ Opera 9.5以降
・ Google Chrome
・ Safari 3.2以降

▼ 対応ブラウザの動作
・ Internet Explorer
アドレスバーが緑色になる
運営者名の名前住所、証明書を発行した認証局が表示される

・ Mozilla Firefox、Opera
アドレスバーに運営者名を記載した緑色のバーを表示
運営者名をクリックすると、証明書の詳細な情報を表示

・ Google Chrome
アドレスバーに運営者名を緑字で表示
運営者名をクリックすると、証明書の詳細な情報を表示

・ Safari
ブラウザの右上にサイトの運営者名を緑色で表示
運営者名をクリックすると、証明書の詳細な情報を表示

※ もちろん、他のブラウザでも、EV SSLの表示がなされないだけで、SSL通信は問題なく行えます。携帯電話については、2005年以降発売の機種はほぼ通信可能です。

EV SSLは、結局のところ、どんなメリットがあるのでしょうか。

まず、フィッシング詐欺に対する効果が期待されています。EV SSLにより、サイトの運営者名などもブラウザ上で簡単に確認できますので、何者かがお客様のサイトを騙って詐欺行為を働こうとしても見分けやすくするこ とができます。※SSLサイトが実際には別の事業者の運用であった場合などは、効果は薄いかもしれません

また、EV SSLは、SSLサイトの安全・安心や、導入企業のセキュリティ意識の高さをユーザに直接的にアピールします。2010年12月にベリサインが行った意識調査でも、非常に多数の回答者が、EV SSL導入サイトおよび導入企業に高い信頼感、好感度を持っているという結果が出ています。

携帯端末の対応について

▼ 各商品の携帯端末の対応について

■ COMODO
下記URLに詳細な対応状況が記載されています。
https://comodo.jp/support/dtl_51

■ JPRS
下記URLに詳細な対応状況が記載されています。
https://jprs.jp/pubcert/info/mobile/

※ 携帯端末の対応は、同じ会社でも機種により微妙に異なっているのが実情ですが、基本的に、ルート証明書がその端末に採用されているか、によって決まります(EV SSLを除く)。ルート証明書の一覧については、本ページの「どのルート証明書が使われるのか教えてください。」をご覧ください。
※ EV SSL証明書については、色が変わるなどの機能は実装されていないことが多いです。
※ iPhone,iPadは、EV SSL以外の証明書はすべて対応していると考えられます。EV SSLも通信は可能ですが、EV SSLの特徴である、色が変わるなどの機能は実装されていません。

▼ 携帯各社、SSL技術資料
NTT DoCoMo
au
Softbank
WILLCOM

SSLアクセラレータを使用しています。サーバ証明書はひとつでいいのでしょうか。

SSLアクセラレータを使用するなど、Webサーバ複数台で分散処理を行っている場合は、コモンネームがひとつであってもサーバの台数分だけのサーバ証明書が必要です。詳しくはライセンスについてをご覧ください。
なお、お申し込みページでは、一コモンネームにつき10ライセンスまでお申し込み可能です。

待機系サーバにも証明書は必要でしょうか。

障害発生時に備えて予備のサーバを待機させている場合、待機サーバには追加のライセンスは必要ありません。ホットスタンバイであるかコールドスタンバイであるかは問いません。

サーバ証明書が不要になりました。別のドメイン用に切り替えできますか。

できません。
サーバ証明書のコモンネームを変更することができないので、別のドメイン用に流用することはできません。

コモンネームにはどのドメインを指定すればいいのでしょうか。

コモンネームには、実際にサイトへのアクセスに使われるドメイン名をFQDNで指定してください。

たとえば、
https://shop.yourdomain.com/order/
というURLでSSLサイトを運用されるのであれば、
shop.yourdomain.com
がコモンネームになります。

メールサーバ、FTPサーバをSSLで運用される場合も同じです。送信/受信メールサーバ、FTPサーバとしてクライアントソフトに設定するのと同じドメイン名をコモンネームとして指定します。

申請承認メールの配信先は自由に指定できるのでしょうか。

申請承認の手続きは、サーバ証明書の発行審査が目的です。具体的には、
・ サーバ証明書の対象ドメインおよびサイトが実在する。
・ 申請者はそのドメインおよびサイトの所有者であるか管理権限を有している。
ということを確認します。

メーリングリストや会員制サイトの登録時によくある本人確認メールとは目的が根本的に異なり、単に発行者本人かどうかを確認するだけではありません。

メール認証だけで、審査になるのでしょうか。

申請承認メールの配信先メールアドレスは、認証局が指定したアドレスでなければなりません。それは以下のような規則で決められます。
・コモンネームに含まれるドメインのメールアドレスで、認証局が指定するもの(管理者用のメールアドレスとして一般的に使われるものが複数示されます)

■ 承認メールアドレスの表示例
admin@ドメイン名
hostmaster@ドメイン名
postmaster@ドメイン名
administrator@ドメイン名
webmaster@ドメイン名

このようなアドレスでメールを受信できるのは、そのドメインの所有者、または管理権限を有している人物に限られるはずですので、申請者の実在確認に使うことができます。もちろん、実際に、そのドメイン用のメールサーバが立ち上がっていなければなりません。

D-U-N-S Numberとは

D-U-N-S(The Data Universal Numbering System) Numberとは、The Dun & Bradstreet Corporation(D&B社) による世界共通の企業識別コードです。

D-U-N-S Numberの取得について詳しくは(株)東京商工リサーチによる説明をご参照ください。なお、D-U-N-S Numberの取得代行はできません。

D-U-N-S Numberは必須でしょうか。

D-U-N-S Numberがあると審査手続きが軽減されます。

コモンネームを間違えてしまいました。

発行前であれば、速やかにご連絡ください。
いったんお申し込みをキャンセルした上で、改めてお申し込みいただきます。
サーバ証明書の性格上、一度発行されてしまいますと取り消しができません。その場合は改めて新規にお申し込みいただくことになります。ご注意ください。

証明書の種類を間違えて申し込んでしまいました。

発行前であれば、速やかにご連絡ください。
正しい種類で改めてお手続きをさせていただきます(CSRの再提出が必要な場合もあります)。
一度サーバ証明書が発行されてしまいますと、取り消しができません。その場合は改めて新規にお申し込みいただくことになります。ご注意ください。


技術的なQ&A
ブラウザが警告を表示します。

※以下のメッセージ例は、ブラウザにより文言が異なります。

■ 「セキュリティ証明書は信頼する会社から発行されていません」
この警告はサーバ証明書をWebブラウザが検証できなかったということを意味します。 検証できない理由は、ブラウザにインストールされたルート証明書からサーバ証明書まで、証明書のパスがつながらないためです。 (誤解されがちですが、サイトを運営する店舗や会社、また認証局の社会的評価とはまったく関係がありません)
これは以下のいずれかの原因が考えられます。

1.サーバ証明書が、ルート証明書をブラウザに提供している認証機関から発行されていない。
2.サーバ証明書が、ルート証明書とパスのつながる中間証明書を提供している認証機関から発行されていない。
3.サーバの設定の間違い

1. 2. は、特に自分で独自にサーバ証明書を作成された場合(自己認証証明書、俗に「オレオレ証明書」)があてはまります。
1. 2. のどちらにも当てはまらない場合は、サーバ設定の間違いが考えられます。サーバ証明書インストールを参考に、設定方法を確認して下さい。

■ 「セキュリティ証明書の日付は無効です」
証明書の期限が切れているか、まだ有効ではないという事を表しています。 サーバ証明書には有効期限があります。期限が切れる前に、余裕を持って証明書の更新を行ってください。 証明書の更新は、新規発行と同じ要領で、注文フォームからお申し込みいただけます。CSRを作り直す必要があります。 また、SSLサーバの日付、時間が正しくない場合にも、同様の警告が表示されます。サーバの時刻設定を確認してください。

■ 「セキュリティ証明書の名前が無効であるか、またはサイト名と一致しません」
アクセスしたサイトのドメイン名がサーバ証明書に記述されたコモンネームと異なる場合、この警告が表示されます。
たとえばコモンネーム www.yourdomain.com として発行されたSSLサーバ証明書は www.yourdomain.com (https://www.yourdomain.com/)でのみ使用できます。secure.yourdomain.com や yourdomain.com で使う事はできません。
サーバ証明書を申し込まれる際は、CSRに指定するコモンネームにご注意ください。
必ず、実際にサイトへのアクセスに使用する FQDN(Fully Qualified Domain Name) を指定してください。
また、複数のURLで同じSSLページにアクセス可能な場合(IPアドレスでアクセスした、サブドメインが省略可能、など)、コモンネームと異なるURLでアクセスすると同様のエラーになります。SSLページのURLは統一してください。

■ 「セキュリティで保護されている項目と保護されていない項目が含まれています」
SSLで保護されたページに表示されている画像やJavaScript、スタイルシートなどが非SSLの場合、この警告が表示されます。 すべてのファイルをSSLでアクセスする場所に置くようにしてください。SSLであれば、別のドメインであってもかまいません。
また逆に、非SSLのページに、SSLでアクセスされる画像などが含まれていても表示されます。
なお、このページから<a href=”…”>等でリンクされているリンク先URLがSSLか非SSLかは関係がありません。

■ 「検証され信頼できる運営者情報はありません」
Firefox でSSLサイトにアクセスし、ウインドウ右下の鍵マークをクリックして「Webサイトの識別情報」を見ると、多くのSSLサイトでこのメッセージが表示されます。 これは、EV SSL以外のSSLサーバ証明書を使用している場合に表示されます。
もちろんSSLサイトとしては何ら問題はありません。 EV SSL証明書は、厳格な審査とわかりやすい表示から、フィッシング対策に大きな効果が期待されていますので、ショッピングサイト等を運営されている方はぜひ取得をお勧めいたします。

「SNI(Server Name Indication)」 とは何ですか?

SNI拡張は、「名前ベースのバーチャルホスト」で複数のSSL環境を利用出来るようにする技術です。
従来、バーチャルホスト環境でSSLを利用するには「IPベースのバーチャルホスト」でなければなりませんでした。そのため、SSLを利用したいバーチャルホスト毎に独立したIPアドレスを割り当てる必要がありました。
SNI拡張では、1個のIPアドレスを複数のSSLサイトで共有できます。このためIPアドレスの節約やコスト削減につながります。
SNI拡張を利用するためには、サーバとクライアントの双方が対応していなければなりません。2011年6月13日現在、対応しているサーバ・クライアントは以下のとおりです。

■ ブラウザ
Internet Explorer 7以降(Windows Vista以降であること。XPは未対応)
Mozilla Firefox 2.0以降
Opera 8.0以降
Androidデフォルトブラウザ
Opera Mobile 10.1 beta以降
Google Chrome
Google Chrome 6(Windows XP)
Google Chrome 5.0.342.1(OS X 10.5.7以降)
Safari 2.1(Mac OS X 10.5.6以降または Windows Vista 以降)
Apple iOS 4.0以降のMobileSafari
Windows Phone 7以降
※Windows版Safariは未対応です。フィーチャーフォンはほぼ未対応と思われます。

■ サーバ
Apache 2.2.12以降 + mod_ssl + OpenSSL 0.9.8f以降
Nginx + OpenSSL0.9.8f以降
Microsoft IIS 8以降

■ サーバ証明書
すべてのサーバ証明書がSNIで利用可能です。

暗号強度(128ビット/256ビット)とは何を表しているのでしょうか。

SSLでは、公開鍵暗号と共通鍵暗号を組み合わせた「ハイブリッド暗号化」と呼ばれる方式を使用しています。
そして、サーバとクライアント間のデータ通信には、「共通鍵暗号」を使用しています。
暗号強度は、共通鍵暗号の鍵の長さを表します。一般に長いほど安全とされています。128ビット、または256ビットが、現在利用されている暗号強度です。

暗号強度が複数ありますが、実際にはどれが使われるのでしょうか。

どの暗号強度が使われるかは、サーバとクライアントの関係で決まります。場合によっては、128ビットよりも弱い暗号強度になってしまうこともあります。

▼ サーバの暗号強度(Webサーバ : 暗号強度(ビット))
下記に記載の暗号強度のうち、Webブラウザの対応する最高強度が使われます。
Apache + ModSSL : 40/56/128
Apache + ModSSL(openssl 0.9.7以降) : 40/56/128/256
Microsoft IIS 4.0 : 40
Microsoft IIS 4.0 + IE高度暗号化パック : 40/56/128
Microsoft IIS 5.0 : 40/56
Microsoft IIS 5.0 + Windows 2000高度暗号化パック : 40/56/128
Microsoft IIS 6.0 : 40/56/128

ブラウザの暗号強度
「99.9%のブラウザに対応とのことですが、具体的には?」に記載したWebブラウザは、少なくとも128ビットの暗号強度に対応しています。
Apache 2 と Firefoxの組み合わせでは256ビットの暗号強度になります。
40ビット、56ビットの暗号強度は、現在のコンピュータの能力で解読可能であることが判明しており、ほとんど使われません。また、使用はおすすめしません。

どのルート証明書が使われるのか教えてください。

SSL証明書発行企業のWebサイトで公開されていますが、ほとんどのブラウザにインストールされており、改めて用意する必要はありません。

■ GeoTrust
以下ページを参照
https://www.geotrust.com/resources/root-certificates/index.html

■ digicert
以下ページを参照
https://www.digicert.com/digicert-root-certificates.htm

■ COMODO
以下ページを参照
https://comodo.jp/support/codesign/dtl_26

■ JPRS
以下ページを参照
https://jprs.jp/pubcert/info/root/

■ GlobalSign
以下ページを参照
https://jp.globalsign.com/repository/

■ SECOM
以下ページを参照
https://repository.secomtrust.net/SC-Root1/

ページ上部へ戻る