テスト用認証局の設定

主に openssl を用いた、テスト用の認証局設定

方針

命名規則

• 認証局(CA)のコモンネーム(CN)には世代を識別するための番号をつけ運用期間全体を通して一意にする

構成

ルート-中間の2階層とし、以下のように役割を設定する:

• selfsign-ca-n
  • n 代目ルート（おれおれ）CA
• server-n
  • n 代目サーバ証明書用中間CA
• client-ca-n
  • n 代目クライアント証明書用中間CA
• enterprise-ca-n
  • n 代目エンタープライズCA(中間＝下位CA)
• proxy-ca-n
  • n 代目プロクシサーバ用CA
• choroi-ca-n
  • n 代目どのようなCRLにも署名するCA。有効期間も指定可能

CAはホストca1, ca2 に対して次のように配置する:

• ca1
  • linux/openssl
  • enterprise-ca-n 以外
• ca2
  • windows/エンタープライズ CA
  • enterprise-ca-n

ここでは openssl 中心の構成としたが、次のような選択肢もある:

• Windows とその他(openssl)で独立したPKIにする
  • ルートCAが複数できて少々格好悪い気がするが、SIer 的な正しさも感じる
• Windows の CA で統一する
  • 証明書テンプレートの扱いに慣れれば可能だが、.ini から CSR を作成するところで openssl の知識が前提になる気がする

有効期間

• CAの存続期間は4年とする
  • choroi-ca と proxy-ca で発行する CA 証明書は除く
• エンドエンティティ(サーバ・クライアント)の証明書の有効期間について、以下の通りとする
  • 申請日より前の新CAの開局日を起点とする。2016/1/1 00:00:00 開設で 2017/3/1 00:00:00 申請の場合、起点は 2017/1/1 00:00:00
  • 起点より2年間または新CAの閉局時刻の先に訪れるほうを終点とする
  • つまり
    • 申請月日で有効期間に1年～2年の幅がでる
    • 上位CAより先の期限をもつ証明書は発行しない

世代管理

• 2年ごとに次世代CAを開局する。2年間は新旧のCAを併存させ、順次いれかえていく
  • ルート証明書の期限切れがサービスに与える影響を抑える
  • 次の要素のバランスをとるという観点で設定
    • 暗号・ハッシュアルゴリズムの危殆化リスク(短いほど低い)
    • 運用の習熟度(短いほど高い)
    • 運用・ユーザの対応負荷(短いほど高い)
• エンドエンティティに対する想定
  • 複数(ここでは2種)のルート証明書を設定できる
  • 4年程度のうちにエンドユーザ端末は代替わりし、証明書のインストールは初期設定時時のみで済む
    • あるいはルート証明書の配付機構がある(ADに参加しているとか)

クロスルート

2年ごとの新CA開設時に以下の対応を行う

• 旧ルートCAで新中間CAを署名し(NewWithOld証明書)、各サーバから配布するよう証明書チェインを構成する

  • 新CA開設以降の証明書は新CAから発行されることになるが、クロスルート証明書により既存端末のルート証明書更新は不要になる

• NewWithOld証明書の運用に加えて、を運用すればCA証明書の期限をまたいだサーバ証明書を発行・運用できるが、サーバ毎に証明書の期限が異なると運用が面倒なのでやらない

  • これにより証明書の期限は最短2年になる

• 中間CAを新ルートCAで署名し(OldWithNew 証明書)、各サーバから配布するよう証明書チェインを構成する

  • 新世代の端末に旧世代の証明書をインストールする必要がない

• サーバ証明書を新世代の中間認証局で再署名しても、旧世代の端末はルート証明書のインストール等は(旧世代CAの期限切れまで)必要ない

• 中間認証局証明書の危殆化が問題になる場合は更新が必要になる

• 実際のクロスルート証明書は以下のようなケースでしか利用されない

• ハードウェアの問題から既存端末のルート証明書は更新できないが、危殆化などの問題から新規端末のルート証明書は更新したい場合

失効（CRL）

サーバ証明書ではCRLの設定は案外適当でも問題は発生しづらいが、Windows の認証ではチェックされるため設計しておく

• Active Directory ドメイン内での利用に限らないため、(ldap://やfile://ではなく) http:// で失効を確認できるようにしておく
• OCSP は使用しない
• 失効の理由は深く考えない
  • onlyContainsUserCerts, onlyContainsCACerts, onlySomeReasons はつけない
• 差分CRLは基本的には扱わない
  • エンタープライズCAのようにデフォルトで生成されてしまうなら仕方ない

CRL 配布点

以下のURLで各エンドエンティティからCRLを参照可能にする。

• http://crldp/

  • selfsign-ca-n.crl
  • server-n.crl
  • client-ca-n.crl
  • enterprise-ca-n.crl
  • enterprise-ca-n+.crl
  • proxy-ca-n.crl
  • choroi-ca-n.crl

• CAで生成したCRLが簡単にコピーできる場所に配置すること

  • 静的ファイルなので hosts ファイルなどでやりくりできるなら異なるIPをもったウェブサーバでホストしてもよいが、この点で面倒になるかもしれない

• mime 的観点で拡張子は(pem などではなく)crl とする

• enterprise-ca-n-+.crl はエンタープライズCRLがデフォルトで生成する差分CRLを指している。Windows/IIS にCRL配布点を置く場合は次のどちらかで対応しておく

  • • を含んだファイル名にアクセスできるウェブサーバを設定する(IISは設定が必要)
  • 問題の起きない文字を使って生成するようエンタープライズCAを設定しておく

AIA

ついでに AIA も以下のような場所に配置するものとする(aia=crldpにする)。エラーになったりする機器がなければ気にしなくて良いかもしれない。

• http://aia/
  • selfsign-ca-n.cer
  • server-n.cer
  • client-ca-n.cer
  • enterprise-ca-n.cer
  • proxy-ca-n.cer
  • choroi-ca-n.cer

秘密鍵管理

• client-ca-n, choroi-ca-n では秘密鍵を保存せず、CSRを申請者から受領・署名・証明書発行する普通のCAとする
• その他のCAはCSR・秘密鍵生成・証明書をその場で(同一組織で)行う。バックアップのため秘密鍵はそのまま保存する

セルフサービス

• client-ca-n, choroi-ca-n は SAN にメールアドレスを加えた CSR を送ると即署名して送り返すとか、なんかそんな感じにする

サーバ証明書

• 管理インタフェースなど、TLS/SSLを使用している(デフォルトで自己証明書を用いるていたりする)機器に対しては原則サーバ証明書を発行して運用する
  • letsencrypt したいのはここなんだよなぁ
  • ユーザに製品デフォルトの自己証明書をインポートさせたり、ブラウザの警告を毎回無視させる運用を避ける

クライアント証明書

エンタープライズCAでスマートカード(PIV)対応できるように x.503 拡張設定を入れる

プロクシサーバ(CA)証明書

通常のウェブサーバやロードバランサはサーバ証明書と中間証明書を単に連結したファイルをサーバ証明書として設定することで、クライアント側で証明書チェーンを確認できるよう取り計らってくれるが、製品によっては中間証明書を扱うことができない場合がある。ルートCAから直接生成するはめになったりするので対象プロダクトの仕様を確認すること。

エンタープライズCA証明書

...代替わりできるのかな?