CSRの先頭がBEGIN CERTIFICATEになる原因と正しいCERTIFICATE REQUESTの見分け方（OpenSSL/Windows対応）

CSR（証明書署名要求）を作成したのに、ファイル先頭が「BEGIN CERTIFICATE」や「BEGIN TRUSTED CERTIFICATE」になって困ったことはありませんか？見た目が似ていても中身は別物です。本記事では、正しいCSRのヘッダー、混同が起きる典型例、OpenSSL/Windowsでの判定と作り直し手順を実務目線で整理します。

まず結論：CSRは「CERTIFICATE REQUEST」で始まる

CSR（Certificate Signing Request）は、CA（認証局）へ証明書の発行を申請するためのデータです。CSRは一般にPKCS#10形式で作られ、PEM（Base64）で保存すると先頭と末尾にヘッダー／フッターが付きます。正しいCSRのヘッダーは次のいずれかです。

• -----BEGIN CERTIFICATE REQUEST-----
• -----BEGIN NEW CERTIFICATE REQUEST-----（Windows系ツールなどで見かけることがあります）

一方で、-----BEGIN CERTIFICATE-----や-----BEGIN TRUSTED CERTIFICATE-----で始まるデータは、名前が似ていてもCSRではありません。拡張子が.csrでも、中身が証明書だったり、OpenSSL独自形式だったりすることがあるため、まずは「ヘッダーで中身を判定する」癖を付けるのが近道です。

PEMヘッダーが示すのは「拡張子」ではなく「中身の種類」

PEMは、バイナリ（DER）をBase64化し、用途を示すラベル（ヘッダー）で囲んだテキスト形式です。ファイル名や拡張子は人間の管理のための目印にすぎず、実際に重要なのは先頭のヘッダー行です。

先頭ヘッダー	中身の正体	主な用途	CAへ提出するCSRとして使える？
BEGIN CERTIFICATE REQUEST BEGIN NEW CERTIFICATE REQUEST	CSR（PKCS#10）	証明書発行申請（ドメイン/組織情報、公開鍵、署名など）	はい
BEGIN CERTIFICATE	発行済み証明書（X.509）	サーバー/クライアントへインストールして利用	いいえ（申請ではなく“結果”）
BEGIN TRUSTED CERTIFICATE	OpenSSLのTrusted Certificate（X.509 + trust rules）	OpenSSLの信頼判定向けに追加情報を付与した証明書	いいえ（CSRではない／他環境で扱えない場合あり）

この表だけでも方向性は決まります。CAに渡すのは「CERTIFICATE REQUEST」系、それ以外は“証明書側のデータ”です。

「BEGIN CERTIFICATE」になる原因：CSRではなく証明書を保存している

-----BEGIN CERTIFICATE-----は、CAが発行した（または自己署名した）X.509証明書です。CSRと違い、発行者（Issuer）や有効期限（Not Before/Not After）、拡張領域（Key Usage / Extended Key Usage / SANなど）が含まれ、CAまたは自分の秘密鍵で署名されています。つまり、証明書は「申請データ」ではなく「発行された成果物」です。

拡張子が.csrでもBEGIN CERTIFICATEになってしまうのは、手順のどこかでCSRのつもりで証明書を出力・保存しているケースがほとんどです。代表的な混同パターンを挙げます。

よくある状況	何が起きているか	対処の考え方
CAから返ってきた証明書（CRT/PEM）を、手元で.csrとして保存した	保存したのは“発行済み証明書”。CSRではない	CA提出用はCSR。証明書はインストール用。役割を分けて保管する
OpenSSLのコマンドをコピペして実行したが、reqではなくx509を使っていた	CSR生成ではなく証明書処理のコマンドを実行している	openssl req -newでCSRを生成する。openssl x509は証明書の表示/変換が中心
GUIツールで「証明書のエクスポート」を選んでしまった	出力されるのは証明書（または証明書チェーン）	CSR作成のメニュー（要求/リクエスト/申請）を選ぶ
自己署名証明書を作った（開発用）つもりが、そのファイルをCSRだと思い込んだ	作ったのは自己署名証明書（= BEGIN CERTIFICATE）	本番CAへ申請するならCSRを生成。自己署名は“CAなしで完結する別手順”

重要なのは、CSRは秘密鍵で署名した「申請書」で、証明書はCAが署名した「発行物」という点です。順序としては「秘密鍵 → CSR → CA発行 → 証明書」です。ここが逆転すると、ほぼ必ず混乱します。

「BEGIN TRUSTED CERTIFICATE」とは：OpenSSL独自の“信頼ルール付き証明書”

-----BEGIN TRUSTED CERTIFICATE-----は、OpenSSLが扱う“Trusted Certificate”形式です。見た目はPEM証明書と同じくBase64ブロックですが、内部的には証明書本体（X.509）に加えて補助情報（X509_CERT_AUX）が含まれ、OpenSSLの信頼判定で利用するtrust rules（信頼/拒否の属性、用途の指定など）を持てるのが特徴です。

この形式は、たとえばOpenSSLのコマンドで証明書を出力するときに、-trustoutや-addtrust等のオプションを使った場合に生成されることがあります。

# 例：証明書を“Trusted Certificate”として書き出す
openssl x509 -in cert.pem -trustout -out cert_trusted.pem

ただし、Trusted CertificateはOpenSSL中心の世界で便利な一方、他のライブラリや機器がこのヘッダーを理解できないことがあります（読み込めても、追加のtrust情報を無視するだけの実装もあります）。そして何より、これはCSRではなく証明書側です。CAへ提出する用途には通常使いません。

もし手元のファイルがTrusted Certificateで、一般的なBEGIN CERTIFICATEのPEMに寄せたい場合は、OpenSSLで“普通の証明書”として書き出し直すのが安全です。

# Trusted Certificate → 通常の証明書PEMへ正規化
openssl x509 -in cert_trusted.pem -out cert.pem

手元での見分け方：OpenSSLで「CSRか証明書か」を即判定する

ヘッダーが分かりやすいケースも多いですが、改行の有無や前後のテキストが混ざっていて判断しづらいこともあります。そんなときはOpenSSLで“通るコマンド”を試すのが最短です。

判定したいもの	コマンド	ポイント
CSRかどうか	openssl req -in file -noout -text	Subject、公開鍵、署名アルゴリズム、拡張要求（SANなど）が表示される
証明書かどうか	openssl x509 -in file -noout -text	Issuer、有効期限、拡張領域、シリアル番号などが表示される
PEMではなくDERかも？	openssl req -in file -inform DER -noout -text openssl x509 -in file -inform DER -noout -text	バイナリ形式（DER）で保存されている場合は-inform DERが必要

実務では「どちらが成功するか」でまず分類し、その後に内容を見て修正します。もしopenssl reqでもopenssl x509でも読めない場合は、そもそもPEM/DERではない（別形式、途中で壊れた、改行が欠けた、メール本文が混ざった）可能性が高いです。

CSRを作り直すときの正攻法（OpenSSL）

CSRは「秘密鍵」とセットで初めて作れます。証明書（BEGIN CERTIFICATE）からCSRを“復元”することはできません（秘密鍵が無いと署名できないため）。手元に秘密鍵が残っているなら、その秘密鍵を使ってCSRを作り直すのが王道です。

秘密鍵を新規に作り、CSRも同時に作る

# RSA 2048bitの秘密鍵とCSRを同時に生成（秘密鍵は暗号化しない例）
openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr

対話形式で国名（C）、都道府県（ST）、組織名（O）、コモンネーム（CN）などを入力します。自動化したい場合は-subjで指定できます。

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/C=JP/ST=Tokyo/L=Chiyoda/O=Example Inc/OU=IT/CN=www.example.com"

既存の秘密鍵からCSRだけ作る

# 既存の秘密鍵（server.key）からCSRを生成
openssl req -new -key server.key -out server.csr

「秘密鍵はそのまま、CSRだけ作り直したい」という現場は多いです。鍵を作り直すと、サーバーにインストールする証明書も入れ替えになるため、影響範囲が広がります。鍵が流出していない前提なら、既存鍵の使い回しは合理的な選択肢です。

SAN（Subject Alternative Name）を確実に入れる

近年のTLSでは、CNだけでなくSANが実質必須です。CSRにSANが入っていないと、CAが自動で補ってくれない限り、発行された証明書もSAN無しになり、ブラウザで警告になったり、機器によっては接続できなかったりします。

OpenSSLでSAN付きCSRを作る代表的な方法は、設定ファイル（openssl.cnf）を使うやり方です。

# openssl.cnf（抜粋例）
[ req ]
default_bits       = 2048
prompt             = no
default_md         = sha256
distinguished_name = dn
req_extensions     = req_ext

[ dn ]
C  = JP
ST = Tokyo
L  = Chiyoda
O  = Example Inc
OU = IT
CN = www.example.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = www.example.com
DNS.2 = example.com

# 設定ファイルを指定してCSR生成
openssl req -new -key server.key -out server.csr -config openssl.cnf

CSR作成後は、必ず中身を表示してSANが入っているか確認します。

openssl req -in server.csr -noout -text

OpenSSLコマンド早見表

やりたいこと	コマンド例	補足
CSRの内容を確認	openssl req -in server.csr -noout -text	Subject / Public Key / SANなどを見る
証明書の内容を確認	openssl x509 -in server.crt -noout -text	Issuer / Validity / EKUなどを見る
秘密鍵とCSRが対応しているか確認	openssl rsa -in server.key -noout -modulus | openssl md5 openssl req -in server.csr -noout -modulus | openssl md5	ハッシュが一致すれば同じ鍵ペア。RSA以外は別手段が必要
ヘッダーを正規化（NEW → REQUEST）	openssl req -in old.csr -out new.csr	中身がCSRなら、一般的なヘッダーに再出力できる

WindowsでCSRを作ると「NEW CERTIFICATE REQUEST」になりやすい理由

Windowsのcertreqや一部の証明書管理ツールで作成したCSRは、PEMの先頭が-----BEGIN NEW CERTIFICATE REQUEST-----になることがあります。これはCSRの一種であり、PKCS#10の中身自体は同じです。OpenSSLで読み込めるなら、基本的に“正しいCSR”と考えて問題ありません。

WindowsでCSRを作る代表例として、certreqを使った方法を紹介します（管理者権限での実行が必要な場合があります）。

# 例：要求ファイル（request.inf）からCSR（request.csr）を作成
certreq -new request.inf request.csr

request.infの内容は環境によって調整が必要ですが、最重要ポイントはCNとSANの整合です。SANを入れないと、発行後に困る確率が上がります。WindowsのINFでSANを指定する方法はいくつか流儀があり、CAやOSバージョンで挙動差も出るため、実運用では「作成したCSRを必ず表示して確認する」手順を組み込みましょう。

Windows上でファイル内容をざっくり確認するなら、先頭行の確認に加えてcertutilも役立ちます。

# まずは中身がCSRとして解釈できるか（Base64のPKCS#10か）を確認する
certutil -dump request.csr

ツールによっては、CSR作成→CA送信→発行証明書の受領までを同じ画面や同じフォルダで扱えるため、ファイル名を付け替えたタイミングで混乱しがちです。Windows運用では次のように役割別に命名すると事故が減ります。

• 秘密鍵：server.key / server_private.key（外部に絶対出さない）
• CSR：server.csr / 2026_example_com.csr
• サーバー証明書：server.crt / server.pem
• 中間CA証明書：intermediate.crt
• チェーン：fullchain.pem（サーバー証明書＋中間）

「CSRとして提出してよいデータ」を見極めるチェックリスト

最後に、CAへ提出する直前に確認しておくと失敗が激減するチェック項目をまとめます。運用手順書にそのまま貼れるよう、現場で実際に効くポイントに絞りました。

• 先頭ヘッダーがBEGIN CERTIFICATE REQUESTまたはBEGIN NEW CERTIFICATE REQUESTになっている
• openssl req -in xxx.csr -noout -textでエラーにならない
• Subject（CN）が意図したFQDNになっている（例：www.example.com）
• SANが入っている（DNS:やIP Address:が想定通り）
• 鍵長とアルゴリズムが要件を満たす（RSA 2048/3072、ECDSAなど）
• CSRに秘密鍵を混ぜていない（BEGIN PRIVATE KEYが同じファイルに入っていない）
• 改行が崩れていない（Webフォーム貼り付け時にスペースが入らない）
• 申請先CAの仕様（文字コード、SAN必須、ワイルドカード可否など）を満たしている

よくある質問

CSRのヘッダーが「NEW CERTIFICATE REQUEST」だとCAに拒否されますか？

多くの場合、拒否されません。中身がPKCS#10のCSRであれば、ヘッダー表記の違いは“包装紙”の違いに近く、OpenSSLなど主要ツールは同じCSRとして扱えます。ただし、Webフォーム側の実装が厳密でヘッダー文字列だけをチェックしているケースもゼロではありません。その場合は、openssl req -in old.csr -out new.csrで再出力してBEGIN CERTIFICATE REQUESTに寄せると解決することがあります。

「BEGIN CERTIFICATE」しか手元にありません。CSRを作れますか？

秘密鍵が無い状態では作れません。CSRは秘密鍵で署名するため、証明書だけからは生成できません。もし過去にサーバーで鍵を作っていたなら、サーバー内に秘密鍵が残っていないか（例：/etc/ssl/privateやWindows証明書ストア）を確認し、見つかった秘密鍵からCSRを再生成してください。

CSRと秘密鍵が合っているか確かめたいです

RSA鍵であれば、OpenSSLでmodulus（公開鍵由来の値）を出し、ハッシュが一致するかを見るのが定番です。前述の「OpenSSLコマンド早見表」の手順で一致すれば、CSRと秘密鍵は同じ鍵ペアです。合っていない場合、CAに提出しても発行後にサーバーへインストールできず、再発行が必要になることがあります。

Trusted Certificateは“信頼できる証明書”という意味ですか？

名前に引っ張られがちですが、ここでのTrusted Certificateは「OpenSSLが信頼判定に使う追加属性を持てる形式」という意味合いが強いです。OSの証明書ストア（Windowsの信頼されたルートなど）に登録されているかどうかとは別概念です。CAへ申請するCSRではない点だけは押さえておきましょう。

CAに提出するCSRは、どこまで貼り付ければいいですか？

基本は、-----BEGIN ...-----から-----END ...-----までを丸ごと渡します。Base64部分だけを抜き出すと受付側でエラーになることがあります。メールやチャットに貼り付ける場合は、途中で自動改行や余計な空白が入らないよう注意してください。

CSR作成で入力する組織名（O）や部署名（OU）は重要ですか？

発行する証明書の種類によります。DV（ドメイン認証）中心の証明書では、組織情報が空でも問題にならないことがあります。一方、OV/EVなど組織実在性を確認するタイプでは、CSRの情報が申請情報と整合していることが求められる場合があります。迷ったら、申請先CAの申請画面・ガイドに合わせ、CSRと申請フォームで情報を揃えるのが安全です。

まとめ：ヘッダーを見れば、CSRか証明書かは一瞬で分かる

CSRの正しい先頭はBEGIN (NEW) CERTIFICATE REQUESTです。BEGIN CERTIFICATEは発行済み証明書、BEGIN TRUSTED CERTIFICATEはOpenSSL独自の信頼ルール付き証明書で、どちらもCAへ提出するCSRの代わりにはなりません。混乱したら、ヘッダー確認とopenssl req/openssl x509での判定を先に行い、必要なら秘密鍵からCSRを作り直す――これが最短で確実な解決ルートです。