クライアントSSL認証の.pemファイルと.crtファイル
したがって、私はセキュリティについて最小限の知識しか持っていませんが、セキュリティを確保したい機密データを処理するアプリケーションの主な開発者です。アプリケーションは他の1つのサーバーと通信します（他のサーバーはフロントエンドで、私のサーバーは基本的にバックエンドです）。私たちのセキュリティ専門家（現在は利用できません）は、サーバー間の接続には相互SSL認証が必要であると説明しています。私たちのシステム管理者はクライアント側の認証を設定し、.pemファイルを提供しました。今度は、誰かがアプリケーションにアクセスしようとすると、クライアントのSSL認証を渡していないため、SSLエラーが発生します。別の州にいる他の開発者に、アプリケーションにアクセスする権限を与える必要があります。彼に.pemファイルを送信することはできますか？ .crtファイルを作成して彼に送信する必要がありますか？基本的に、他の開発者がアプリケーションにアクセスするために必要なすべての情報を入手できるように、他の開発者にどのような情報を提供する必要がありますか。 .pemファイルには何がありますか？公開鍵だけですか、それ以上ですか？
PEMはPrivacy Enhanced Mailを意味しますが、頭字語は長い間ファイル形式より長く使われていません「PEM」形式は、バイナリデータをテキストにエンコードする方法です。そのため、データは、テキストベースのメディア（通常は電子メール）にあまり注意を払わないメディアを介した転送でも存続できます。
基本的に、PEMはいくつかのヘッダーで始まります。
-----BEGIN FOOBAR-----
続いて、バイナリデータの Base64 エンコードと、要素の終わりを示すフッター行：
-----END FOOBAR-----
したがって、PEM形式は非常に一般的であり、実際にファイルに何があるかを知るにはヘッダーを調べる必要があります。
あなたのケースでは、certificateとprivate key。証明書は公開部分です。これは、SSLクライアントとサーバーが最初のハンドシェイク中に互いに送信するものです。証明書は電子メールで移動できます。公開データのみが含まれ、さらに署名されているため、特別な保護は必要ありません。
秘密鍵は、まったく別のビジネスです。 SSLハンドシェイクでは、クライアントはサーバーに証明書のコピーを送信し（サーバーがクライアントの公開鍵を学習できるようにする）、クライアントは対応する秘密鍵の習熟を示します（内部では、署名が計算されます）サーバーからのチャレンジを介して）。 秘密鍵は、クライアントを「特別」にするものです。攻撃者はそれを知りません。攻撃者が秘密キーを知っている場合、攻撃者はクライアントになりすますことができ、それはまさにあなたが避けたいことです。
したがって、電子メールで「現状のまま」秘密鍵を送信しても、本当に発生しないはずです。
ただし、状況によっては、クライアント（「別の状態の開発者」）が証明書との両方の秘密鍵を取得する必要があります。したがって、証明書と秘密鍵の両方をそのクライアントに伝達する方法が必要です。通常の方法では PKCS＃12形式 を使用します。これにより、パスワードベースの暗号化が可能になります。
- 証明書とその秘密鍵の両方を、巨大で太い、非常にランダムなパスワードで保護されたPKCS＃12ファイルにラップします。
- 結果のファイル（従来は「.p12」または「.pfx」と呼ばれていました）を受信者に送信します。
- 受信者に電話してパスワードを伝え、パッケージを復号化して証明書と秘密鍵を取得できるようにします。
組織内に証明書または秘密鍵がわかっている人がいない場合は、問題があります。つまり、暗号を理解せずに使用しているということです。ある時点で「セキュリティの専門家」がいました。彼を取り戻しましょう。セキュリティは即興をうまく許容しません。
システムにアクセスするための.pemファイルが1つしかない場合は、ファイルに証明書と関連する秘密鍵の両方が含まれているようです。これを確認するには、テキストエディターでファイルを開き、「BEGIN CERTIFICATE」セクションと「BEGIN RSA PRIVATE KEY」セクションの両方が含まれていることを確認します。
この状況では、システム管理者に他の開発者用の新しい証明書を生成させるのが理想的です。これにより、両方のユーザーが資格情報を共有せずにシステムにアクセスできるようになります。