自己署名証明書ジェネレーター

openssl の呪文を覚えなくても、内部サービス用の証明書とその秘密鍵が作れます。コモンネームを入力し、証明書がカバーすべき名前と IP をすべて列挙し、有効期間と鍵長を選んで、2 つの PEM ファイルをダウンロードしてください。鍵はブラウザ内でローカルに生成され、アップロードされることは決してありません。このページはネットワークリクエストを一切行わず、鍵は保存するまでこのタブの中にだけ存在します。

鍵が大きいほど生成に時間がかかります。4096 ビットは控えめなマシンではしばらくかかることがあります。作業はあなたのマシン、このタブの中で行われます。開いたままにして、終わるのを待ってください。

自己署名証明書は何のためにあるのか

自己署名証明書とは、発行者とサブジェクトが同一の証明書です。自分で自分の保証人になるわけです。それは欠陥に聞こえますし、公開ウェブにとっては実際に欠陥です。訪問者のブラウザには、見知らぬ者の言い分を信じる理由がありません。しかし TLS の大部分は決して公衆に面しません。内部ダッシュボード、ラボやステージング環境、ホームラボのサービス、ネットワーク機器の管理画面、そして 1 つの組織の中でのサービス間通信です。そうした用途では、相手はあなたが管理するマシンであり、信頼の問いには別の答えがあります。証明書（または自分専用の小さな CA）を、あなたが管理する信頼ストアに、一度だけ、意図的にインストールするのです。その代わりに、公的 CA があなたの内部ホスト名 — それ自体があなたのインフラの地図である名前 — を知ることなく、自分の壁の内側で暗号化と本人性が得られます。

生成の儀式はかつて、誰も覚えられず誰もがコピー＆ペーストする openssl コマンドでした。SAN は、古いバージョンにはそのフラグが存在しなかったため、設定ファイル経由で後付けされていました。このページが存在するのは、証明書の形を代わりに目に見えるものにするためです。名前は読めるリストであり、有効期間は失効すると知った上で選ぶ日数であり、鍵長は気付かなかったデフォルトではなく 1 つの決定です。このページが意図的にしないのは、CA のふりをすることです。チェーンはなく、中間証明書もなく、失効させるものもありません。1 つのサービスに 1 つの証明書、把握すべき有効期限は 1 つだけです。

クライアントに受け入れてもらう

証明書を生成するのは簡単な半分であり、信頼こそがデプロイです。自分のマシンが一握りなら、証明書をオペレーティングシステム（またはブラウザ）の信頼ストアに追加すれば警告は永久に消えます。また curl や git のようなツールは、検証を無効化するという危険な習慣ではなく、コマンドごとの --cacert の指定を受け付けます。-k フラグは、本物の攻撃を捕まえるはずのまさにその警告を無視するよう全員を訓練します。相手が一握りのマシンを超えたら、単独の自己署名証明書から小さなプライベート CA へ進んでください。それでサービス証明書に署名し、CA 証明書だけを配布すれば、ローテーションはすべてのクライアントを回る巡回ではなくなります。そしてサービスが結局は公衆に面することになったら、証明書を公的に信頼されるものに置き換えてください。SSL チェッカーは、サーバーが稼働した後に実際に提示するものを検証します。それが自己署名がもはや選択肢でなくなる瞬間です。

関連ツール：SSL 証明書パーサーであらゆる証明書を読み戻したり、SSL チェッカーで稼働中サーバーが提示するものをチェックしたりできます。

さらに読む：1 つの信頼性のルーティン — 内部証明書とその有効期限が、ローテーションやバックアップと同じ計画ページに属する理由。

証明書の生成には node-forge を使用します。BSD-3-Clause ライセンスの下で使用し、「生成」を押したときにのみ読み込まれます。このツールのどの部分もネットワークリクエストを行いません。

よくある質問

自己署名証明書はどこで使うべきですか？

あなたとあなた自身のシステムだけが話すものに使ってください。内部ダッシュボード、ラボとステージング環境、ホームラボのサービス、デバイスの管理ページ、そして本物の証明書が発行される前にサーバーを起動できるようにするプレースホルダーとしてです。ルールは到達範囲です。見知らぬ者のブラウザがいつかそれを見るなら、代わりに公的に信頼される証明書が必要です。それらは Let’s Encrypt で無料です。

ブラウザはなぜ自己署名証明書について警告するのですか？

「自己署名」とは、証明書の保証人がそれ自体だけだという意味だからです。暗号化は機能します — 接続はプライベートです — が、サーバーが自称する通りの者であることは何も証明しません。それは通常、認証局が提供する TLS の半分です。そのため、証明書（またはあなたが管理する CA）がそれを使うマシンの信頼ストアに追加されるまで、ブラウザは警告を出します。

コモンネームが SAN リストにも現れるのはなぜですか？

最新のブラウザはコモンネームフィールドを完全に無視し、代わりにサブジェクト代替名リストを確認するからです。主名が自身の SAN リストに含まれていない証明書は、それが作られたまさにその名前で失敗します — 最もよくある自己署名の間違いです — ので、このページはコモンネームを常に SAN に追加します。

2048 ビット RSA で十分ですか、それとも 4096 を選ぶべきですか？

2048 ビット RSA は現在のベースラインであり、内部サービスには十分です。ほとんどの公開証明書が今も使っているものです。4096 ビットは、生成が遅くなりハンドシェイクがわずかに遅くなる代償と引き換えに、将来の暗号解読に対する余裕を買います。長寿命の内部 CA や、簡単に再発行できないサービスには意味があります。どちらの場合も生成はあなた自身のマシンで行われます。4096 ビットはしばらくかかることがあり、タブは固まっているのではなく動作しています。

ウェブページで秘密鍵を生成しても安全ですか？

このページでは、作り方ゆえに安全です。鍵ペアは node-forge ライブラリを使ってブラウザ内でローカルに生成され、このページはネットワークリクエストを一切行わず、生成したものがアップロード、記録、保存されることはありません。それでも一般的な習慣は保つ価値があります。鍵は信頼するページ（とマシン）でのみ生成し、秘密鍵ファイルは存在した瞬間から秘密として扱ってください。