PEM、CER、CRT、P12-それはすべて何ですか？
私の質問があまり一般的ではないことを願っていますが、非対称キーを格納するトピックは非常に混乱します。
私が理解する方法は次のとおりです。openSSLを使用して、RSAキーペアを生成できます。
openssl genrsa -out private.pemは秘密鍵のみを含むPEMファイルを私に与えますopenssl rsa -in private.pem -outform PEM -pubout -out public.pemは、公開鍵を含むPEMファイルを提供します
したがって、これらの2つのコマンドを実行した後、RS-256キーのペアができました（正しい名前ですか？キーは私が知る限り2048ビットなので、RS-2048ではなくRS-256なのでしょうか）。
- すでに証明書（private.PEM + public.PEM）を持っている2つのファイルを検討できますか？
- CER、CRT、またはP12ファイルの内容は何ですか？これらのファイルの実際の例は見つかりません。
- 持っている2つのPEMファイルからCER、CRT、またはP12を生成するにはどうすればよいですか？
- P12ファイルをパスワードで保護できるという情報を見ました-このファイルをパスワードで保護する理由は何ですか-そのパスワードはどこかに保存する必要があります。すでにP12ファイルは誰もアクセスできない安全な場所に保存しています。右へ？
- 1つのPEMファイルに公開キーと秘密キーの両方が含まれている例をいくつか見ました。 PEMの決められた構造はありませんか？必要な鍵をそこに置くことはできますか？
- 「----- BEGIN CERTIFICATE -----」と「----- END CERTIFICATE -----」のあるPEMファイルも見ました。その証明書は何ですか？私の2つのPEMファイルには「----- BEGIN PUBLIC KEY -----...----- END PUBLIC KEY -----」があり、もう1つには「----- BEGIN RSA」があります。プライベートキー-----...----- END RSA PRIVATE KEY ----- "。
openssl genrsa -out private.pemは、秘密鍵のみを含むPEMファイルを私に与えます
あんまり。原則として、RSAは秘密鍵のみを公開鍵なしで格納できますが、OpenSSLが使用するRSAPrivateKey形式（PKCS1別名RFC 2313 2437 3447 8017 ）は両方を格納します。他の非対称アルゴリズム（DSA、DH、ECC）に使用される形式にもこのプロパティがあります。つまり、常に秘密鍵ファイルのみを保存し、必要なときにいつでも公開鍵を取得できます。 GPGも同じことを行います。公開鍵情報は、歴史的な理由で呼ばれるため、常に「秘密」鍵内に含まれています。 OpenSSH（主に）はOpenSSL形式を使用しているため、有用な観察ではありません。
openssl rsa -in private.pem -outform PEM -pubout -out public.pemは私に公開鍵を含むPEMファイルを与えます
only公開鍵が含まれています。また、（1）秘密鍵ファイルから再生成でき、（2）ほとんどのアプリケーションは公開鍵だけでなく証明書を使用するため、ほとんど役に立ちません。
したがって、これらの2つのコマンドを実行した後、RS-256キーのペアができました（正しい名前ですか？キーは私が知る限り2048ビットなので、RS-2048ではなくRS-256なのでしょうか）。
技術的にはキーペアですが、上記のようにOpenSSLは基本的にキーペアの概念をプライベートキーとマージし、パブリックキーのみを区別します。パブリックキーはパブリックであるため、区別する必要があります。
はい、暗号鍵はほとんど常にビット単位で測定されます。スキーム名RS256（ハイフンなし）は、JSON Web署名（JWS）およびJSON Webトークン（JWT）で使用され、RSA署名（具体的には、RSA署名スキームRSASSA-PKCS1-v1_5はPKCS1によって定義されています）SHA-付きハッシュの場合は256。これはRSAキーのサイズとは関係なく、任意の（実装された）サイズで使用できます。 RFC7517のRS256のサンプルキーは1024ビットです-今日のRSA-1024は十分な安全マージンを提供していませんが、NISTやCABforum（およびほとんどのWebブラウザー）などの権威者によって数年間禁止されています。 RSA署名（およびRSA暗号化）は、JWS/JWT以外の多くのアプリケーションで使用されます。
すでに証明書（private.PEM + public.PEM）を持っている2つのファイルを検討できますか？
まず明確化：「証明書」は、多くのコンテキストで使用される一般的な概念です。暗号化の場合、対象となる証明書は通常、公開鍵をいくつかの関連する属性を持つアイデンティティ（または場合によってはロール）にバインドする公開鍵証明書であり、最も一般的なものは、以下で定義される公開鍵証明書です- X.509 は、1988年に当時のCCITT（現在はITU-T）によって作成された標準であり、多くの標準化団体によって拡張され、より使いやすくなりましたが、基本的には異なりません。証明書のインターネット標準はX.509に基づいており、PKIXと略されるX.509を使用して公開鍵インフラストラクチャと呼ばれます。 X.509は、他のいくつかのコンピューター標準と同様に、抽象構文記法1と呼ばれる-- ASN.1 と呼ばれる一般的な構文を使用してデータを表します。
そうは言っても、NO。 公開鍵/X.509証明書含む公開鍵ですが、それは単なる公開鍵ではありません。良い鍵が含まれています公開鍵は間違いなく最も重要な単一の情報ですが、それが使用される方法に不可欠な他の情報の取り扱い。証明書はfor公開鍵であり、通常は証明書署名要求としてCSRまたは単に要求としてパッケージ化され、 Certificate Authority と呼ばれるエンティティ、またはCAを使用して証明書にデジタル署名しますCAのキー。他のユーザーがそれを変更できないようにするため、それを使用するすべてのプログラムがCAを信頼できます。原則として、誰でもCAとして機能でき、特にOpenSSLコマンドラインプログラムは、証明書の発行など、CAが行う技術的な操作を実行できます。ただし、ほとんどの状況で、証明書の価値と有用性は、発行CAがどれだけ広く信頼されているかに依存するため、最も成功したCAは、Digicert-now-include-Symantec-formerlyなど、信頼できると証明されたCAです。 -Verisign、Comodo、GoDaddyなど.
特殊なケースとして、CAの鍵の代わりに独自の鍵を使用して署名された「自己署名」証明書を持つことが可能です。この証明書は、実際のCAと同じように信頼を伝えることはできません。置換に対して効果的に保護されていないためですが、CAに連絡したり、支払いを行ったりできない場合でも作成でき、通常は次のように処理できます通常は証明書を使用または必要とするように設計されたプログラムによる手動の承認または上書き。
CER、CRT、またはP12ファイルの内容は何ですか？これらのファイルの実際の例は見つかりません。
CERとCRTは（両方）X.509証明書を含むファイルの拡張子として一般的に使用され、ファイルシステムに応じてどちらの場合でも使用できます。ファイルのコンテンツに使用される2つの一般的なエンコーディングがあります。「DER」は、ASN.1によって定義されたバイナリエンコーディング（Distinguished Encoding Rules）です。 "PEM" 。バイナリDERをbase64に変換し、便利なサイズの行に分割し、ヘッダーとトレーラーの行を追加します。これは、特にカットアンドペーストなどの場合に便利です。 PEMは、このエンコーディングが他の電子メールおよびメッセージテクノロジに取って代わられたプライバシー強化（e）メール用に最初に定義されたため、この名前が付けられていますが、この形式は引き続き使用されています。これらのエンコーディングは非常に異なって見えますが、それらにはまったく同じ情報が含まれており（破損していない限り）、証明書を扱う多くのプログラムは両方を読み取ることができます。 OpenSSLによって作成されたPEMファイルには、ヘッダーの前またはトレーラーの後に「コメント」情報が含まれることがよくあります。プログラムはこれを無視する必要がありますが、混乱することがあり、無関係な情報を削除する必要があります。 Windowsでは、通常は Byte Order Mark を追加する「UTF-8」形式を使用しないように注意してください。これは、ディスプレイには表示されませんが、プログラムによるファイルの読み取りを妨げます。
PEMは証明書に広く使用されており、多くのPEMファイルは証明書ですが、PEMは他の多くのものにも使用されていることに注意してください。 PEMファイルが証明書であるとは限りません。代わりに、ヘッダー行を確認してください。この場合、便宜上-----BEGIN CERTIFICATE-----または-----BEGIN X509 CERTIFICATE-----と表示されます。詳細については rfc7468 を参照してください。
P12は、一般に、 PKCS12 aka PFX 形式のファイルを識別するために使用されますが、かなり異なります。 PKCS12標準は多数のオプションをサポートしていますが、通常、秘密鍵とそれに対応する証明書に加えて、ほとんどの場合、信頼チェーンを形成するために必要な1つ以上の「チェーン」または「中間」証明書を含めるために使用されます。エンドエンティティ証明書を検証します。実際には、PKCS12ファイルは常にバイナリですが、PEMでエンコードできなかったり、人間にとって使いやすいものになったりする技術的な理由はありません。
持っている2つのPEMファイルからCER、CRT、またはP12を生成するにはどうすればよいですか？
証明書を取得するには、CA（作成したCAまたは作成したDIYのCA）を使用するか、自己署名証明書を作成する必要があります。使用するソフトウェア（および存在する場合はCA）に応じて、これらのそれぞれに数百のバリエーションがあると思われますが、OpenSSLおよびmost CAの場合、sualプロシージャは次のとおりです。
openssl req -new -key privatekey [... other options] >csrを使用してCSRを作成します
詳細については、reqのmanページを参照してください。証明書HTTPSを含むSSL/TLSの場合を使用する場合は、「共通名」を、サーバーへのアクセスに使用する名前（またはa）にします。これは、通常、完全修飾ドメイン名です（FQDN）。証明書を他のアプリケーションに使用する場合、必要なID情報はアプリケーションによって異なります。
- 実際のCAの場合は、CSRをCAに送信し（多くの場合、PEMが便利なWebフォームで）、IDの証明またはその他の承認、および必要に応じて支払いを行います。
代わりに、新しく発行された「エンドエンティティ」証明書（公開鍵とIDを含む）と、信頼チェーンの作成に使用される中間CAの公開鍵とIDを含む1つまたは2つの証明書を受け取る必要があります。これらは、通常はP7BまたはP7Cと呼ばれる個別のファイル（DERまたはPEM）または連結（PEMのみ）または PKCS7 標準（データのないSignedDataまたは署名のみの証明書）の特定の場合があります。
2 '。または、これを自分で行います。 CAのキーと証明書を作成し（一度だけ）、openssl ca ...またはopenssl x509 -req -CA -CAkey ...を使用してCSRを読み取り、独自のCAで証明書を発行します。
この証明書は、あなた自身または暗黙的にあなたを信頼する人が制御するシステムとプログラムでのみ使用できますand技術的にCA証明書をインストールできます。これは通常、小規模なグループで、空の場合もあります。また、たとえば、reqのデフォルトを受け入れるなど、CA証明書とエンドエンティティ証明書に同じ名前を付けないように注意してください。そうすると、結果の証明書はどこでも使用できなくなります。
- 必要に応じて、秘密鍵とチェーン証明書とともに証明書を使用します。このmayは、
openssl pkcs12 -exportを使用して、それらをPKCS12に結合することを含みます。
上記のように、CAが発行した証明書の代わりに自己署名証明書を作成できます。手順1と2/2 'を単一の手順に置き換えます：openssl req -new -x509 -key privatekey ... >cert
-x509フラグの追加に注意してください。また、manページで説明されている追加のオプションが多数あります。これには、DIY CAのすべてのプロパティと制限に加えて、さらに多くのことが含まれます。あなた（および/またはあなたの友人）は、DIY CA証明書を一度インストールするだけでなく、各エンドエンティティ証明書を個別にインストールし、いつでもプロセスを繰り返す必要があります。有効期限が切れているか、関連情報が変更されているため、証明書を置き換える必要があります。
P12ファイルをパスワードで保護できるという情報を見ました-このファイルをパスワードで保護する理由は何ですか-そのパスワードはどこかに保存する必要があります。すでにP12ファイルは誰もアクセスできない安全な場所に保存しています。右へ？
パスワードは必ずしも保存する必要はありません。プログラムは必要に応じてプロンプトを表示できます（特にopensslプログラムはプロンプトを表示します）。 PKCS12/PFXは現在ストレージに使用されることが多いですが、もともとは証明書を使用して秘密鍵をあるシステムから別のシステムに転送することを目的としていましたが、このプロセスは安全でないことがよくあります。ストレージであっても、安全であると考えるシステムや場所は、安全ではないと判明することがあります。秘密鍵を暗号化する多層防御は、その価値があります。ただし、場合によっては、パスワードはほんの少しの追加作業であり、実際の利益はありません。
1つのPEMファイルに公開キーと秘密キーの両方が含まれている例をいくつか見ました。 PEMの決められた構造はありませんか？必要な鍵をそこに置くことはできますか？
1つのPEMファイルから複数のオブジェクトを読み取ることができるため、1つのPEMファイルを有効に保存できるかどうかは、読み取りを行うプログラムによって異なります。 most（すべてではない）の場合のOpenSSLはこれを処理できるため、OpenSSL（およびOpenSSLライブラリを呼び出すプログラム）でそのようなファイルを使用することは、ある程度一般的です。他のプログラムやライブラリは異なる場合があります。上記のように、公開鍵をそのまま保存することはほとんど役に立ちません。保管など秘密鍵とcertificate、またはチェーン内のすべての証明書が役立ちます。 Apache httpdやnginxのようなプログラムはこれをサポートします（ただし必須ではありません）。
「----- BEGIN CERTIFICATE -----」と「----- END CERTIFICATE -----」のあるPEMファイルも見ました。その証明書は何ですか？
証明書全般については、上記を参照してください。特定の証明書の詳細（「所有者」と呼ばれる鍵の所有者の名前、公開鍵、証明書が有効な期間、発行元のCAとそのシリアル番号など）を知りたい場合は、次を使用できます。 openssl x509 -text <fileまたはシステムによっては、通常、他のいくつかのプログラムで証明書の詳細を表示できます。 Windows for .cer .crtでは、ファイルをダブルクリック（または「実行」ダイアログで名前を付けるか、CMDでstartコマンド）すると、[詳細]タブを含むダイアログがポップアップ表示されます。