CSR 作成ツール

証明書署名要求と、対になる秘密鍵を、このページで作成できます。鍵ペアはお使いのブラウザー自身の Web Crypto が生成し、コンピューターの外には出ません。入力した内容も鍵も、当サイトのサーバーを含め、どこにも送信されません。

RSA 2048/3072/4096 · ECDSA P-256/P-384/P-521 · Ed25519 · ブラウザー内で Web Crypto が作成、アップロードなし
鍵の種類

迷ったらこれです。強度は RSA 3072 と同じで、サイズははるかに小さくなります。

証明書の発行先ほとんどの証明書では省略できます

登記されている、組織の正式名称を入力してください。

略さず、正式な名称で入力してください。

2文字のISO 3166-1コードです。

要求する内容公的CAは独自のプロファイルから設定します。プライベートCAでは、要求が必要な場合があります。
鍵用途
拡張鍵用途

CAから求められた場合のみ入力してください。SCEP の登録で使われ、Web証明書の注文では使いません。

鍵ペアはお使いのブラウザーが作り、どこにも送られません。

送るファイル証明書署名要求ボタンを押すと、このブラウザー内で作成されます
保管するファイル秘密鍵ボタンを押すと、このブラウザー内で作成されます

送信しようとしている内容ECDSA P-256 · SHA-256

ECDSA P-256ボタンを押すと、このブラウザー内で作成されます
認証局がこの要求をどう扱うか

名前を入力するかサンプルを試すと、この列に、作成する前の段階で、認証局がこの要求をどう扱うかが表示されます。

鍵ペアは、お使いのブラウザーの Web Crypto が、どこにも接続できないフレーム内で作成し、送信されることはありません。ネットワークパネルを開いて確かめてください。

CSR ジェネレーターとは何ですか

2つのファイルを作るツールです。認証局に送る証明書署名要求(CSR)と、手元に残す秘密鍵です。要求には、公開鍵と証明してほしい名前が入っており、秘密鍵で署名されています。

形式は PKCS#10 で、RFC 2986 に定められています。要求の中には、サブジェクト名、公開鍵、代替名を運ぶ属性の集まり、そしてそれら全体に秘密鍵で付けた署名が入っています。この自己署名が所有の証明になります。証明書の発行対象となる鍵を、送信者が持っていることを示すものです。

2つのファイルは同じ扱いではありません。要求は送るためのファイルで、CAに送っても、サポートへの問い合わせに添えても構いません。秘密鍵は、どんな場合も送ってはいけません。このページでは、鍵はブラウザー内で作られ、ブラウザー内に留まります。Webツールの常として、ページのコードを信頼する必要はありますが、何を送信しているかは確認できます。生成しながらネットワークパネルを開いて確かめてください。

一緒に作られる2つのファイルRFC 2986 · PKCS #8

秘密鍵保管するファイル

-----BEGIN PRIVATE KEY-----
  • 秘密の半分いまは要求に署名し、のちにサーバーへのすべての接続に署名します
  • その公開の半分要求にコピーされます

コピーは1つだけ、お手元のコンピューターに

証明書署名要求送るファイル

-----BEGIN CERTIFICATE REQUEST-----
  1. サブジェクト名108バイトほとんどの証明書では省略できます
  2. 公開鍵294バイト認証局が確実に使う唯一のフィールドです
  3. 要求した名前60バイト代替名が属性として運ばれます
  4. 署名261バイト秘密鍵が、上のすべてに対して作ります

秘密は含まれません

実際の要求で、サイズは 749バイト です。隣には、それを作った鍵があります。外に出す必要があるのは要求だけで、その中には鍵の公開の半分と、秘密の半分にしか作れない署名が入っています。
CSR 作成ツールの画面:サブジェクトの項目、代替名、鍵の種類と、完成した証明書署名要求および秘密鍵のファイルを表示CSR 作成ツールの画面:サブジェクトの項目、代替名、鍵の種類と、完成した証明書署名要求および秘密鍵のファイルを表示名前証明書の対象にするホスト名です。最初の名前が共通名になり、残りがそれに加わります。鍵RSA または楕円曲線です。鍵ペアは、目の前でお使いのブラウザーが作ります。発行先サブジェクトの項目です。公的CAはこれらを自分で検証するため、残るのはごく一部です。2つのファイル送る要求と、保管する秘密鍵です。鍵は、保存するまでお使いのブラウザーの中にしか存在しません。同じ内容をコマンドでこの要求とまったく同じものを作る OpenSSL の1行です。自分で作りたい場合に使えます。
要求を作成しているところです。名前、鍵の種類、そして出力される2つのファイルを表示します。番号を選ぶと、各部分に何が表示されているかを確認できます。

なぜ鍵をブラウザー内で作るのですか

他人のサーバーに届いた秘密鍵は、そのサーバーがあとで何をしようと、業界自身の定義で「漏えいした鍵」に当たるからです。

CA/Browser Forum の Baseline Requirements は、議論の余地なくこう定義しています。「A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it.」悪用は必要ありません。届いただけで該当します。

これは理論上の話ではありません。2020年に DigiCert は、顧客が要求と一緒に貼り付けた337個の秘密鍵を見つけ、関係するすべての証明書を失効させて、公表しました。「by sending the private key to DigiCert along with the CSR, the customer has compromised the private key」と述べ、さらに「the only part of a CSR we use is the public key」と付け加えています。自分のサーバーで鍵を作り、そのコピーを渡すジェネレーターは、この定義に照らせば、すでに鍵を漏えいさせています。このページはそうなりません。crypto.subtle.generateKey はお使いのブラウザー内の、どこにも接続できないサンドボックス化されたフレームで動き、その外側のページが目にするのは公開鍵だけです。

秘密鍵が作られる場所CA/Browser Forum TLS BR 2.3.1

このページ

お使いのブラウザー
  1. Web Crypto が鍵ペアを作る crypto.subtle.generateKey
  2. 鍵が要求に署名する
  3. 2つのファイルを保存する
この線を越えるものはありません
他人のサーバー

鍵は、お使いのコンピューターの中にしか存在したことがありません

サーバーで鍵を作るジェネレーター

お使いのブラウザー
  1. 名前と詳細がサーバーに送られる
秘密鍵がこの線を越えます
他人のサーバー
  1. サーバーが鍵ペアを作る
  2. 秘密鍵があなたに送り返される

何かをインストールする前から、定義上、漏えいしています

「A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it.」

認証局が自分たち自身のために書いた定義

すでに起きています2020年、ある認証局が、要求と一緒に送られてきた秘密鍵を337個見つけました関係するすべての証明書が失効されました

違いは鍵の作り方ではなく、作る場所です。他人のサーバーにあった鍵は、そのサーバーがあとで何をしようと、業界自身の定義ではすでに漏えいした鍵に当たります。

CSR を作成する方法

ホスト名を入力し、鍵の種類を選んで、ボタンを押してください。ほかはすべて任意です。最近の証明書は、サブジェクトではなく代替名で識別されます。

証明書の対象にする名前を、すべて名前の欄に入力してください。example.com、www.example.com、*.api.example.com のようなワイルドカード、IPアドレスなどです。最初の名前は共通名にもなります。Baseline Requirements は、共通名を含める場合、代替名のいずれかとまったく同じにすることを求めています。

国、組織、市区町村が意味を持つのは、組織認証(OV)またはEV証明書だけで、その場合もCA自身が検証してからでないと証明書には載りません。Let's Encrypt が発行するようなドメイン認証の証明書で、規則が認めるサブジェクトの項目は、国と共通名だけです。公的CAが削除または禁止する2つの項目、組織単位とメールアドレスには、ジェネレーターが印を付け、フォームの横の列に、何が変わるかを表示します。

名前から2つのファイルまで/csr-generator
  1. 名前を入力する

    証明書の対象にするすべてのホスト。最初の名前が共通名になります
  2. 鍵の種類を選ぶ

    古いものが読む必要がなければ P-256
  3. 要求を作成

    ブラウザーが鍵を作り、それで要求に署名します
  4. 2つのファイルを受け取る

    要求は認証局に送り、鍵は保管します
このページが行う作業の全体です。名前より先はすべて任意です。最近の証明書は代替名で識別されるため、サブジェクトの項目が意味を持つのは、組織認証の注文だけです。

どの鍵の種類を選べばよいですか

新しく作るなら ECDSA P-256 です。強度は3072ビットのRSA鍵と同じで、サイズはずっと小さく、公的認証局がすべて従う規則で認められています。古い機器が鍵を読み取る必要がある場合は RSA 2048 を選びます。

NIST は P-256 と RSA-3072 を同じ128ビットのセキュリティ強度としており、RSA-4096 には強度そのものを与えていません。表の次の段階は7680ビットです。したがって4096ビットは、文書化された利点がないまま、訪問者全員のハンドシェイクに余分な負荷をかけます。P-384 は192ビットの段階で、Baseline Requirements は P-521 も許可していますが、Let's Encrypt は P-521 を拒否します。要求が規則上は完全に有効でも、使うつもりだったCAで失敗することがあります。

Ed25519 は、SSH、署名、プライベートCAに優れているため用意していますが、TLS証明書を発行する公的認証局はありません。規則が挙げているのはRSAと3種類のNIST曲線で、「no other algorithms or key sizes are permitted」と続きます。ポスト量子の ML-DSA も同じです。公的TLSで許可するはずだった投票案は、2026年10月にマージされないままクローズされました。ジェネレーターは、拒否のメールで知らせる代わりに、各選択肢の横でそのことを伝えます。

NIST の表によるセキュリティ強度NIST SP 800-57 Part 1 Rev 5, Table 2
112ビット128ビット192ビット256ビット
RSA20483072768015360
RSA 40964096
ECDSA—P-256P-384P-521

4096ビット:独自の段階なし 表は1つのサイズから次のサイズへ飛ぶため、余分なハンドシェイクの負荷は、文書化された利点を何も生みません

表にありません

Ed25519公的認証局は、これに対して発行しません

ML-DSAポスト量子:許可するはずだった投票案は、2026年10月にマージされないままクローズされました

  • 同じ強度
  • ここで選べます
  • 表にはありますが、ここでは選べません
  • 受け付けるCALet's Encrypt
縦ではなく横に読んでください。P-256 と3072ビットのRSA鍵は同じ強度で、曲線はそれを12分の1の鍵サイズで実現します。規則の範囲内の鍵でも、使うつもりだった認証局に拒否されることがあります。

各項目に何を入力するか

名前は、証明書の対象にするすべてのホストです。国は2文字です。組織は、OV または EV 証明書の場合の正式名称です。それ以外は任意で、現在は禁止されているものもあります。

組織単位は禁止されています。 CA/Browser Forum の投票案 SC047 により、2022年9月1日以降に発行された公的なTLS証明書には OU を含められず、CAは注文を拒否せず、これを削除します。サブジェクトのメールアドレスも、ドメイン認証の証明書では認められず、それ以外でも推奨されません。このジェネレーターは、プライベートCA向けに両方の項目を残し、印を付けています。

国は ISO 3166-1 alpha-2 のコードで、US、DE、GB、IN のように入力します。国名や3文字のコードではありません。都道府県は、略さず正式な名称で入力してください。EV証明書では、設立の管轄地と登記番号も必要で、このジェネレーターで入力できます。

証明書に残るサブジェクトの項目CA/Browser Forum TLS BR 7.1.2.7
要求の内容DVドメイン認証OV組織認証EVEV認証
共通名CN
国C
組織O
市区町村、都道府県L, ST
番地、郵便番号street, postalCode
組織単位OU2022年9月1日以降は禁止
メールアドレスemailAddress
登記番号、事業分類、管轄地serialNumber, businessCategory, jurisdictionC
  • CAが検証したとおりに証明書に載る
  • 認められるが推奨されない
  • この種類の証明書には載らない
  • 一切認められない
購入する証明書が載せられる項目だけを入力してください。認証局は残すすべてのサブジェクト項目を検証する必要があり、ジェネレーターは公的CAが削除する項目に印を付けます。

鍵や CSR は使い回せますか

使い回せます。禁じる規則はありません。ただし、証明書ごとに新しい鍵を作っても1秒しかかからず、鍵が1つ漏えいしたときの影響範囲を狭められます。

Baseline Requirements は「one certificate request MAY suffice for multiple Certificates to be issued to the same Applicant」と明記しているため、更新に同じ要求を使い回すことは認められています。代償は、何かが起きたときに現れます。その鍵が漏えいすれば、心配していた1枚だけでなく、その鍵を持つすべての証明書を24時間以内に失効させなければなりません。

さらに、漏えいした鍵は永久に使えなくなります。鍵の漏えいを知らされたCAは「SHALL reject a certificate request」とされているため、その鍵は、知っているどのCAでも二度と証明されません。証明書の有効期間は2029年に47日まで短くなり、使い回した鍵は、何十回もの更新を通じて何年も署名し続けることになります。新しい鍵を作るのは、1秒で済みます。

1つの鍵で複数の証明書CA/Browser Forum TLS BR 4.9.1.1 · 6.1.1.3

1つの鍵を使い回す

鍵が漏えいする
  • www.example.com
  • api.example.com
  • mail.example.com

3件の証明書を24時間以内に失効

その鍵は、知らされたCAでは二度と証明されません

証明書ごとに新しい鍵

  • www.example.com
  • api.example.com影響なし
  • mail.example.com影響なし

1件の証明書を24時間以内に失効

鍵の使い回しは認められています。代償が現れるのは、その鍵が漏えいしたときだけです。その鍵を持つものがすべて一度に失効し、以後その鍵は拒否されます。

CSR を送ったあとの流れ

CAは名前を検証し、ほかの大半は無視して、証明書を返します。秘密鍵は保管してください。鍵がなければ、証明書をインストールできません。

検証の対象はファイルではなく名前です。DNSレコード、Webサーバー上のファイル、またはそのドメインのアドレス宛のメールで行われます。それが通ると証明書が返ってきて、要求はもう使いません。インストール、更新、失効のいずれにも不要です。保管しなければならないのは秘密鍵で、鍵がなければ証明書は役に立ちません。何かを再起動する前に、証明書を CSR デコーダーに貼り付け、その横に秘密鍵も加えて、一致するかどうかを確認してください。

証明書の有効期間は短くなります。現在発行される公的なTLS証明書は200日を超えられず、2027年3月15日に100日、2029年3月15日に47日へ短縮されます。この長さでは更新を自動化する必要があり、それは ACME を意味します。ACME クライアントが要求を作ってくれるため、このページが役に立つのは、クライアントでは対応できない場合です。機器、アプライアンス、要求を手作業で求めるCAなどです。

要求から使える証明書までRFC 8555 · CA/Browser Forum TLS BR 6.3.2
  1. お手元のコンピューター要求を送る
  2. 認証局各名前を管理していることを確認するDNSレコードWebサーバー上のファイルそのドメインのアドレス宛のメール
  3. 認証局証明書に署名して送り返す
  4. お手元のコンピューター鍵の隣にインストールするここから先、要求はもう使いません
秘密鍵は動きません
証明書が有効でいられる期間
  1. 398日現在有効
  2. 200日2026年3月15日以降
  3. 100日2027年3月15日以降
  4. 47日2029年3月15日以降
検証の対象はファイルではなく名前です。返ってきた証明書は鍵がなければ役に立たず、有効期間がここまで短いからこそ、更新を自動化する必要があります。

OpenSSL で同じことをする方法

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes -keyout example.com.key -out example.com.csr で、鍵と要求を一度に作れます。

ジェネレーターは、入力した内容に合わせて、代替名とすべての拡張を含むコマンドを書きます。当サイトのテストでは、そのコマンドを OpenSSL で実行し、ページと同じサブジェクトと拡張が作られることを確認しています。質問を省くには -subj "/CN=example.com" を、名前には -addext "subjectAltName=DNS:example.com,DNS:www.example.com" を、アクセント付きの名前を保つには -utf8 を追加してください。-nodes は鍵を暗号化せずに残します。OpenSSL 3 では新しい書き方の -noenc を勧めていますが -nodes も使え、macOS に組み込まれた LibreSSL が理解する唯一の書き方です。その LibreSSL は Ed25519 の鍵をまったく作れないため、作るには OpenSSL 1.1.1 以降を使ってください。

作ったものを確認するには、openssl req -in example.com.csr -text -verify -noout を実行します。すべての項目が表示され、自己署名が検証されます。署名が一致しなければ、何も表示する前に停止します。鍵が要求に対応するかを確かめるには、openssl req -in example.com.csr -pubkey -noout と openssl pkey -in example.com.key -pubout の出力を比べてください。CSR に拡張子を割り当てる標準はなく、.csr、.pem、.req、.txt のどれも正しいものです。

1つのコマンドを、フラグごとにOpenSSL 3 · openssl-req(1)

openssl req -new -utf8 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes -keyout example.com.key -out example.com.csr -sha256 -subj '/CN=example.com' -addext 'subjectAltName=DNS:example.com,DNS:www.example.com'

  1. openssl req -new証明書署名要求を作ります
  2. -utf8サブジェクトを UTF-8 として読み、アクセント付きの名前を保ちます
  3. -newkey…そして一緒に新しい鍵ペアも作ります
  4. -pkeyoptP-256 曲線で
  5. -nodes鍵のファイルを暗号化しません(OpenSSL 3.0 では -noenc とも書けます)
  6. -keyout秘密鍵の書き出し先
  7. -out要求の書き出し先
  8. -sha256要求の署名に使うハッシュ
  9. -subjサブジェクト。質問されません
  10. -addext代替名

読み戻して、自身の署名を検証しますopenssl req -in example.com.csr -text -verify -noout

鍵は要求に対応していますか。2つの出力は同一でなければなりませんopenssl req -in example.com.csr -pubkey -nooutopenssl pkey -in example.com.key -pubout

このページが最初のサンプルに対して書くコマンドを、分解したものです。ジェネレーターは、入力した内容に合わせて、要求が持つすべての名前と拡張を含む同じ形の1行を書きます。

Windows、IIS、macOS での CSR の作り方

Windows には certreq と .inf ファイルがあり、macOS には Keychain Access があります。どちらも、始める前に知っておきたい落とし穴があります。

Windows では、certreq -new request.inf request.req が、[NewRequest] セクションでサブジェクトと鍵の長さを指定したファイルを読みます。代替名は、[Extensions] の OID 2.5.29.17 の下に _continue_ 行を使って書きます。SAN= というキーはなく、間違えやすい点です。Microsoft 自身のリファレンスページには、例が SHA-1 を使っているという警告があり、Let's Encrypt は SHA-1 で署名された要求を拒否するため、ハッシュは自分で指定してください。

Mac では、Keychain Access > Certificate Assistant > Request a Certificate From a Certificate Authority で作成できます。鍵の種類とサイズは「Let me specify key pair information」のチェックボックスの先にあり、2048ビット未満の RSA 鍵はもう提供されません。どちらの方法も代替名の指定は簡単ではないため、コマンドのほうが楽な場合がよくあります。

ブラウザーを使わずに作るMicrosoft Learn · Apple Support

certreqWindows Server と IIS

certreq はプレーンテキストのファイルを読み、要求を書き出しますcertreq -new request.inf request.req
request.inf
[NewRequest]Subject = "CN=example.com"KeyAlgorithm = RSAKeyLength = 2048HashAlgorithm = sha256RequestType = PKCS10[Extensions]2.5.29.17 = "{text}"_continue_ = "DNS=example.com&"_continue_ = "DNS=www.example.com"

代替名:OID で指定する拡張に、1行に1つずつ名前を書きます

ハッシュは自分で指定してください。Microsoft 自身の例は SHA-1 を前提に書かれており、認証局は拒否します

SAN= というキーはありません

Keychain AccessmacOS

Keychain Access が、Certificate Assistant から要求を書き出します
  1. Keychain Access
  2. Certificate Assistant
  3. Request a Certificate From a Certificate Authority
Mac は、これらのメニューを自分の言語で表示します

Let me specify key pair information

鍵の種類とサイズは、このチェックボックスの先にありますRSA は4096ビットまで。2048ビット未満は、もう提供されません
どちらの方法も、鍵をお手元のマシンで作ります。それが肝心な点です。どちらも代替名の指定は簡単ではなく、コマンドのほうが楽な場合がよくあります。

オンラインの CSR 作成ツールは安全ですか

鍵をどこで作るかで、すべてが決まります。ブラウザー内で作るページは安全です。サーバーで作るページは、あなたの秘密鍵に触れたことになります。

確かめ方は簡単で、自分で実行できます。ブラウザーのネットワークパネルを開き、要求を作成して、見てください。鍵がページ内で作られるなら、鍵も入力した内容も外には出ません。ここで出るリクエストは、ページ自身と、公開されている2つの名前リストだけで、どの訪問者でも同じです。リクエストが出て、鍵が返ってくるなら、その鍵は先に別の場所に存在していたことになり、インストールする前から、業界自身の定義では漏えいしています。

このページのすべての処理は、ブラウザー内で行います。鍵ペアは、どこにも接続できないサンドボックス化されたフレーム内の crypto.subtle.generateKey から生まれ、ページは公開鍵を中心に要求を組み立て、フレームがその外に出ない秘密鍵で一度だけ署名します。2つのファイルは、お使いのブラウザーにだけ現れます。どのWebページにもこれを任せたくない場合は、このページのOpenSSLコマンドが、同じことをお手元のマシンで行います。そのために表示しています。

鍵を作っているあいだの、ネットワークパネル開発者ツール › Network

このページ

リクエスト運ぶもの
GETtlds.jsonトップレベルドメインの一覧:どの訪問者でも同じ
GETsuffixes.jsonパブリックサフィックスリスト:どの訪問者でも同じ

入力した内容も鍵も、ページの外には出ません

サーバーで鍵を作るジェネレーター

リクエスト運ぶもの
POST…/generate入力した名前と詳細
200-----BEGIN PRIVATE KEY-----どこか別の場所で作られた秘密鍵

鍵がネットワーク経由で返ってきます。先に別の場所に存在していたことになります

確かめてみてください。ブラウザーの開発者ツールの Network タブを開いて、要求を作成します。ページ自身のコードを除くと、取得するのは公開されている2つのリストだけで、どの訪問者でも同じです。鍵は、どこにも接続できないフレーム内で、ブラウザー自身の暗号機能が作ります。

CSR 作成ツール:よくある質問

CSR を作成するにはどうすればよいですか

証明書の対象にするホスト名を入力し、鍵の種類を選び(迷ったら ECDSA P-256 です)、ボタンを押してください。2つのファイルが出力されます。認証局に送る証明書署名要求と、保管する秘密鍵です。すべてブラウザー内で行うため、アップロードも保存もされません。

CSR をオンラインで作成しても安全ですか

鍵をどこで作るかによります。ページが自分のサーバーで作る場合、そのサーバーはあなたの秘密鍵に触れたことになり、CA/Browser Forum 自身の定義では漏えいです。ページがブラウザー内で作るなら、鍵はそこから出ません。このページは後者で、確認もできます。生成しながらネットワークパネルを開いて確かめてください。

どの鍵の種類を選べばよいですか

新しく作るなら ECDSA P-256 です。NIST の評価では3072ビットのRSA鍵と同じ128ビットの強度で、サイズははるかに小さく、ハンドシェイクのたびに負荷が軽くなります。古いアプライアンスやロードバランサーが必要とする場合は RSA 2048 を選びます。RSA 4096 には3072に対して文書化された利点がなく、P-521 は規則上許可されていても Let's Encrypt が受け付けません。

Ed25519 の鍵で公的な証明書を取得できますか

できません。Ed25519 に対して発行する公的認証局はありません。Baseline Requirements が挙げているのはRSAと P-256、P-384、P-521 の曲線で、「no other algorithms or key sizes are permitted」と続きます。Ed25519 は SSH、署名、プライベートCAに向いているため用意していますが、これで公的なTLS証明書を注文すると拒否されます。

秘密鍵のファイルは何のためのものですか

証明書があなたのものだと証明する、鍵ペアの半分です。誰にも送ってはいけません。保管するファイルとして、要求の隣に保存してください。CAから返ってきた証明書をインストールするのに必要で、なければ証明書は役に立ちません。失くした場合は、新しい鍵、新しい要求、新しい証明書を用意するしかありません。

組織と国は入力する必要がありますか

組織認証またはEV証明書の場合だけで、その場合もCA自身が検証してからでないと証明書には載りません。ドメイン認証の証明書では、規則が認めるサブジェクトの項目は国と共通名だけで、それ以外は載ってはいけません。公的CAが削除または禁止する2つの項目、組織単位とメールアドレスには、ジェネレーターが印を付けます。

組織単位の欄に警告が出るのはなぜですか

OU は、公的なTLS証明書では禁止されているためです。CA/Browser Forum の投票案 SC047 により、2022年9月1日以降に発行された公的なTLS証明書には含められず、認証局は注文を拒否せず、これを削除します。このジェネレーターは、プライベートCA向けにこの項目を残し、公的CAがどう扱うかを表示します。

1つの CSR に複数のドメインを入れられますか

はい。そのためにあるのがサブジェクト代替名で、マルチドメイン証明書や SAN 証明書はこの方法で注文します。証明書の対象にするホストをすべて追加してください。必要なら www 付きの名前も含めます。ワイルドカードと通常の名前を混在させ、IPアドレスも追加できますが、IPアドレス向けの証明書を販売していないCAもあります。

次の証明書に CSR や鍵を使い回せますか

使い回せます。規則上、1つの要求を、同じ申請者の複数の証明書に使えます。避ける理由は被害の範囲です。その鍵が漏えいすれば、その鍵を持つすべての証明書を24時間以内に失効させなければならず、鍵は、知らされたどのCAでも二度と証明されません。新しい鍵を作るのは、1秒で済みます。

チャレンジパスワード とは何ですか

RFC 2985 の任意の属性で、後で失効を求めるときに伝える共有の秘密として作られました。SCEP によるデバイスの登録でいまも使われ、Microsoft の証明書サービスには求めるものもあります。通常のWeb証明書の注文では何の役割もないため、CAから特に求められた場合以外は、空のままにしてください。

ワイルドカード証明書にも使えますか

はい。名前に *.example.com を入力し、ベースドメインも対象にしたい場合は example.com も追加してください。ワイルドカードで置き換えられるのはちょうど1つのラベルで、その下にある名前自体には一致しません。アスタリスクは左端のラベル全体でなければならず、*.co.uk のようなパブリックサフィックスに対するワイルドカードは、どのCAも発行しません。

ファイルは、このあとどうすればよいですか

送るファイルである要求を認証局に送り、保管するファイルである秘密鍵は、自分だけが読める状態(LinuxとmacOSではパーミッション600)で安全な場所に置いてください。証明書が返ってきたら、それと要求を CSR デコーダーに貼り付けて、同じ鍵を共有しているかを確認してから、何かを再起動してください。証明書と一致しない鍵は、サーバーが気づく前に見つけたい間違いです。

足りないものはありますか?機能や新しいツールを提案する