iOS Code Signing: Part 3, Certificates
iOS Code Signing: Part 3, Certificates
In Part 3 of this iOS code signing series, you'll learn how to generate certificates for iOS development and what's in these certificates.
Join the DZone community and get the full member experience.Join For Free
This is Part 3 of the iOS Code Signing tutorial series. This series covers fundamentals of the iOS code signing process. You can find Part 1 here.
In the previous post, we covered how to generate the Certificate Signing requests from Keychain Access as well as using command line tools. In this post, we will cover how to generate certificates for iOS development and will look inside the certificate contents. As an iOS developer, you must have created certificates by yourself at least once and stored them in the keychain. You probably never looked at it until your Xcode tells you that your certificate expired. It's important to understand the certificate's contents in order to understand the code signing process. Now, let's dive deep into Certificates.
The certificate is at the core at code signing in iOS apps. Let's forget about Apple Certificates and get into real life. When you finish university or some professional course, you get a certificate. You then attach that certificate to your CV or LinkedIn profile to show that you are trusted by some authority (the university) that you have completed that program and you have knowledge. The employer is then impressed and offers you the job. Certificates are more powerful when they are offered by popular trusted authorities. If you get the certificate from London Business School, Oxford, or Cambridge University, then people trust you more. Basically, it's the same concept in the iOS or Apple world.
In the iOS world, you get the certificate from the trusted authority a.k.a. Certificate Authority (CA), which is Apple certifying that
- You are a legitimate (not necessarily good) developer of apps.
- You also paid Apple to get a membership with Apple Developer or another similar program.
- Apple has verified that all the information provided is correct and issued you a certificate to build awesome iOS apps.
Getting the certificate from Apple isn't a big thing; you just have to pay them enough to get those required certificates. However, understanding the details of certificates and why we need those certificates are definitely a big thing. Apple has ten different types of certificates, as mentioned in the official documentation here. Each certificate has a different purpose, but there are two main certificates: the Development Certificate and Distribution Certificate.
Let's go through the process of generating the certificates. In order to generate a new certificate, we have to log in to our developer portal and select the Certificates and Profile section. If you click on the Certificates section, you will see an option in the form of a + button to create a new certificate. Click on the add new certificate which prompt you to select the type of certificate that you want to create, as shown below.
After selecting the certificate - in this case, "iOS App Development" - the next step will be to create the CSR, which we have seen in the above session. Apple will give you all the instructions to generate the CSR file locally.
This will ask you to save the file CertificateSigningRequest.certSigningRequest on your local machine. In the next screen, we need to upload this file to the developer portal to get the certificate. We can then download the certificate to the local machine.
At this stage, you will have the file with the extension downloaded to your local machine. You can then double click on the certificate to add it to the keychain. Verify that the Keychain has newly generated certificate with private key attached, as shown below.
If you see the certificate with the private key in the keychain, then you can confirm that you have successfully generated an iOS developer certificate. You can also confirm that using the following command:
$ security find-identity -v -p codesigning
This command will print all the certificates that you have on the keychain.
You can generate the same for the distribution as well using a similar process, selecting "iOS distribution" instead of "iOS app development" in the certificate type.
Now that we have successfully generated the certificate for iOS development, let's look at the certificate and see what's inside to get more information.
Basically, the certificate has all the data that we have provided while creating the certificate signing request. Apple then adds some signer data like authority, expiry date, etc. The whole certificate has the signature attached to it. In the Keychain application, if you right-click on the certificate and "Get Info," you will see all this information. It should have the following things:
- Subject Name: This contains UserID, name, organization details, and the country name of the developer.
- Issuer name: This contains Apple details like authority, organization unit that has issued the certificate, and expiry date of the certificate.
- Public Key Info: This contains details of the public key, like which algorithm and signature are used.
- Fingerprints: Finally, it contains fingerprint details like SHA-256 and SHA-1 etc. The certificate also shows what this certificate will be used for, like codesigning or any other activity.
You can see the certificate details from the command line, as well:
$ openssl x509 -in ios_development.cer -inform DER -text -noout
This will show exactly the same information on the command line with the whole signature at the bottom.
Note that these details are exposing all the information of the certificate itself, but we also need the private key attached to the certificate to code sign the apps. This is where we need the certificate in the
P12 format to back it up with the private key.
In cryptography, PKCS#12, a.k.a. Public Key Cryptography Standard is the standard used to store private keys with public key certificates protected with a password. This format defines multiple cryptographic objects in a single file.
In our case, in the iOS development certificate, we can export the certificate from the keychain into the Personal Information Exchange, a.k.a. p12 format. Just right-click on the certificate in the Keychain Access and select Export.
You will see the option to export your certificate in the
.p12 format. Also, you can encrypt this certificate with a strong password.
You can also create the certificate in the
.p12 format using the command line. If you have generated the private key using the command line while creating CSR, as mentioned above, then we can use this key.
$ openssl x509 -in XXXXX.cer -inform DER -out mycert.pem -outform PEM $ openssl pkcs12 -export -inkey my.key -in mycert.pem -out mycert.p12
If you provided the passphrase, then this command will prompt you to enter the passphrase, and you will see your certificate generated in the p12 format. Once, we have generated the certificate in .p12 format, it's easy to backup. There is no risk of losing the private key while using it on multiple Macs. The certificate in the p12 format has your certificate combined with the private key. If you are interested in knowing what's inside the P12 certificate, you can find the details using the following command:
$ openssl pkcs12 -info -in mycert.p12
This will prompt you for the password if the p12 is encrypted. The storage container for PKCS#12 is called safe bags, which stores information as bags, with each bag having its own attributes and actual content. In our case, we have two bags: one for the certificate and another for the private key. You will see bag attributes followed by the actual content of the certificate or private keys.
At this stage, we understand the iOS certificates and it's internal details. However, having the certificate alone can't code sign iOS apps, it requires the private key to code sign the apps. In the next part, we will see another important aspect of code signing: provisioning profiles and entitlements.
Published at DZone with permission of Shashikant Jagtap , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.