.p12 ファイルのパスワードを取得することで問題を解決したことは認識していますが、あなたが言及した各ファイルの内容に少し光を当てたいと思いました。将来。
この質問の主な質問に答えるには: CertificateSigningRequest.certSigningRequest ファイルから必要なものを再構築できますか?
残念ながら、答えは非常に堅実な「いいえ」です。この根本的な原因は、デジタル証明書の作成、検証、使用、および失効を扱う一連の管理テクノロジ、人員、慣行である公開キー基盤 (PKI) の心臓部にあります。PKI の中心となるのは、公開鍵と秘密鍵のペアの概念です。「公開」キーは、広く共有するキーです。誰もがそのコピーを持っている可能性があり、デジタル証明書によって署名されたメッセージを検証したい人は、このキーにアクセスする必要があります。「プライベート」キーは、あなた (より正確にはあなたのマシン) だけが知っていて、メッセージに署名するときに使用するリンクされたキーです。メッセージが実際に本物であることを認証するために広く共有されている「公開」キーを使用して検証されるのは、この署名です。
開発証明書または配布証明書を作成するときは、本質的にキーチェーン アクセス、openssl、または好みの SSL ツールチェーンに公開鍵と秘密鍵のペアを作成するように求めます。公開鍵は、名前や電子メール アドレスなどの他の「件名」フィールドとともに CertificateSigningRequest ファイルに入り、このファイルを Apple に発送します。そのファイルは主に、アプリの署名を検証するために使用できる公開鍵を Appleに通知します。結局のところ、秘密鍵のコピーを提供するわけではありません。 iOS プラットフォームでの説明責任の概念 (例: このアプリの署名は有効であるとチェックアウトされますが、それが実際に有効であったかどうかはまだわかりません)私が信頼する開発者によって署名されています...)。いかなる時点においても、あなたの秘密鍵が Apple または開発者ポータルに送信されることはありません。1) 証明書の有効期限が切れる、2) 開発者ポータルから積極的に証明書を失効させる、または 3) キーチェーンからキーペアを誤って (または意図的に) 削除するまで、キーチェーンに問題なく存在します。
では、これらの各ファイルには何が含まれているのでしょうか?
CertificateSigningRequest.certSigningRequest - これには、ローカルで生成した公開鍵と秘密鍵のペアからの公開鍵のコピーと、証明書署名要求の形式で必要な追加のサブジェクト情報が含まれています。Apple はこの追加情報を無視し、証明書を作成する際に、開発者アカウントのファイルにある名前と電子メール アドレスを使用します。
.p12 - これは PKCS#12 形式のファイルで、Apple 発行の証明書 (それ自体に公開鍵が含まれています) のコピーと、リンクされた秘密鍵のコピーが含まれています。このデータは、認証されていないアクセスを防ぐために暗号化されているため、解読するにはパスワードが必要です。
.cer - これは、キー ペアの公開キー部分を含む Apple 発行の証明書です。この証明書は、提出されたアプリが App Store レビュー チームへの転送中に改ざんされていないことを確認するために Apple によって使用されます。
- 自分だけが知っている秘密鍵を使用してアプリに署名し、署名済みのバイナリを Apple にアップロードします。
- 次に、Apple は、すでに共有されている公開鍵を使用して署名を検証します。
- 計算がうまくいけば、アプリは改ざんされていないので、問題ありません。
- 計算がうまくいかない場合は、アプリが改ざんされたか、または (可能性が高い) 証明書が失効または再生成され、アプリが古いか正しくないキー ペアで署名されました。
ご覧のとおり、秘密鍵が存在する場所は、元の開発者のキーチェーンと暗号化された .p12 ファイルだけです。あなたのコメントと flup のコメントの両方と一致して、その .p12 ファイルへのパスワードを取得するか、暗号化の突破を検討する必要があります。
とにかく、元の開発者からパスワードを入手できたと聞いてうれしいです. ご不明な点がございましたら、お気軽にお問い合わせください。