CSRについて

  1. CSR作成時に特別な規則はありますか
  2. サーバ証明書発行申請を複数枚まとめて申請することはできますか
  3. FQDNがIPアドレスの証明書を発行することができますか
  4. (VirtualHostやVMwareなどの)仮想サーバを利用している場合, またその他の方法で同一計算機上で複数のサーバを運用している場合, サーバ証明書は(仮想)サーバの数だけ必要ですか
  5. サーバの冗長化など,同一FQDNの複数サーバで証明書を利用する場合はどうすればよいですか
  6. 旧プロジェクトでサーバ証明書が発行されているサーバに,新サービスでサーバ証明書を発行する場合の注意点はありますか
  7. OS X(OS X Server)に付属のCSR作成プログラムでは,本サービスのルールに従ったCSRが作成できません

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

CSRに関するルールをご覧ください。

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

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

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

IPアドレスでは証明書の発行を行いません。
ドメイン申請書で申請していただいたドメインが対象です。

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

VMwareやXenなど,同一計算機で複数の仮想環境(ゲストOS)を使用している場合

少なくとも仮想環境(ゲストOS)毎に,サーバ証明書の申請が必要です。


 

バーチャルホスト機能など,
同一計算機・同一OSでホスト名が異なる複数のサーバを使用している場合

1枚のサーバ証明書で対応が可能です。
発行申請TSVファイルの「dNSName」の欄に,「利用管理者FQDN」に記入したホスト名以外のホスト名を
「dNSName=xxx2.example.ac.jp,dNSName=xxx3.example.ac.jp」
のように列挙して入力してください。
(各ホスト名の前に「dNSName=」を付けるのを忘れないようにしてください)
証明書上はsubjectAltName拡張にホスト名が記載されます。

 

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

▶︎発行申請TSVファイルフォーマット

 

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

 

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

▶︎情報交換ML:42

 

同一計算機同一ホスト名ながら異なるポート番号で複数のサーバを使用している場合

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

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

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

以下の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を指定する。

 

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

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

OS X(OS X Server)に付属のCSR作成プログラムでは,本サービスのルールに従ったCSRが作成できません

最新のmacOSでは、OpenSSLコマンドの実体として LibreSSL が採用されています。

別途OpenSSLをインストールしてご利用ください。

インストールには、HomeBrew などをお勧めします。