メニュー

アーカイブ

この記事は過去のUPKIイニシアティブに掲載されていたものです
 

FAQ


よくあるご質問を下記にまとめています。掲載されていないご質問等がありましたら、お問合せ先へご連絡ください。
 

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


このページでは以下の質問およびその回答を掲載しています。
  • Q3.1  CSR作成時に特別な規則はありますか。
  • Q3.2  サーバ証明書発行申請を複数枚まとめて申請することはできますか。
  • Q3.3  (VirtualHostやVMwareなどの)仮想サーバを利用している場合、またその他の方法で同一計算機上で複数のサーバを運用している場合、サーバ証明書は(仮想)サーバの数だけ必要ですか。
  • Q3.4  FQDNがIPアドレスの証明書を発行することができますか。
  • Q3.5  サーバの冗長化など、同一FQDNの複数サーバで証明書を利用する場合はどうすればよいですか。
  • Q3.6  旧プロジェクトでサーバ証明書が発行されているサーバに新プロジェクトでサーバ証明書を発行する場合の注意点はありますか。(新プロジェクト向け)
  • Q3.7  RSA 2048bit推奨とありますが、非推奨の1024bitの鍵を使っても大丈夫でしょうか?(新プロジェクト向け)
  • Q3.8  OS X(OS X Server)に付属のCSR作成プログラムでは、本プロジェクトのルールに従ったCSRが作成できないのですが。
 

Q3.1

CSR作成時に特別な規則はありますか。


A.本プロジェクトでは、次のルールに従って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:使用しないでください

※なお、OpenSSLを利用してCSRを作成する場合、該当項目に.(ドット)を入力することで、その項目を省略することができます。
詳細は絵文字:PDFサーバ証明書インストールマニュアルv1.05(pdf)をご参照ください。
 

Q3.2

サーバ証明書発行申請を複数枚まとめて申請することはできますか。


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

新プロジェクト


発行申請TSVファイルの1行がサーバ証明書1枚に対応していますので、複数行からなるTSVファイルを作成してください。
現状では、1つのTSVファイルに最大99件の申請を含めることが可能です。(99件申請した場合、証明書発行までの処理時間はおおよそ30分程度です。)
 

旧プロジェクト


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

Q3.3

(VirtualHostやVMwareなどの)仮想サーバを利用している場合、またその他の方法で同一計算機上で複数のサーバを運用している場合、サーバ証明書は(仮想)サーバの数だけ必要ですか。


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

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

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

Q3.4

FQDNがIPアドレスの証明書を発行することができますか。


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

Q3.5

サーバの冗長化など、同一FQDNの複数サーバで証明書を利用する場合はどうすればよいですか。


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

新プロジェクト


以下の3つの方法いずれかで可能です。
  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と読み替えてください。
 

Q3.6

旧プロジェクトでサーバ証明書が発行されているサーバに新プロジェクトでサーバ証明書を発行する場合の注意点はありますか。(新プロジェクト向け)


A.サーバ証明書は新旧プロジェクトで別の認証局から発行されますので、新プロジェクトでは新規発行として申請を行ってください。
通常の手順では新証明書インストール後に旧証明書の失効を行うことになりますが、2009年9月末10月末に全失効されることに鑑み、旧証明書の失効は不要です。ただし鍵ペアが危殆化(紛失・漏洩等)した場合など急ぎ失効する必要がある場合には、上記に関わらず直ちに失効申請を行っていただくようお願いいたします。

その他の注意事項は以下の通りです。
より詳しく説明した文書を用意しましたので、こちらもご覧ください。⇒解説資料
  1. 中間CA証明書が旧プロジェクトのものと異なりますので置き換えてください。
  2. 旧プロジェクトの証明書の鍵ペアでなく、新しく生成した鍵ペアで申請してください。
  3. CSRに記載するLの値は旧プロジェクトと異なり"Academe2"(L=Academe2)としてください。
  4. OおよびOUに使用できる記号が変更されています。新プロジェクトで現在使用できる記号は以下の6つ10個です。
    括弧"("および")"、ハイフン"-"、ピリオド"."、コロン":"、スペース" "、アポストロフィ「'」、カンマ「,」、スラッシュ「/」、イコール「=」
  5. (IISの場合)Security Communication RootCA1(以下SC-Root1)認証局証明書の再登録が必要です。絵文字:別ウィンドウSC-Root1リポジトリから自己署名証明書をダウンロードし証明書ストアにインポートしてください。
    手順はインストールマニュアルの補足として提供しています。⇒インストールマニュアル

(2009年10月20日更新)
使用可能文字を改修内容に合わせて更新しました。⇒10月8日付け支援システム改修内容
 

Q3.7

RSA 2048bit推奨とありますが、非推奨の1024bitの鍵を使っても大丈夫でしょうか?(新プロジェクト向け)


A.RSA1024bit鍵については近い将来十分な強度を確保できなくなる恐れがある、ということが有識者らによって指摘されており、このため米国連邦政府やEV SSL証明書などにおいては2011年以降はRSA1024bit鍵の使用を制限する、いわゆる「2010年問題」があります。
現時点においてはRSA1024bit鍵もまだ十分な強度を確保できていると認識しておりますので、本プロジェクトでは当面はRSA1024bit鍵についても2048bit鍵と同様25ヶ月の有効期間で証明書発行を行いますが、今後の動向によってはRSA1024bit鍵に関しての取扱いを変更する可能性があります。
このような状況を鑑みて、特段の事情がない限りはできるだけRSA2048bit鍵をご利用いただくことを推奨していますが、現時点では、加入者側の責任でRSA1024bit鍵を利用することを妨げるものではありません。

なお、本プロジェクトにおいて証明書を発行するオープンドメイン認証局2およびその上位のルート認証局SC-Root1は、いずれもRSA2048bit鍵となっています。

(2013年3月21日追記)
本プロジェクトにおける1024bitの証明書の発行は6月末まで、利用期間は11月末までとし、それ以上の有効期間があるものについては強制失効することが決定されました。
【重要】鍵長2048bit未満の証明書の6月末発行停止と年内の失効について
 

Q3.8

OS X(OS X Server)に付属のCSR作成プログラムでは、本プロジェクトのルールに従ったCSRが作成できないのですが。


A.OS Xにはopensslコマンドが標準でインストールされておりますので、インストールマニュアル絵文字:PDFApache 2 + mod_ssl 編の手順に従えばCSRの生成が可能です。