CSR単独では登録ではない：VPN CAが確認すべきこと

証明書署名要求には公開鍵と要求されたsubjectが含まれ、対応する秘密鍵で署名されています。その署名は、要求者が鍵を所持していることを証明します。要求された名前、デバイス、VPNロールへの権利があることは証明せず、それを証明しているかのように扱うことが、ヘルプデスクのチケットをアクセス許可に変えてしまう原因です。

二つの登録モデルは、どのプロトコルを話すかではなく、何を結びつけるかで比較する価値があります。

要求は名前を主張するが、証明はしない

要求を、実際に含まれているものとして読んでください。公開鍵、要求者が選んだsubject、そして両者に対する自己署名です。その構造には、あなたの台帳、アカウントディレクトリ、承認ワークフローを参照するものは何もありません。cn=finance-laptopのようなsubjectは、誰かが入力した文字列です。発行プロセスがその文字列を信頼する記録と照合するまで、証明書は署名が添えられた主張にすぎず、この区別こそが登録プロセスが存在する理由そのものです。

その帰結は運用上重要です。認証局が証明書を発行するのにクライアントの秘密鍵を必要とすることは決してなく、それを求めるワークフローは署名と鍵預託を混同しています。生成はエンドポイント側に置き、公開側だけを送ってください。

何を結びつけるかでモデルを比較する

手動署名は、運用者が確認しようと覚えているものだけを結びつけます。自動登録サービスは、認証された要求をサービスが強制できる判断に結びつけ、RFC 7030は、証明書が返される前にクライアントが認証する設計の一つを説明しています。監査を生き残る違いは自動化ではなく、本人確認が発行経路の内側で行われるか、その横で行われるかです。

どちらのモデルも、同じ三つの問いに答える必要があります。誰が、どのデバイスまたはロールで、どのくらいの期間か。答えを記録するチケットシステムは実際の仕事をしていますが、誰かがコモンネームを眺めるだけの行列はそうではなく、後で証明書がどれほど丁寧に整形されても同じです。

モデルは、想定する登録件数とデバイスの入れ替わりで選びます。年に数台のサーバーなら、書面のチェックリストによる手動レビューで足ります。ノートPCの群れには足りません。

最初の発行からライフサイクルを記録する

発行の時点で、証明書の識別子、所有者、意図した用途、有効期限、削除経路を保存し、最初のインシデントのときまで待たないでください。意図した用途は拡張鍵用途によって証明書自体に入れるべきで、記録もそれと一致すべきです。クライアント認証用に発行した証明書が、サーバー用の証明書と区別できないものであってはなりません。

十番目のプロファイルを発行する前に、更新と紛失デバイスの失効を計画してください。部署全体で共有された証明書は、標的を絞った削除を停止に変え、その判断は、金曜日のインシデントの最中より今のほうがはるかに安く見直せます。

発行された証明書を確認し、次にアクセスを確かめる

登録後、何が発行されたかを確認し、想定した認証局につながることを確かめてください。二つのコマンドがよくある誤り、つまり用途が誤った証明書と、クライアントが検証を無視する設定になっているためにだけ機能するチェーンを押さえます。

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

次に、成果物ではなくアクセスを試してください。証明書は身元を確立しますが、その身元がどのサービスに届くかはポリシーが決めます。両方を確認してください。正しい成果物でもポリシーが広すぎればレビューに落ちます。クライアントが認証し、意図したルートやリソースだけを受け取り、観察したことを記録して、プロファイルがすべきだったことを書かないでください。

誤った理由で機能するプロファイル、たとえば一致するコモンネームと本人確認がないだけのものは、あると思っていた統制が外された後も機能し続けます。