I'm reading this article on iOS push certificates, and I'm confused about this paragraph:
Your backend sends notifications through Apple's servers to your application. To ensure that unwanted parties are not sending notifications to your application, Apple needs to know that only your servers can connect with theirs. Apple therefore requires you to create an SSL certificate to be able to send push notifications.
My understanding of SSL certificates is that if a server has one, that server is able to encrypt data that it sends to a device. But it says here Apple needs to know that only your servers can connect with theirs. I don't understand how having an SSL certificate ensures that. Does anyone have any insight?
The article shouldn't have used the term SSL Certificate. SSL is the Secure Sockets Layer (which was superseded by TLS many years ago). SSL and TLS define the handshake that is used to negotiate encryption on a connection.
Enabling SSL on a web server required you to have a certificate to verify your server's identity and so this became known colloquially as an "SSL certificate".
While it isn't often used on the web, in SSL/TLS both parties can present a certificate so that there is mutual authentication.
What you typically have is actually an x.509 certificate. This is the case with the push notification service.
An x.509 certificate contains some information including the identity of the certificate holder, their private key and a signature from a trusted party that can be used to verify the information.
For push notifications, the developer generates a certificate request and submits this to Apple who sign it with their private key. Apple is the trusted party in this case.
When this certificate is subsequently presented to Apple's server they can verify that signature using their public key to confirm the identity of the connecting party.
You have has encrypted the message with their private key (Apple can decrypt it with the public key included in the certificate).
What this means is, that as long as the developer has kept their private key secure (which is why you wouldn't connect directly to the push service from your app, for example) then Apple can be sure of the identity of the server making the connection.
If someone was trying to impersonate your server then, as long as you have kept your private key secure, they can't encrypt the data properly. If they use a forged certificate that uses a public/private key pair known to them then the signature on the certificate won't be valid and Apple will reject it.
I'm trying to figure out how trust anchors play a part in the PKI. I understand that it's the root of the certificate chain and is used to validate if a certificate is trusted or not. How does it validate a certificate? (eg. how does it use a public key and the certificate chain to validate a certificate?)
A certificate binds an identity to a public key.
Suppose you get a digitally signed email from me. If you validate the signature with a public key in your possession, then as long as you trust that people are keeping private keys private, you know that email came from someone who had the private key corresponding to that public key.
If you know for sure that the public key you have is mine (e.g. because I handed it to you personally) then that's all you need to know. The problem is you don't always know that. Anyone can create a key pair and sending the public key all over the internet falsely claiming to be me, or set up a web server falsely claiming to be StackOverflow, or whatever else. You could find out Google's phone number from an independent source and call them up to confirm you've got the right key, but if you had to do this every time you wanted to make a secure TLS connection then e-commerce would be considerably more inefficient than it is now.
One solution is to get hold of a certificate. This contains a public key and identity information (e.g. name and address, domain name, email address) that is digitally signed by a certificate authority. If you validate the signature in the certificate with the certificate authority's public key, then you know that someone who has access to the certificate authority's private key was happy to sign a certificate stating that they agree that that identity goes along with that public key. If you trust that the certificate authority is not to do that unless it's taken reasonable steps to verify that that's true (e.g. by making sure they see the individual's personal identity documents, and verifying that that individual has the private key corresponding to the public key that's going to appear in the certificate) then you can trust that you have the right key for the right individual.
But even if you have that trust, this just pushes the problem one step up the chain, because to validate the certificate in the signature with the certificate authority's public key, you first need to be sure that you have the right public key for that certificate authority. So you might get a certificate for that certificate authority, and find that it's been issued by a different certificate authority, and so on.
You obviously can't validate an infinite chain of certificates, so at some point this all has to stop. Eventually you have to verify that you have the right public key for the top-level certificate authority without relying on another certificate to do so, and this is your trust anchor.
So suppose you have a certificate for me, and you see that it's signed by ABC Certificate Authority, a certificate authority that you've never heard of. You get the certificate for ABC and use the public key in it to verify the signature on my certificate, and this proves to you that ABC Certificate Authority really did issue my certificate.
Then you look at ABC Certificate Authority's certificate, and you see that it's signed by DEF Certificate Authority, a certificate authority that you do trust and for which you already have a self-signed certificate, or trust anchor. You use the public key in DEF's certificate to validate the signature in ABC's certificate, and this proves to you that DEF really did issue that certificate for ABC.
To be sure that my certificate is valid, you therefore need to do a few things and make a few assumptions:
You need to get and trust a (self-signed) certificate for DEF Certificate Authority, which is your trust anchor. In most cases your browser and/or operating system will come pre-loaded with a bunch of CA certificates that the manufacturer has decided to trust, and you'll just blindly trust the manufacturer's judgment on that, but you can take your own steps to validate that trust yourself if you want to.
You need to have confidence that DEF is a legitimate and trustworthy certificate authority that's going to keep its private key secure and isn't going to issue certificates to anybody unless it has good reason to do so. Again, you'll most likely trust the manufacturer on this one, but most CAs undergo regular audits of their certificate issuance processes and controls, so if you're concerned you could get hold of the last audit report for that particular CA, for example. Note that doing this requires that you trust the auditor's judgment, so whichever way you go, at some point you have to trust somebody just because they're trustworthy.
You need to have confidence that DEF wouldn't issue an intermediate CA certificate to ABC Certificate Authority unless it had good reason to believe that ABC was also a legitimate and trustworthy certificate authority that's going to keep its private key secure and not issue certificates without a good reason. Here you don't trust ABC directly - you trust it because DEF trusts it, and you trust DEF.
This same logic applies if there are more than one intermediate CA certificates in the chain between the trust anchor and the end-user certificate - you're effectively trusting every intermediate CA in the chain on the grounds that the preceding CA in the chain wouldn't have issued them their CA certificate unless it was satisfied they were a trustworthy CA and unless it had validated that the public key in the intermediate CA certificate really did belong to that intermediate CA. By validating the signature in each intermediate CA certificate with the public key of the CA immediately before it in the chain, you demonstrate that the preceding CA really did issue that certificate. Since you explicitly trust the root CA, then if your trust anchor is found to be at the bottom of that chain then you've built an implicit chain of trust that gives you confidence that the end-user certificate you were originally interested in is good.
Ultimately it's all based on the idea that you just explicitly trust a handful of well-known root CAs, and then you can implicitly trust any of the billions of other identities on the internet if you can find a chain of valid certificates going back to one of those roots that you explicitly trust and if you're willing to accept the notion that every intermediate CA in that chain is trustworthy on that basis.
The reality is that certificate authorities are usually very careful about issuing intermediate CA certificates, and when issuing them to third party organizations often restrict them, so that an intermediate CA certificate issued to ACME Inc may only be used to issue certificates for ACME Inc employees, or to issue certificates only for domains that end with .acme.com, for example.
Trust relationship, trust chain, and trust anchor
A trust anchor has to do with how a trust is established during a secure transaction, as when going to a secure website, for example. When a website presents a certificate to you, how do you know you can trust this certificate? Well, because it's signed by another certificate which belongs to an entity you trust as a Certificate Authority (CA). (More on signatures and verification below.) But how can you trust the CA certificate? Because it was signed by yet another certificate belonging an entity you trust. You can repeat the steps of asking the same question about this entity and getting the same answer about yet another signer, until you get to a certificate which was not signed by another certificate. In fact, it's a self-signed certificate. This is called the root certificate. So, how do you know to trust THIS certificate? The answer is you just do, usually because it's bundled with your browser or other software when you install it or you just accept that you trust this cert. This set of related certificates with the CA certificate, signed by another certificate, signed by another certificate . . . signed by the root certificate, is called your trust chain and the root certificate is the trust anchor because it's trust is not derived from another certificate; it's just accepted as being trusted, whereas all the other certificates directly or indirectly derive their trust from the trust anchor.
What is a digital signature and how is it verified?
Asymmetric Keys --
There are a pair of digital encryption keys associated with digital certificates. This pair consists of a public and a private key which have a special relationship to each other. Something encrypted by a public key can only be decrypted by the private key and vice versa. "Asymmetric" refers to the fact that if one is used for encryption, the other must be used for decryption as opposed to a single key being used for both encryption and decryption. The private key, as the name implies, is kept private by the entity to which the certificate is issued, but the public key is available to anybody and in fact, it's included with the publicly available certificate. An Asymmetric key pair makes digital signatures possible as well as PKI in general.
Hash (Digest) --
Another concept in understanding a digital signature is a hash or a digest. A hash function takes data of an arbitrary size as its input and produces a fixed size representation of this data as its output. This output is known as a hash or a digest of the data. A sophisticated hash algorithm, such as MD5, produces a hash value which has the following properties:
Given the same data and same hash function, the product is always the
same hash value every time.
Two different sets of data will almost never produce the same hash. In fact, even if there is a small change to the data, the two hash values will be completely different from each other.
Not pertinent to this discussion, but as a general note, the original data cannot be derived from the hash. For this reason, a hash is sometimes also known as a one-way encryption.
Creating and verifying signatures --
A signature can be created by taking a hash of a document such as a certificate and then encrypting the hash using the signer's private key. So, a signature is just an encrypted hash. A Certificate Authority (CA) creates a digital signature for a PKI certificate using the CA certificate's private key. The signature is always included with the PKI certificate.
To verify a signature the verifying entity, such as the browser, would:
Un-encrypt the signature on the PKI cert using the signer's public key which gives you the hash of the PKI cert
Create another hash of the certificate
Compare the un-encrypted signature and the hash you just created for the same certificate. If they are the same, the signature has been verified.
So, because you can un-encrypt the signature using the signer's public key, you know that it could only have been encrypted with the signer's private key, and therefore unless the private key has been compromised, the only entity who could've signed the certificate is the CA to which the signing cert belongs.
And because you created your own hash of the same data with the same hash algorithm and it matches the un-encrypted signature, you know that the signature was created from the cert you're trying to verify and that it hasn't been tampered with.
In summary, you've established this is a valid cert because it's signed by an entity you trust because that entity's certificate is signed by an entity you trust and so on, until you reach the trust anchor (the root) which you trust by acceptance.
Hope this answers both your questions.
If my company's server leaf certificate expires and they are creating new certificate with different new Public key as per CA and its policies.
Hence I can only pin certificate rather than public key or SPKI ?
Doing so i know i have to update the new certificate in app and push to users but it won't work for old version users. Any suggestions to avoid this problem?
I'm trying to understand what the certificate is. I'm talking about the .cer file.
In the description it sounds like it is a public key but if it is, than why do I need Certificate Signing Request (CSR) when creating it?
Everywhere I can find "what is a developer certificate for" and so on, but there is no information what the certificate — as an entity — is.
So my questions are:
What is .cer file? (Not .p12)
What is the difference between certificate and public key?
1) The .cer is an commonly used extension for certificates.
Certficates are digitaly signed and encoded documents. To my understanding certificates are documents which contain data (strings etc.) and are encoded. Simply put it is a container for sensitive data.
For details read: DER vs CRT vs CRM vs PEM
2) The public key simply put is a value (String for example). This value is stored in a certificate .cer file.
For better understanding this video might help: Private and public key
The difference is that a certificate can contain a public key but a public key cannot contain a certificate.
A certificate certify who you are, its a kind of identity card or passport or whatever. A public key is something used to secure something, somehow like a real key closes a safety box not to let everyone have look inside.
Then you may have the need to certify that a public key is the one it claims. A certificate is (normally) obtained from another trusted authority (like your passport is delivered by a legal entity). If not how would you trust a public key I'll give to you? It can be a hacked public key, but if you have a certificate that belongs to it, then (if you trust the authority) you'll know it's really mine and not a forged one.
You may read Public Key Certificate on Wikipedia for example.
.cer files are certificates in some well defined format.
In my iPhone app I'm using an https connection with a self-signed SSL certificate to download sensible data (username and password) from a server.
This app is for private use only, it is not meant for production.
I'm using AFNetworking to manage the https connection but, since my certificate isn't signed from a CA, in order to make it work I had to add the following to the header of the AFURLConnectionOperation class:
#define _AFNETWORKING_ALLOW_INVALID_SSL_CERTIFICATES_ 1
But with this my app will allow any certificate.
Is there a way to allow only the certificate from my server maybe bundling it in the app and comparing it with the certificate provided by the server in the https connection?
And if it were possible, would there be any significant advantage in terms of security?
I'm very new to security and I'm kind of confused.
The term you're looking for is SSL Pinning, where the app verifies that a known certificate or public key matches one presented by a remote server.
AFNetworking supports both pinning with certificates or public keys. You'll need to add the certificate(s) or public key(s) to your app's Bundle, and enable the feature by setting either the defaultSSLPinningMode property on AFHttpClient or the SSLPinningMode property on AFURLConnectionOperation.
You can pin using AFSSLPinningModePublicKey or AFSSLPinningModeCertificate. AFSSLPinningModeCertificate means that the server's certificate must exactly match one of those in the bundle.
AFSSLPinningModePublicKey is more liberal and means that the server's certificate must match for any public key in the bundle, or any public key attached to certificates in the bundle.
There's an example of setting the pinning mode in the AppDotNet example.
To expand a bit on David's answer with respect to AFSSLPinningModePublicKey versus AFSSLPinningModeCertificate. Ideally, you would pin the public key and not the certificate. That's because some sites and services, like Google, rotate their certificates every 30 days or so. But they re-certify the same public key.
The certificates are rotated frequently to keep the size of the CRL small for mobile clients. But they re-certify the same public key (rather than creating a new one) to allow for key continuity testing.
Public key pinning is why tools like Certificate Patrol miss the mark. The certificate is expected to change; the public key is not.
Public key pinning is a lot like SSH's StrictHostKeyChecking, if you are familiar with it.
OWASP has a write-up on it too at Certificate and Public Key Pinning.