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

PEMとは

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

とくにWebサーバーのTLS設定やVPN、SSHなどで「証明書ファイル」「秘密鍵ファイル」を扱うときに、PEM形式が選ばれるケースが多いでしょう。

PEMの構造と特徴

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

代表例として、証明書（Certificate）は次のような形です。

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

同様に、秘密鍵やCSR（証明書署名要求）でも「BEGIN/END」の種類が変わります（例：BEGIN PRIVATE KEY、BEGIN RSA PRIVATE KEY、BEGIN CERTIFICATE REQUESTなど）。

テキスト形式なので内容を開いて確認しやすい一方で、手作業で編集すること自体は推奨されません。改行や余計な空白、ヘッダー／フッターの崩れで読み込みエラーになりやすく、意図せず破損させてしまうことがあります。

PEMファイルの特徴

PEM形式は「.pem」で提供されることもありますが、実務上は拡張子と中身が必ずしも1対1ではありません。たとえば証明書でも、.pem / .crt / .cer といった拡張子で配布されることがあります（中身がPEMの場合もDERの場合もあり得ます）。

PEMとして配布される証明書には、一般に「所有者（Subject）」「発行者（Issuer）」「有効期限」「公開鍵」など、通信相手を検証するための情報が含まれます。秘密鍵（Private Key）は別ファイルとして管理されることが多く、取り扱いは慎重に行う必要があります。

PEMの利用シーン

PEMは、現在ではインターネット全般のセキュリティ設定で利用されます。代表例は次の通りです。

• Webサーバー（HTTPS/TLS）でのサーバー証明書・中間証明書・秘密鍵
• OpenVPNなどのVPN接続での証明書・鍵
• SSHでの鍵（OpenSSH形式も含め、テキスト表現として近い運用感）

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

デジタル証明書とは？

デジタル証明書（一般にX.509証明書）は、オンライン通信において「相手が正しい相手であること」を確認するための電子的な証明書です。主な要素として、次の情報を含みます。

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

証明書そのものは「中身の構造（DERで表現されることが多い）」と、「それをどう運ぶか（PEMで包む／DERのまま配る）」が分かれており、PEMはその“運び方（表現形式）”として登場するイメージです。

【参考】デジタル証明書とは？ 役割・種類・仕組みをわかりやすく解説

デジタル証明書の役割

デジタル証明書は、主に次の3点に関わります。

• 真正性：相手が本物か（なりすましではないか）
• 完全性：通信内容が改ざんされていないか
• 機密性：必要に応じて通信を暗号化できるか（TLSなど）

証明書は単独で万能ではありませんが、信頼の連鎖（認証局）や暗号プロトコル（TLS）と組み合わさることで、実運用に耐えるセキュリティ基盤になります。

PEMの「できること」

PEMは「暗号の仕組みそのもの」ではなく、暗号データ（証明書・鍵・CSRなど）を扱いやすくする表現形式です。現場でよく登場する用途を、整理しておきます。

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

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

ただし、秘密鍵をPEMで保存している＝安全という意味ではありません。テキストで扱えるぶん、流出時の影響も大きいため、アクセス制御・保管場所・バックアップ手順まで含めて運用設計が重要です。

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

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

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

WebサーバーでTLSを設定する際、サーバー証明書・中間証明書（チェーン）・秘密鍵をPEMで指定する構成は非常に一般的です。ソフトウェアによっては「証明書チェーンを1ファイルに連結して指定する」運用もあり、このときPEMは扱いやすい形式になります。

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

PEMは「連結できる」点が便利ですが、混ぜ方には注意が必要です。たとえば、証明書チェーンは連結でOKでも、秘密鍵まで同一ファイルに入れる運用は、管理・権限設計の観点で避けられることもあります（要件と運用ポリシー次第です）。

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

PEM形式に必要なデータの整理

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

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

重要なのは、これらが「PEMという箱に入ったデータ」だという点です。中身が証明書なのか、鍵なのか、CSRなのかで、ヘッダー／フッターが変わります。

.pemファイルの作り方（考え方）

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

どうしても「貼り付けで保存」する場面があるなら、最低限次を守ります。

• ヘッダー／フッターを正しい表記で保持する（-----BEGIN ...-----）
• Base64部分の改行を崩さない（余計な空白を入れない）
• 文字化けを起こさない（UTF-8で保存、BOMは避けるのが無難）

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

PEMはテキストなのでエディタで開けます。ただし「中身の意味」を確認するなら、ツールでパースして確認するのが確実です。たとえば証明書であれば、Subject、Issuer、有効期限、SANなどを確認できる手段（OpenSSL、OSの証明書ビューア等）を使うと安心です。

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

よく見かけるエラー例として、次があります。

• Unable to load certificate
• Unable to load private key

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

• ヘッダー／フッターの種類が違う（CERTIFICATEのはずがPRIVATE KEYになっている等）
• 余計な空白・改行崩れ・文字化けでBase64が壊れている
• 証明書と秘密鍵がペアではない（鍵の組み合わせ違い）
• 暗号化された秘密鍵なのに、パスフレーズ指定ができていない／間違っている

「どのデータを読み込もうとしているのか」「そのデータの種類は何か」を切り分けると、復旧が早くなります。

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

証明書や鍵を扱うフォーマットはPEMだけではありません。ここでは、現場でよく並べて語られるDERとPKCS系を整理します。

DER形式

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

DERは「テキストで読めない」だけで、危険という意味ではありません。むしろ、仕様として厳密で、機械処理に向いています。人間が中身を確認したい場合は、ビューアやツールで表示します。

PKCS形式

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

• PKCS#7（.p7b / .p7c など）：証明書チェーンをまとめる用途で見かける（秘密鍵は含まないのが一般的）
• PKCS#12（.p12 / .pfx）：証明書と秘密鍵をまとめて格納でき、パスワード保護も可能

たとえばWindows環境で証明書と秘密鍵を「一式として」移行する場合は、PKCS#12（.pfx）が選ばれることが多いでしょう。

PEM、DER、PKCSの主な違い

シーンに応じた形式選択のポイント

形式選択は「何をどこで使うか」でほぼ決まります。

• WebサーバーやOSS系ツールの設定：PEMが多い
• 証明書と秘密鍵を一式で安全に持ち運びたい：PKCS#12（パスワード保護）
• 製品や環境がDERを要求している：DERで渡す（必要に応じて変換）

まとめ

PEMは、もともとメールセキュリティの文脈で登場した言葉ですが、現在は証明書や鍵などを「テキストとして扱える表現」にする形式として広く使われています。PEM自体が暗号方式ではなく、証明書や鍵といった暗号データの“入れ物”である点を押さえると、DERやPKCS#12との違いも整理しやすくなります。

PEMは確認しやすい反面、改行崩れや貼り付けミスで壊れやすい側面もあります。運用では、ツールで生成・変換し、種類（CERTIFICATE / PRIVATE KEY / CSR）を取り違えないことが大切です。

よくある質問

PEMは「証明書の形式」なのですか？

厳密には、PEMは証明書そのものの構造ではなく、証明書や鍵などをBase64化してテキストとして表現する「表現形式（エンコーディング）」です。中身が証明書（X.509）であることも、秘密鍵であることもあります。

PEMの「BEGIN/END」は何を意味しますか？

そのブロックに入っているデータの種類を示します。たとえば証明書は BEGIN CERTIFICATE、秘密鍵は BEGIN PRIVATE KEY、CSRは BEGIN CERTIFICATE REQUEST のように表示されます。

.pem以外の拡張子でもPEM形式はありますか？

あります。.crt や .cer、.key などでも中身がPEMであることがあります。拡張子だけで判断せず、BEGIN/ENDの表記やツールで中身を確認するのが確実です。

PEMはテキストなので、編集しても問題ありませんか？

推奨されません。改行や空白、文字コードの影響で破損しやすく、読み込みエラーの原因になります。編集が必要な場合は、OpenSSLなどのツールで再生成・変換するのが安全です。

証明書PEMと秘密鍵PEMは、同じファイルにまとめてもよいですか？

技術的には可能ですが、運用上は分けることが多いです。アクセス権限やバックアップの扱いが難しくなり、秘密鍵の露出リスクも上がるためです（要件とポリシー次第です）。

「Unable to load certificate」が出たときの典型原因は何ですか？

ヘッダー／フッターの種類違い、Base64部分の破損（改行崩れ・余計な空白・文字化け）、そもそも証明書ではないデータを読み込んでいる、などが典型です。

証明書と秘密鍵がペアかどうかはどう確認しますか？

ツールで両者の公開鍵情報（モジュラスやフィンガープリント等）を比較して一致するか確認します。目視では判断できないため、コマンドや機器の診断機能を使うのが確実です。

DERとPEMの違いは何ですか？

DERはバイナリで厳密に表現された形式、PEMはそれをBase64化してテキストで扱えるようにした形式です。同じ証明書でも、DER版・PEM版が存在します。

PKCS#12（.pfx/.p12）はいつ使いますか？

証明書と秘密鍵を「一式」で扱いたいときに使われることが多いです。パスワード保護も可能で、Windows環境の移行や配布でよく登場します。

PEMの中身（有効期限やSANなど）はテキストで読めますか？

PEM自体はBase64なので、そのままでは読み取れません。ツールでデコードして表示することで、Subject、Issuer、有効期限、SANなどを確認できます。運用ではこの確認手順を持っておくと安心です。