PEMとは？ わかりやすく10分で解説

PEMは、証明書や秘密鍵、CSRなどの暗号データを、テキストとして扱いやすい形で表す形式です。-----BEGIN ...----- と -----END ...----- に挟まれたBase64文字列として使われることが多く、WebサーバーのTLS設定やVPN、証明書運用の現場で利用されています。

PEMとは

PEMは「Privacy-Enhanced Mail」の略称で、もともとは電子メールを安全に扱うための仕組みとして提案されました。現在はその文脈を超えて、証明書や鍵などの暗号データをテキストとして扱える形に整える表現形式として使われています。

特に、WebサーバーのTLS設定、VPN、SSH関連の鍵や証明書の受け渡しなどで、PEM形式のファイルを扱う場面があります。ただし、PEMは暗号方式そのものではありません。証明書、秘密鍵、公開鍵、CSRなどのデータを、Base64と境界行で表現するための形式です。

PEMの構造と特徴

PEM形式は、バイナリデータ（例：X.509証明書や秘密鍵）をBase64でエンコードし、ヘッダーとフッターで囲んだテキストとして表現します。代表例として、証明書は次のような形になります。

-----BEGIN CERTIFICATE-----
（Base64で表現された証明書データ）
-----END CERTIFICATE-----

秘密鍵やCSRでも、同じようにヘッダーとフッターでデータの種類を示します。たとえば、秘密鍵では BEGIN PRIVATE KEY や BEGIN RSA PRIVATE KEY、CSRでは BEGIN CERTIFICATE REQUEST が使われることがあります。

PEMはテキスト形式なので、ファイルを開いて境界行を確認しやすい形式です。一方で、手作業での編集には注意が必要です。改行、余計な空白、ヘッダー／フッターの崩れによって読み込みエラーが起きることがあります。

拡張子だけではPEMと断定できない

PEM形式のファイルは .pem で提供されることがあります。ただし、実務上は拡張子と中身が必ずしも1対1ではありません。証明書ファイルでも、.pem、.crt、.cer などの拡張子で配布される場合があり、中身がPEM形式の場合もDER形式の場合もあります。

そのため、拡張子だけで判断せず、-----BEGIN CERTIFICATE----- などの境界行や、OpenSSLなどのツールで中身を確認します。PEMとして配布される証明書には、一般に所有者（Subject）、発行者（Issuer）、有効期限、公開鍵など、通信相手を検証するための情報が含まれます。

PEMの利用シーン

PEMは、現在ではインターネット全般のセキュリティ設定で使われています。代表的な利用場面は次のとおりです。

• Webサーバー（HTTPS/TLS）でのサーバー証明書、中間証明書、秘密鍵の設定
• OpenVPNなどのVPN接続で使う証明書や鍵の管理
• SSH関連の鍵変換や一部ツールでの入出力
• CSRを認証局へ提出する際のデータ形式

なお、SSHではOpenSSH独自形式の鍵が使われる場面もあります。PEMとして扱えるかどうかは、利用するツール、設定先、鍵の種類によって確認します。

PEMファイルとデジタル証明書

デジタル証明書とは？

デジタル証明書（一般にX.509証明書）は、オンライン通信において、通信相手の公開鍵がどの主体に結び付いているかを確認するための電子的な証明書です。主な要素として、次の情報を含みます。

• 証明書の所有者情報（Subject）
• 発行者情報（Issuer：認証局など）
• 公開鍵（Public Key）
• 有効期限（Not Before / Not After）
• 用途（サーバー認証、クライアント認証などの拡張情報）

証明書そのものには、X.509などの構造があります。その証明書データをバイナリで扱う場合はDER形式、テキストとして扱いやすくした場合はPEM形式、という関係で整理できます。PEMは証明書の中身そのものではなく、証明書や鍵を運ぶための表現形式です。

デジタル証明書の役割

デジタル証明書は、主に「誰の公開鍵か」を示し、相手の真正性確認や鍵共有の前提になる情報を提供します。

• 真正性：相手の公開鍵が、その相手に結び付いているかを確認する材料になる
• 完全性：証明書自体は電子署名で保護され、改ざん検出の前提になる
• 機密性：TLSなどが証明書内の公開鍵を使って鍵共有を行い、通信の暗号化につながる

証明書は単独で通信の安全性を完結させるものではありません。認証局への信頼、証明書チェーン、暗号プロトコル、秘密鍵の管理と組み合わせて、通信相手の確認と暗号化を支えます。

PEMで扱える主なデータと用途

PEMは暗号の仕組みそのものではなく、暗号データを扱いやすくする表現形式です。証明書、秘密鍵、公開鍵、CSRなど、現場でよく登場するデータの種類と用途を整理します。

秘密鍵・公開鍵を格納できる

PEMは、秘密鍵や公開鍵をテキストとして格納できます。秘密鍵では、BEGIN PRIVATE KEY（PKCS#8）や、古い形式である BEGIN RSA PRIVATE KEY（PKCS#1）などが見られます。

ただし、秘密鍵をPEMで保存していること自体は、安全性を保証しません。PEMはテキストとして扱えるため、流出時の影響も大きくなります。アクセス制御、保管場所、バックアップ、パスフレーズの扱い、権限設定まで含めて管理します。

CSR（証明書署名要求）を格納できる

CSRは、証明書を発行してもらうために認証局へ提出するデータです。公開鍵と申請情報を含み、対応する秘密鍵で署名されます。CSRもPEM形式で扱われることが多く、ヘッダーには BEGIN CERTIFICATE REQUEST が使われます。

CSRを送信するときは、秘密鍵ではなくCSRだけを提出します。秘密鍵をCAや第三者へ送る必要はありません。

SSL/TLS通信の設定で使われる

WebサーバーでTLSを設定する際、サーバー証明書、中間証明書、秘密鍵をPEM形式で指定する構成は広く使われています。ソフトウェアによっては、証明書チェーンを1つのPEMファイルに連結して指定する運用もあります。

このとき重要なのは、証明書、秘密鍵、中間証明書を取り違えないことです。BEGIN CERTIFICATE、BEGIN PRIVATE KEY などの境界行を確認し、証明書と秘密鍵が対応しているかをツールで検証します。

複数要素を1ファイルにまとめられることがある

PEMは複数のブロックを連結できるため、証明書チェーンを1ファイルにまとめる用途で使われます。ただし、何を同じファイルへ入れるかは、利用するソフトウェアと運用ポリシーに依存します。

証明書チェーンの連結は一般的に使われますが、秘密鍵まで同一ファイルに含める場合は、アクセス権限やバックアップ範囲の管理が難しくなります。秘密鍵を含むファイルは、証明書ファイルよりも厳格に扱う必要があります。

PEM形式ファイルの作成と確認方法

PEMファイルに入る主なデータ

PEMファイルとして扱う代表的なデータは次のとおりです。

• デジタル証明書（X.509）
• 秘密鍵（Private Key）
• 公開鍵（Public Key）
• CSR（証明書署名要求）

重要なのは、これらがPEM形式で表現されたデータだという点です。中身が証明書なのか、鍵なのか、CSRなのかで、ヘッダー／フッターが変わります。

.pemファイルを作るときの考え方

実運用では、証明書や鍵はOpenSSLなどのツールや、認証局からの発行物として入手するのが一般的です。テキストエディタで手作業により作成するのではなく、ツールで生成・変換し、ファイルとして保存する方法が安全です。

やむを得ず貼り付けて保存する場合は、最低限、次の点を確認します。

• ヘッダー／フッターを正しい表記で保持する
• Base64部分の改行を崩さない
• 余計な空白を入れない
• 文字化けを起こさない形式で保存する
• 秘密鍵を扱う場合は、保存先とアクセス権限を制限する

.pemファイルの内容確認方法

PEMはテキストなのでエディタで開けます。ただし、Base64部分をそのまま読んでも、証明書の有効期限やSANなどの意味は分かりません。内容を確認する場合は、OpenSSLやOSの証明書ビューアなど、ツールでパースして確認します。

証明書であれば、Subject、Issuer、有効期限、SAN、公開鍵、署名アルゴリズムなどを確認します。秘密鍵であれば、暗号化の有無や鍵形式を確認します。CSRであれば、サブジェクト情報やSANなどの拡張要求を確認します。

よくあるPEM関連エラーと対処の考え方

PEM関連でよく見かけるエラーには、次のようなものがあります。

• Unable to load certificate
• Unable to load private key
• no start line
• bad base64 decode

典型的な原因は次のとおりです。

• ヘッダー／フッターの種類が違う
• Base64部分に余計な空白や文字化けがある
• 改行が崩れている
• 証明書と秘密鍵が対応していない
• 暗号化された秘密鍵のパスフレーズが指定されていない、または誤っている
• 読み込ませるファイルの種類を誤っている

復旧時は、どのデータを読み込もうとしているのか、そのデータの種類は何か、証明書と秘密鍵が対応しているかを切り分けます。

PEMと他のフォーマット（DER、PKCS）との比較

証明書や鍵を扱うフォーマットはPEMだけではありません。現場では、DER、PKCS#7、PKCS#12なども使われます。用途に応じて、形式の違いを把握しておく必要があります。

DER形式

DERは、ASN.1構造をバイナリで厳密に表現する形式です。PEMのようなヘッダー／フッターはなく、ファイルとしてはバイナリになります。環境によっては、.cer や .der などの拡張子で配布されることがあります。

DERはテキストで読めませんが、危険という意味ではありません。仕様として厳密で、機械処理に向いています。人が内容を確認する場合は、証明書ビューアやOpenSSLなどのツールで表示します。

PKCS形式

PKCSは公開鍵暗号関連の標準群です。実務では、主に次の形式が登場します。

• PKCS#7（.p7b / .p7c など）：証明書チェーンをまとめる用途で使われる。通常、秘密鍵は含まない。
• PKCS#12（.p12 / .pfx）：証明書と秘密鍵を一式で格納でき、パスワード保護も可能。

Windows環境で証明書と秘密鍵を一式として移行する場合は、PKCS#12（.pfx）が選ばれることがあります。一方、WebサーバーやOSS系ツールでは、PEM形式で証明書と秘密鍵を別ファイルとして指定する構成もよく使われます。

PEM、DER、PKCSの主な違い

用途に応じた形式選択のポイント

形式選択は、何をどこで使うかによって決まります。代表的な選び方は次のとおりです。

• WebサーバーやOSS系ツールの設定：PEM形式が使われることが多い
• 証明書と秘密鍵を一式で持ち運びたい：PKCS#12を検討する
• 製品や環境がDERを要求している：DERで渡す
• 証明書チェーンだけをまとめたい：PEM連結またはPKCS#7を確認する

どの形式を選ぶ場合でも、最終的には設定先の製品やサービスが要求する形式に合わせます。拡張子ではなく、ファイルの中身と設定先の仕様で判断します。

PEM運用時の注意点

秘密鍵を含むPEMは厳格に管理する

PEM形式の秘密鍵は、テキストとしてコピーしやすい形式です。扱いやすい反面、誤送信や権限設定ミスで流出するリスクがあります。秘密鍵を含むファイルには、必要最小限のアクセス権限を設定し、不要な共有やメール添付を避けます。

証明書チェーンの順序を確認する

証明書チェーンをPEMで連結する場合、サーバー証明書、中間証明書の順序を設定先の仕様に合わせる必要があります。順序や不足があると、クライアント側で証明書検証に失敗することがあります。

本番反映前に検証する

証明書、秘密鍵、中間証明書を設定した後は、本番反映前または反映直後に検証します。証明書と秘密鍵が対応しているか、証明書チェーンが正しいか、有効期限が適切か、SANに必要な名前が含まれているかを確認します。

まとめ

PEMは、もともとメールセキュリティの文脈で登場した言葉ですが、現在は証明書や鍵などをテキストで扱うための形式として広く使われています。PEM自体は暗号方式ではなく、証明書や鍵などのバイナリデータをBase64で表し、ヘッダーとフッターを付けて扱う表現形式です。

PEMは確認しやすい一方で、改行崩れや貼り付けミスで読み込みエラーが起きやすい形式でもあります。運用では、ツールで生成・変換し、CERTIFICATE、PRIVATE KEY、CERTIFICATE REQUEST などの種類を取り違えないことが重要です。

秘密鍵を含むPEMファイルは、証明書ファイルよりも厳格に管理します。用途に応じて、PEM、DER、PKCS#12などを使い分け、設定先の製品やサービスが求める形式に合わせて扱う必要があります。

よくある質問