FAQ-3. サーバ証明書発行申請について（CSRの作成方法）

Ａ．本プロジェクトでは、次のルールに従ってCSRを作成することになっております。新旧プロジェクトで一部異なります。

新プロジェクト

こちらのページをご覧ください。⇒CSRに関するルール

旧プロジェクト

• Country Name（C）：「JPと入力」
• State or Province Name（ST）：使用しないでください
• Locality Name（L）：「Academeと入力」
• Organization Name（O）：「機関名」を記入（登録担当者が申請した機関名（英語表記）をご利用ください）
• Organizational Unit Name（OU）：証明書を使用する「部門名」又は「グループ名」を記入（省略可）
• Common Name（CN）：「サーバ名」（SSL/TLSでアクセスする際のFQDN）を記入
• Email Address：使用しないでください

Ａ．申請方法は新旧プロジェクトで異なります。

旧プロジェクト

サーバ証明書発行申請書を事務局に提出する際に、サーバ証明書発行申請書（登録担当者記入用）と複数のサーバ証明書発行申請書（加入者記入用）を、一つのExcelファイルの別々のシートに保存することで申請が可能です。

●VMwareやXenなど同一計算機で複数の仮想環境(ゲストOS)を使用している場合
Ａ．少なくとも仮想環境(ゲストOS)毎に，サーバ証明書の申請が必要です。

●バーチャルホスト機能など同一計算機同一OSでホスト名が異なる複数のサーバを使用している場合
Ａ．1枚のサーバ証明書で対応が可能です。新旧プロジェクトで申請方法が異なります。

新プロジェクト

発行申請TSVファイルの「dNSName」の欄に、「加入者FQDN」に記入したホスト名以外のホスト名を「dNSName=xxx2.example.ac.jp,dNSName=xxx3.example.ac.jp」のように列挙して入力してください。（各ホスト名の前に「dNSName=」を付けるのを忘れないようにしてください）
証明書上は、旧プロジェクトと同じくsubjectAltName拡張にホスト名が記載されます。

その他、dNSName欄に関する制約は発行申請TSVファイルフォーマットをご参照ください。
⇒発行申請TSVファイルフォーマット

(2009年9月10日追記)
上記の通り、CSRには追加ホスト名について何ら記載する必要はありません。
また、証明書に記載できるホスト名は合計8件まで（加入者FQDNを除いて7件）となっておりますのでご注意ください。記載できる文字数にも上限があります。

(2010年4月23日追記)
この方法で追加されたホスト名に携帯電話・スマートフォンでアクセスした場合、一部機種では警告が表示されることが確認されております。詳しくは情報交換ML:42以降の報告をご参照ください。⇒情報交換ML:42

旧プロジェクト

証明書発行申請書のsubjectAltName項目を利用することにより，1枚のサーバ証明書で申請することができます。詳しくはsubjectAltName申請手続き（pdf）をご覧ください。

●同一計算機同一ホスト名ながら異なるポート番号で複数のサーバを使用している場合
(例えば80番ポートで動作するWebサーバと8000番ポートで動作するSSL-VPNサーバなど)
Ａ．どちらも同じサーバ管理者の責任下で運用されていることになりますので、サーバ証明書は1つで構いません。ただし、サーバ秘密鍵が漏洩しないようサーバ管理者の責任の下、厳格に管理することが前提です。
特に、各サーバで異なるパスに秘密鍵を保管する場合には、秘密鍵ファイルのアクセス権の設定などに十分ご注意ください。
(例えばどちらか一方の秘密鍵ファイルだけでも管理者・サーバプロセス以外が読み取れる設定などになっていると秘密鍵が漏洩する可能性があります)。

同一FQDNであっても冗長化構成などによって物理的に異なる複数のサーバを利用する場合には、Q3.5も参照ください。

Ａ．IPアドレスでは証明書の発行を行いません。
プロジェクト参加申請時に提出していただいた、ac.jpドメイン、又は各組織の主たるドメインが対象です。

Ａ．方法は新旧プロジェクトで異なります。

新プロジェクト

1. 新プロジェクトでは、同一FQDNであれば、発行された1枚のサーバ証明書を、必要とする複数の機器にコピーしてご利用いただくことができます。これは、同一FQDNのサーバを使用するケースの多くは負荷分散のためであり、負荷分散装置配下に並列設置されるサーバの鍵ペア漏洩リスクは同等とみなせるためです。
   従って、同一FQDNのサーバであるものの、設置場所が異なるなど鍵ペア漏洩リスクが異なる場合には、下記2,3の方法で対応いただくことを推奨します。
2. サーバ毎にCSRを作成し、各サーバに証明書を発行する方法でも対応可能です。
   次の点に留意して、CSRを作成してください。
   1) Common Name（コモンネーム, CN）は同一にする。
   2) Organizational Unit Name（組織部門, OU）は、最後に1、2、3等の数字をつけた名称とする等、各サーバ毎に名称を変更する。
   ※これは証明書を一意にするために行っていただくものです。
3. 2と同様ですが、各サーバに個別のFQDNも割り当てられている場合下記の方法でも対応可能です。
   次の点に留意して、CSRを作成してください。
   1) Common Name（コモンネーム, CN）は個別のFQDNにする。
   2) Organizational Unit Name（組織部門, OU）は、各サーバで同一で結構です。
   3) dNSNameに共通のFQDNを指定する。
   ※この方法では一部の携帯電話・スマートフォンで警告が表示されることが確認されております。携帯電話からのアクセスを想定している場合は他の方法をお使いください。
   不具合についての詳細はこちら⇒情報交換ML:42以降

旧プロジェクト

旧プロジェクトでは上記新プロジェクトでの方法のうち2と3が可能です。ただし3につきましてはdNSNameの部分をsubjectAltNameと読み替えてください。