I understand that you solved the problem by getting the password for the .p12 file, but I thought I would lighten up a little what lives in each of these files that you mentioned, in the interests of anyone who works on the question in the future.
To answer the main question in this question: can I restore what I need from the file CertificateSigningRequest.certSigningRequest?
Unfortunately, the answer is a very solid no. The root cause of this is the core of public key infrastructure (PKI), a set of management technologies, people and practices related to the creation, verification, use and revocation of digital certificates. A central element of PKI is the concept of a public-private key pair. The "Public" key is one that you widely distribute, everyone can have a copy of it, and anyone who wants to check messages signed with a digital certificate will require access to this key. The 'Private' key is a related key that only (or, more precisely, your computer) knows and uses when signing messages. It is this signature that is verified using the public key, which is widely used to authenticate that the message is indeed authentic.
When we create development or distribution certificates, we essentially ask for Keychain Access, openssl, or your preferred SSL chain to create a public / private key pair. The public key is included in the CertificateSigningRequest file along with other Subject fields, such as name and email address, and we send this file to Apple. This file primarily tells Apple that the Public Key that they can use to verify your subscription to the application does not give them a copy of your Private Key in the end, if others had your secret key, they could encode the code, since you are effectively destroying the concept of accountability on the iOS platform (for example, this application signature is verified as valid, but I still don’t know if it was actually signed by a developer whom I trust ...). At no time is your secret key transferred to Apple or Portal Developer; he lives happily enough in your keychains until the certificate expires. 2) you are actively revoking the certificate from the developer portal, or 3) you accidentally (or intentionally) delete the key from Keychain.
So what lives in each of these files?
CertificateSigningRequest.certSigningRequest . It contains a copy of the public key from the open-access local pair you created, as well as additional required information about the subject, required by the certificate signing request format. Apple ignores this additional information and uses the name and email address that they have in the file for your developer account when creating your certificate.
.p12 . This is a PKCS # 12 formatted file containing a copy of the Apple certificate (which itself contains the public key) and a copy of the associated private key. This data is encrypted to prevent access to unauthorized access and, therefore, a password is required for encryption.
.cer . This is an Apple certificate that contains part of the public key of a key pair. This certificate is used by Apple to verify that the applications you submit are not faked during transit to the App Store review group:
- You sign your application with a secret key that you only know, and download the signed binary into Apple.
- Apple then verifies the signature using the public key that you have already shared with them.
- If the math works, then the application is not faked, and you are good to go.
- If the math does not work, either the application was tampered with, or (which is much more likely), the certificate was revoked or regenerated, and the application was signed with an old or incorrect key pair.
As you can see, the only places where the private key is located are in the original developer key chain, as well as in the encrypted .p12 file. In accordance with your comments and comments, you should either get a password for this .p12 file, or study an encryption breakthrough.
Regardless, it's nice to hear that you were able to get a password from the original developer. Let me know if you have any further questions.