CloudFront の Viewer mTLS を採用すると決めたあと、残る論点は技術の選定ではない。 秘密鍵をどこで生成し、誰が署名し、配った証明書をどう失効させるかである。 ここを決めないまま始めると、秘密鍵が人の手を渡り歩き、有効期限で黙って止まり、使われていない証明書が台帳に残る。
本稿では、鍵の生成場所の選び方、発行・更新・失効が別の操作であること、 端末への取り込みで実際に詰まる点を整理する。 方式の比較とこの手段を選ぶかどうかは親記事にある。
1. 誰が何を持つか
名前が似ているため、どれを秘密として扱うのかが混ざりやすい。先に分けておく。
CA の秘密鍵を扱える範囲が、この仕組みで最も強い権限になる。 その鍵で署名すれば、任意の Subject の証明書を作れる。 発行の操作を画面に出すかどうかは、この鍵に触れる範囲を広げないことと引き換えに決める。
2. 秘密鍵をどこで生成するか
ブラウザ内で鍵を生成する keygen 要素は、現在の HTML 規格では使ってはならない機能として扱われている。
証明書の登録用途には Web Cryptography API で鍵の組を生成し、利用者が手で取り込む形が案内されている。
ブラウザ方式を採るなら、その画面を自分で実装することになる。
サーバーで生成する方式は、サーバーが一度は秘密鍵を保持する。 PKCS#12 をその場でダウンロードさせる仕組みはこの方式である。 生成後に保存しない運用にはできるが、「保持していない」ことを設計で示すのは難しい。
3. CSR を受け取る構成
対象が社内の運用担当という限られた相手のため、端末で鍵を生成する方式を採った。 秘密鍵は端末から出ず、画面と台帳を通るのは CSR と証明書だけになる。
4. 発行・更新・失効は別の操作である
運用でつまずくのは、次の3つが別物だからである。画面の作りでも、ここを分けて見せる。
有効期限も、台帳の状態とは別に扱う。 失効させていなくても期限を過ぎた証明書は通らないため、状態の値ではなく notAfter から導く。
失効を効かせる仕組みは、別に用意する必要がある。 CloudFront は Trust Store に対して証明書を検証するが、失効したかどうかの確認は組み込みではない。 失効させた通し番号を保持し、接続時に動く関数が照合する構成が案内されている。 つまり「失効させる」という操作には、台帳への記録だけでなく照合先への反映までが含まれる。
5. 端末への取り込み
秘密鍵と証明書をまとめた PKCS#12 を作れるのは、秘密鍵を持っている側だけである。 秘密鍵を受け取らない構成では、画面でこのファイルを作れない。利用者が自分の端末で作る。
まとめるときの暗号方式には注意が要る。 新しい版の OpenSSL が既定で使う方式（PBES2 / AES-256-CBC、MAC は SHA-256）でまとめたファイルは、 macOS のキーチェーンが取り込めなかった（2026-10 に確認）。古い方式を明示するとそのまま取り込めた。
# 端末の中で、秘密鍵・証明書・CA 証明書をまとめる。
|
# 取り込み先が新しい暗号方式を扱えない場合は、古い方式を明示する。
|
openssl pkcs12 -export \
|
-inkey private-key.pem -in certificate.pem -certfile ca.pem \
|
-keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -macalg sha1 \
|
-out bundle.p12 |
取り込みの手順は画面に書いておく。 証明書の配布は年に数回しか起きないため、手順は必ず忘れられる。
6. 証明書は端末までしか示さない
接続してきた証明書の情報（通し番号、発行者、Subject、有効期間）は、ヘッダーとしてオリジンへ渡せる。 ただしオリジンリクエストポリシーに明示的に挙げる必要があり、他の目的で必要なヘッダーと設定が両立しないことがある。 アプリケーションが接続元の証明書を参照する構成にするかは、この手当てを含めて決める。
渡したとしても、証明書が示すのは端末までである。 誰であるかは利用者の認証が決める。 親記事の軸でいえば、クライアント証明書は到達範囲だけを受け持ち、本人性は別に決める。
本人性を前段に置かない構成も採れる。 その場合、前段は端末だけを確かめ、誰が操作しているかはアプリケーション側で確かめることになる。 証明書だけで接続してきた相手に対して、画面は返るがデータは返らない、という状態もこの形である。
7. 増える運用
端末ごとの台帳と、これらの出し方は操作できる画面に置いた。
アクセス制限の切り替え（運用画面例。AWSに接続しないモック）
8. まとめ
クライアント証明書は認証を強くする道具ではなく、接続元の端末を限定する道具である。 限定した結果として増える運用（有効期限・配布・失効）を引き受ける場所を決めてから採用する。