FAQ3 ライセンス・製品仕様詳細および利用時の注意点 |スターフィールドSSL

Q. 「クラウド環境」やロードバランサ上での利用等、マルチサーバ（仮想化や負荷分散環境の同時稼働サーバ）への追加ライセンスが無償？

"コモンネーム数× 同時稼働サーバ台数"と言う、お客様にとって極めて負担感の強いライセンス体系を採用する多くの国内他社とは異なり、一定要件の下で同時稼働サーバへの追加ライセンスは無制限に無償です。

同一コモンネームであれば、ロードバランサ上での利用時や、仮想化や負荷分散環境の同時稼働サーバ（マルチサーバ）台数に対する追加ライセンスは、仮想・物理サーバに関わらず、頂戴しておりません。（無償で追加できます。）

同一サーバにバーチャルホスト環境で複数のコモンネーム及びサイトを運用する場合においても、ワイルドカードライセンスやマルチドメインライセンスをご利用であれば、仮想化や負荷分散環境の同時稼働サーバ（マルチサーバ）台数に対する追加ライセンスは、仮想・物理サーバに関わらず、頂戴しておりません。（同上。）

従って、Windows Azure やAmazon Web Service（AWS）など、サーバ等のハードウェアを始めとしてインターネットインフラを、自ら所有することなく「従量制課金」により必要な分だけ利用できる、「クラウド環境」との親和性は極めて高い、と言えます。

なお、2014年8月にGoogleから公表された「HTTPSをランキングシグナルに使用開始」に伴う、お客様サイトの全ページの常時SSL化も、スターフィールドSSLのマルチサーバ対応により有料ライセンス数を最低限に抑えられますので、極めて安価に実現頂けます。

注意事項: どの程度まで「マルチサーバ」ライセンスを活用するかについては、敢えて同一FQDNの証明書を複数ライセンスご購入頂き「秘密鍵」を分ける、いわばSSLサーバ証明書を「冗長化」する、というリスク管理の合理性に勝るものではないことに十分留意の上、ご判断ください。
特に、数十台を超える大規模サーバ構成においては、ひとたび秘密鍵の危殆化に繋がるサーバの脆弱性が露見した場合に、サーバの洗浄・復旧までの「タイムラグ」を最少化するための合理性ある「ライセンス」数が選択されるべきであろうと考えます。

Q. マルチサーバ（クラウド環境や負荷分散環境の同時稼働サーバ）間での「1枚」の証明書の共用（インストール）方法は？

SSLアクセラレータ（或いはSSLアクセラレータ機能付きロードバランサー）にSSL証明書を搭載できる場合、あるいは同時稼働サーバ（マルチサーバ、仮想・物理サーバに関わらず）間で、同一SSL証明書及び秘密鍵のペアを複製の上、共用できる場合が対象です。

スターフィールドSSLとGo Daddy SSLはTwin Rootであり、まったく同等の方法で設定頂けます。

代表的なサーバソフトウェアでのSSL証明書及び秘密鍵のバックアップ（エクスポート）及び共用を目的としたインポート方法を以下の通りご案内しております。

注意事項: 弊社では、すべてのデバイスに於いて外部環境で生成した秘密鍵のインポート（共用）が出来る、という保証は行なっておりません。外部環境で生成した秘密鍵のインポート（共用）が出来ないデバイスは、本項の対象外となりますのでご注意ください。

同一SSL証明書及び秘密鍵のペアのサーバ間での複製利用の手順については、ジェイサートではサポートしておりません。サーバーソフトウェア毎に異なりますので、その手順の詳細や、サーバの設定等SSL設定については、各機器およびソフトウェアのマニュアルまたは開発元にご確認ください。

同時稼働マルチサーバ間で同一SSL証明書及び秘密鍵のペアを複製利用できない場合、あるいはセキュリティの観点より同時稼働マルチサーバ毎にCSRを個別に生成しSSL証明書を個別に取得される場合には、SSL証明書の枚数分ライセンスのご購入が必要です。

特に、数十台を超える大規模サーバ構成においては、敢えて同一FQDNの証明書を「複数」ライセンスご購入頂き「秘密鍵」を分ける、いわばSSLサーバ証明書を「冗長化」することがリスク管理上合理的です。危殆化が疑われるサーバの洗浄・復旧までの「タイムラグ」を最小限に抑える為にも、迅速に「秘密鍵」を作り直し、証明書を再発行・置換えるための作業時間を想定のうえ、合理性ある「ライセンス」数を判断されることを強くお薦めします。

Q. ワイルドカードライセンス（ワイルドカードSSL）とは？

ベースドメインおよびFQDN全体の階層数が同じであれば、最左端階層のサブドメインは任意に無制限に設定できるマルチドメインに類する証明書です。

注意事項: ただし、ワイルドカード証明書は、証明書ブランドに関わらずフィーチャーフォン（ガラケー）との接続は出来ませんのでご注意ください。

CSRの生成に際し、アスタリスク（）を、任意無制限に設定・選択したいサブドメインに相当する最左端階層に記載する必要があります。例えば、コモンネームを「.jcert.co.jp 」と記載した場合、以下のように4階層目のサブドメインが変化する全てのFQDNがSSL通信の対象となります。

jcert.co.jp（アスタリスク（*）のないドメインも常に暗号化対象です!）
www.jcert.co.jp
www1.jcert.co.jp
www2.jcert.co.jp
xyz.jcert.co.jp 等

注意事項: 上記の事例では、アスタリスク(*)は特定された階層（4階層目）のホスト名を置換えるため、階層構造が異なる「https://www.xyz.jcert.co.jp（5階層）」等は対象外となります。

Q. マルチドメインライセンス（マルチドメインSSL、ユニファイドコミュニケーションSSL）とは？

バーチャルホスト環境や複数物理サーバ上で、全く異なる複数のドメイン名（FQDN）で複数のSSLサイトの運用を行っている場合、1 枚のマルチドメインライセンス証明書で全てのドメイン名に対しSSL通信が可能です。

注意事項: 最大100ドメインまで。ただし、収容可能ドメイン数上限は購入時に固定され、有効期間中の増枠変更は不可であること、および上限枠数の変更ある場合には「更新」ではなく「新規取り直し」となりますのでご注意ください。　なお、選択した付帯ドメイン数上限に達していなくても、上限数未満でのドメイン数での発行は可能です。

例えばマルチドメイン（上限5ドメイン枠 - 基幹ドメイン + 4 付帯ドメイン = 5ドメイン）の場合、

www.jcert.co.jp（基幹ドメイン）
jcert.co.jp（基幹ドメインに対してはシングルドメインライセンスPLUSが適用され、都合5+1=6 ドメインの暗号化が可能です!）
www.jcert.jp（付帯ドメイン1）
jcert.com（付帯ドメイン2）
secure.jcert.biz（付帯ドメイン3）
www.host.jcert.info（付帯ドメイン4）

マルチドメインライセンスPLUS（マルチドメインSSL、ユニフィドコミュニケーションSSL）とは？

SSL通信が可能なドメイン名（FQDN）は、発行された証明書の詳細情報「サブジェクト（発行先）の別名」欄（Subject AltName/SAN Field）においてご確認いただけます。

注意事項: Subject Alt Name Field の有効性については、デジタル証明書の標準仕様（X.509/ITU）に定められており、Google/ChromeやIE を始めFirefox、Opera、Safari 等全ての主要クライアント（iPhone/iPad, Android 等スマートフォン含む）が対応しております。ただし、マルチドメイン証明書は、証明書ブランドに関わらずフィーチャーフォン（ガラケー）との接続は出来ませんのでご注意ください。

マルチドメインの登録方法について

本ライセンスは、EV SSL、デラックス OV SSL（組織認証）、スタンダード DV SSL（ドメイン認証）のいずれのクラスでもご利用頂けます。

マルチドメインSSLは、別名ユニファイドコミュニケーションSSLとも呼ばれ、Microsoft Exchange Server において、VoIPやボイスメール、電子メール等マルチなコミュニケーションの統合プラットフォームのセキュア化にも適応しております。

証明書有効期間中であれば、未使用の付帯ドメインスロットがある限り付帯ドメインの追加や、基幹ドメイン以外の収容済付帯ドメインの入替を、随時無償でお受けします。　お客様管理画面にログインし、「証明書管理」メニューから「再発行」処理により付帯ドメインの異動（追加・入替）処理が可能です。

注意事項: なお、付帯ドメインの入替・追加後の新しいSSL証明書が発行されてから「72時間」経つと、現在利用中のマルチドメインSSL証明書は自動失効（クライアントPC側で接続拒否）されますので、それまでにすべての収容ドメイン名に対しサーバ上での新旧証明書の「置き換え」を完了する必要があります。

IIS/Windows Server において利用中のマルチドメイン証明書の付帯ドメインの入替や追加を行う場合には、OpenSSLを利用して、再発行されたSSL証明書と古い秘密鍵を別途ペアリングする必要がありますのでご注意ください。
詳しくはこちら

Q.1つのIPアドレス上で複数のSSLバーチャルサイトの運用（名前ベースバーチャルホストSSL、SNI）は可能ですか？

はい、Apache, Plesk およびIIS（Ver.6 以降）の各種サーバ上では可能であることを確認しております。（その他サーバソフトウェアでの可否についてはサーバ製造元にご照会ください。）弊社では、クライアントOSでのSNIの可用性が未だ100%近くに達していないとの認識から、SNIによるのではなく、マルチドメイン証明書やワイルドカード証明書を活用することにより、名前ベースバーチャルホストSSL対応とされるようお薦めしております。暗号化するドメイン（バーチャルホスト）毎にI Pアドレスを割り振る必要はありません。

暗号化すべきドメインの形式・パターンにより、ワイルドカードライセンス（任意のサブドメイン）とマルチドメインライセンス（任意のFQDN）をご用意しております。

apache上でのワイルドカード・マルチドメイン証明書による「名前ベース」バーチャルホストSSL設定方法については、こちら（iis用ガイドは弊社までお問い合わせください。）

ジェイサートにお問い合わせはこちら

注意事項SNIはどの程度使える？: Apache（2.2.12以降）やiis8/Windows Server 2012のSNI（Server Name Indication）機能を活用すれば、1つのIPアドレス配下で複数の異なるシングルドメイン証明書での名前ベースSSL対応も可能ですが、クライアント側でドメイン不一致エラーを引き起こす等、XPを始めとする未対応OSが未だ少なからず存在しその汎用性が充分ではないとの判断から、弊社では実質的にSNIと同等以上の効果が期待できる、マルチドメイン証明書やワイルドカード証明書をApache やiis 上で利用されることをお薦めしております。なお、SNIについてのさらなる詳細情報については、こちらをご参照ください。

Q.複数のSSL証明書の有効期限合わせは可能でしょうか？

ジェイサートのライセンス体系においては、複数の証明書を保有するのではなく、複数サイトを「1枚」のワイルドカード証明書（複数のサブドメイン）やマルチドメイン証明書（複数のFQDN）を運用することで、ライセンス費用を安価に抑えられるばかりか、複数の異なる証明書の異なる有効期限を管理する手間をも割愛してくれます。つまり、「有効期限合わせ」などは必要ない、と言えます。

Q.スターフィールドSSLルート証明書のPCクライアント（ブラウザ）への搭載（ストア）状況の確認方法について

マイクロソフト「Windowsルート証明書プログラム」において、PCクライアント（ブラウザ）での各認証局のルート証明書の取り扱いに関して網羅的に解説されておりますので、ぜひご一読ください。

【1】クライアント利用状況に即し、必要最低限の認証局のルート証明書しかストアされないこと。（信頼できる認証局ルート証明書は100を超え、かつ年々増加しており、そのすべてをクライアント端末出荷時にストアすることは現実的ではないため。）
【2】未ストアの認証局のルート証明書については、クライアントが当該認証局の発行したSSL（TLS）サーバ証明書で保護されたサイトに初めてアクセスした時点で瞬時に追加でストアされること。
【3】一旦ストアされたルート証明書は、Microsoft Updateにより逐次自動更新されること。
【4】クライアントがイントラネット等自動更新プログラムが機能しない環境で使用されている場合には、別途マニュアル処理でルート証明書更新パッケージを利用できること。

Q. スターフィールドSSLの暗号強度について

SSL証明書により実現されるセキュリティは次の3つの要素の" 掛算" により強固に担保されています。

スターフィールドSSLの暗号強度について

【1】通信経路の機密性
共通鍵による通信経路の暗号強度によって担保されますが、スターフィールドSSLは TLS1.0/1.1/1.2に対応済であり、128～256bitの世界水準の暗号強度を確保しております。（サーバとブラウザの組合せに依存します。）
【2】通信相手の真正性
公開鍵による署名強度により担保されますが、2011年1月からマイクロソフトにより2048bitかそれ以上の強度をもったルート公開鍵による署名が義務付けられることになりました。スターフィールドSSLでは、2009年1月より、ルート証明書のみならず中間証明書、エンド証明書のいずれにおいても2048bit強度による公開鍵署名を実現済みです。
【3】通信内容の完全性
通信内容をハッシュ化する際に用いられるハッシュ関数の強度によって担保されており、業界標準に影響あるマイクロソフトの先導により、(1) 2011年1月以降ではSHA-1かそれ以上の、(2) 2017年1月以降ではSHA-2かそれ以上の、強度をもったハッシュ関数の利用が義務付けられることになりました。　スターフィールドSSLでは、ルート証明書のみならず中間証明書、エンド証明書のいずれにおいても同標準を満たしております。

Q.対応ブラウザについて

CA Browser Forum（CABF ）に加盟する世界主要ブラウザに対し100％対応済です。

Microsoft Internet Explorer 6(Windows XP SP3)以降
Google Chrome 1.0以降
Mozilla Firefox 1.0.0 以降
Opera Software Opera 9.5以降
Apple Safari 2.0 以降

等

注意事項: Netscape Navigatorについては、2002年にバージョン4.8で新規開発は終了、製造元による保守サポートも2008年に完全に終了しておりますので、動作確認対象ブラウザから除外しております。

その他詳細はこちらをご確認ください
※ 米国Go Daddy Group, Incへ遷移します。

Q.スマートフォン/携帯端末対応について

スマートフォンは100％対応済

注意事項: スマートフォン（スマホ）およびタブレット端末については、iOS,Android OS等主要OSで可用性を常時確保しております。（但し、OSを最新バージョンにUpdateしていることが要件です。また、SHA-2対応を確保するには iOS4/Android2.3以降のバージョンへのUpdateが必要です。）

フィーチャフォン（ガラケー）については限定対応となります。

注意事項: 上記フィーチャーフォンでは、シングルドメイン証明書のみがSSL通信可能です。他社証明書同様、ワイルドカード証明書やマルチドメイン証明書をインストールしたサーバとのSSL通信はできませんのでご注意ください。

Q.メールサーバ対応（POP/SMTP over SSL）

POP およびSMTPいずれのプロトコルにおいても、メールサーバに対応しております。

Q.シングルドメインライセンスとは？

スターフィールドSSLでは、シングルドメイン証明書でありながら、無償でエキストラに1SAN（付帯ドメイン）を付与してマルチドメイン証明書としてご提供しております。（但し、ドメイン認証方法として「Web page認証」を選択される場合　は除きます。）　無償となる付帯ドメインは、申請されたFQDNが左端のサブドメインに”www”を含む場合はそれを除いたFQDNを、”www”を左端のサブドメインとして含まない場合にはそれを加えたFQDNを設定させて頂きます。
（例）
申請FQDN1: www.jcert.co.jp → jcert.co.jp
申請FQDN2: mail.jcert.co.jp → www.mail.jcert.co.jp

本サービスは、証明書の詳細情報「サブジェクト（発行先）の別名」欄（Subject Alt Name Field）を活用して提供されますが、その有効性については、デジタル証明書の標準仕様（X.509/ITU）に定められており、Google ChromeやIEを始めFirefox、Opera、Safari等全ての主要クライアント（iPhone/iPad, Android等スマートフォン含む）が対応しております。

これにより、お客様サイトの"www"を持つFQDNと"www"を持たないFQDNの双方が、1枚の証明書で暗号化されるため、結果として、サイト訪問者によるURLのミスタイプや誤解（URLには"www"が常時必要！?）による「エラー」表示が回避されます。

シングルドメインライセンスのみならず、マルチドメインライセンスの基幹ドメインに対しても適用されます。

（注）2021年12月1日以降、「Web page 認証」を選択された場合、コモンネームドメインにwwwを加えたり、あるいは削除した上で付帯ドメインを無償追加するサービスの利用はできなくなりました。　（例えば、example.com をコモンネームとして申請し、「Web page 認証」によりドメインのコントロールを検証する場合、発行された証明書は www.example.com を付帯ドメインとして無償追加できません。）　wwwを加えたり、あるいは削除した上で付帯ドメインを無償追加されたい場合は、ドメイン認証時、「DNS認証」あるいは「メール認証」を選択してください。

なお、上記は、EV SSL、デラックスSSL（組織認証）、スタンダードSSL（ドメイン認証）いずれのクラスにも適用されます。

Q. クライアント証明書として転用できますか？

仕様上は転用可能ですが、そのサポートはお受けできません。

注意事項: SSLサーバ証明書を、クライアント証明書として転用することは、弊社利用約款では規定していない利用方法となります。パフォーマンスに関しましては弊社は一切保証致しません。

Q. http/2に対応していますか？

はい、sha-2 仕様の全商品がhttp/2 に対応しております。

http/2とは、2009年米Googleによりセッション多重化によるWeb高速化を目的として考案されたプロトコルSPDYを改良したもので、益々リッチ化するWebサイトへのアクセスをより快適にすることを目的とした次世代プロトコルです。

Akamai社が提供するテストサイトにてお客様のブラウザがhttp/2に対応しているか、そして旧来のhttp/1.1に比べそのレイテンシー（接続速度）がどれほど改善されるのか、を評価することが出来ます。

http/2の実装には、クライアント/サーバの双方がhttp/2対応であることが必要です。Google Chrome 40+, Firefox 35+, IE11+ 等主要ブラウザでの対応は進みつつありますが、サーバー側は、apache 2.4.17+、nginx1.9.5+、IIS10/Windows Server 2016等今後の対応進展が期待されております。（2016年10月現在）

注意事項: http/2の利用はGoogle ChromeやMozilla Firefox, Operaによりhttps通信でのみで有効とされていることから、「常時SSL化」は確実に進展して行くものと思われます。

Q. CT（Certificate Transparency）に対応していますか？

はい、従前より対応済のEV SSLに加え、2018年4月11日以降その他のクラス（デラックス OV SSL、スタンダード DV SSL）にも適用を開始しております。

Certificate Transparency（CT）とは、Google社により提唱され同社Chromeに先導的に実装済の、SSL/TLSの信頼性を高めるとされている新たな技術です。

CT対応証明書では、その詳細情報「SCT一覧」（Signed Certificate Timestamp）としてCTログ情報が開示されます。

「SCT一覧」証明書詳細情報として記載

認証局の枠を超え世界中で発行された全てのSSL/TLS証明書の認証証跡（FQDN、発行認証局、発行日時、有効期限等々）を、誰もが参照できる第三者が運営するCTログサーバに登録させる（所謂ホワイトリストとして）ことで、なりすましが疑われる証明書の発行を迅速に捕捉しよう、とするものです。

因みに、CTを実装していないEV SSL/TLS証明書はGoogle Chrome上ではEV扱いされず、アドレスバーが緑に変色しません。他方、現状ドメイン認証（DV）や組織認証（OV）等のその他のクラスの証明書についても、2018年4月30日以降に発行されるあらゆる認証レベルの証明書(新規/更新のみならず再発行も含む)へのCT実装がGoogle Chrome上でのhttps接続の要件となり、未対応の証明書が設定されたサイトでは「Not Secure（安全ではありません！）」との警告が明示されます。（有効期限が2018年4月30日以降であっても、もともとの発行日が2018年4月29日以前であれば一切影響はありません。）

また本要件は、RFC6962としてRFC化されておりますが、FireFox等その他主要ブラウザにおいても実装が進むものと予想されております。

注意事項: 登録された証明書のFQDNは公に対し全て公開されるため、不特定多数に公開していないクローズドなサイト運営には不向きであるとの見方の一部にあるようです。（ID/PWのIDが初めから特定できるとハッキングの可能性は格段に高まる理屈。この用途には、SSL証明書のCTによるFQDNの特定ができないワイルドカードライセンスPLUSが最適であろうと思われます。）

2016年6月1日より、一部有力他社認証局が発行するドメイン認証（DV）や組織認証（OV）等のその他のクラスの証明書へのCT実装が義務化されておりましたが、同措置はあくまでも過去不適切な証明書発行プロセスにより誤発行が確認されている当該認証局に限定した懲罰的措置であり、スターフィールドSSLには適用されておりません。

Q. Twin Root（双子ルート）「W（ダブル）ブランド」オプションとは？

同一仕様・可用性の2つのブランドのSSL（TLS）サーバ証明書のいずれか一方を選択頂き、ご提供するものです。

スターフィールドSSLでは、相互バックアップルート認証局 Go Daddy SSLとW（ダブル）ブランドで、仕様・パフォーマンスとも完全同等の2つのルート証明書（双子ルート）を選択頂けます。

【1】Starfield Root Certificate Authority - G2
【2】Go Daddy Root Certificate Authority - G2

完全に同等の仕様・パフォーマンス

【1】有効期間（2009/9/1 -2038/1/1）
【2】暗号強度（ハッシュ関数SHA2、公開鍵長2048bit）
【3】デバイス対応（サーバ、PC/スマホ、フィーチャフォン（ガラケー））

発行済証明書であっても、有効期間内であれば随時、リキー再発行（無償）によりルート証明書の切替も可能（この場合、それぞれのルート証明書に対応する中間証明書の切替も必要です）。

注意事項: 本オプションは、一方のルート証明書を他のルート証明書のバックアップとして併用することを意図しておりますが、Best Effortベースのサービスであり認証局瑕疵担保責任の対象外となりますので、ご承知おきください。（過去、双方のルート認証局が同時に供用不能に陥ったことは一度たりともありません。）

以下のそれぞれの接続テストサイト（リポジトリ）のいずれか一方にエラー表示なくアクセスできれば、その端末はスターフィールドSSLおよびGo Daddy SSL双方に対応していることが判断できます。

Q. DNS/CAAレコードに対応していますか？

はい、2017年8月17日以降、DNS/CAAレコードの検証機能を米国認証局サイドで実装済です。

DNS Certification Authority Authorization（以下「CAA」）とは、ドメイン名の所有者・管理者が、DNSサーバを用いて、自らが所有・管理するドメイン名に対してSSL/TLS証明書の発行を受け入れる認証局をあらかじめ特定できるようにする仕組みです。

DNSにCAAレコードを新たに追加指定することで、自らが所有・管理するドメイン名に対して、悪意ある第三者が「なりすまし」サイトへの利用を目的に、認証手続きの甘い中間認証局を利用する等により、存在すべきでない証明書が発行されるリスクを低減するものです。

2017年8月17日（米国時間）以降、弊社を介して申請頂いたスターフィールドSSL/TLSサーバ証明書に対しては、米国認証局が当該申請を受領時にお客様のDNSゾーンファイル内のCAAレコードを確認し、下記いずれかの場合に限り、証明書発行プロセスを継続します。 （下記に該当しないレコード登録が確認されました場合には、ご申請をお受け出来ません。）