CSRジェネレーター

生成されるもの

2つのPEMファイル：

example.csr（公開、CAへ送る）：

-----BEGIN CERTIFICATE REQUEST-----
MIIC...
-----END CERTIFICATE REQUEST-----

example.key（秘密、サーバーに残す）：

-----BEGIN PRIVATE KEY-----
MIIE...
-----END PRIVATE KEY-----

CSRは保持の証明として秘密鍵で署名されます。CAが証明書を発行するとき、証明書の公開鍵はCSR内の鍵と一致し、それはサーバー上の秘密鍵と一致します。

このジェネレーターは、入力したコモンネームのみを含み、サブジェクト代替名（SAN）拡張のないCSRを作成します。証明書が複数のホスト名をカバーする必要がある場合は、認証局のツールを使用してください：Let’s EncryptなどのACMEクライアントはリクエストを自動で作成し、多くのCAのWebフォームは提出時に追加の名前を補います。

証明書の種類ごとのフィールド要件

Let’s Encryptとほとんどの自動DV発行者はコモンネームのみを確認します。OV/EV証明書を発行する企業のCAは、組織の詳細を事業記録と照合して検証します。

鍵のサイズの選択

公開Webサーバーには、RSA 2048が安全な既定です。より大きなセキュリティの余裕が欲しく、遅い鍵生成とハンドシェイク、大きな証明書を受け入れられるなら、3072または4096ビットを選んでください。

CSRが間違いやすいところ

• 証明書がホスト名をカバーしていない：証明書が訪問した正確な名前をカバーしていないと、ブラウザは「NET::ERR_CERT_COMMON_NAME_INVALID」とエラーになります。コモンネームはwwwを含む完全なホスト名と一致させる必要があります。このジェネレーターはCNのみの要求を作成するため、追加の名前が必要な場合は認証局のツールを使用してください。
• ワイルドカードの制限：ワイルドカード*.example.comはサブドメインの1階層のみに一致します。api.v2.example.comには一致しません。
• 頂点とワイルドカードは別の名前：*.example.comは裸のexample.comをカバーしません。証明書には両方を別々の名前として含める必要があります。
• IPアドレス：ほとんどの公開CAはIPアドレスの証明書をもう発行しません。ホスト名を使う必要があります。

生成後

1. 秘密鍵を安全に保ちます。パーミッション0600、Webサーバーのユーザーが所有。
2. CSRをCAのWebフォームまたはCLIツールに貼り付けます（ACME経由のLet’s Encryptは通常これを自動で処理します）。
3. 署名された証明書（と中間チェーン）を受け取ります。
4. 証明書チェーンと秘密鍵の両方をサーバーにインストールします。
5. SSLチェッカーで検証します。