2

To implement Cert Pinning on a native mobile app on (e.g. iOS), a new API end-point is being established (e.g. api.example.com). This URL will be setup with a self-signed SSL certificate.

This API end-point URL is meant to be consumed only by this mobile app (and not via Web or other UA). On the mobile app, the "cert not trusted" warnings, if any, can be transparently suppressed to make it seamless for the mobile user.

Is the Cert Pinning validation on mobile app sufficient for the security of data-in-transit (with self-signed cert)?

Do we really require a public SSL certificate in this scenario?

Would a public SSL cert add additional value from a cryptographic standpoint to mitigate MITM (one of the goals of cert pinning)?

Puneet
  • 43
  • 4

1 Answers1

1

A certificate is used in TLS for making sure that the client talks to the correct server and not some man in the middle. To check the certificate the client either has to know exactly which certificate to expect or has to find another way to trust the certificate. In a typical setup with web browsers as clients it does not scale to distribute the expected certificate in a secure way to all clients and thus a PKI is used instead where the browser does not trust the certificate directly but it trusts the certificate because it trusts the issuer and the subject of the certificate matches the URL.

But in your case of a mobile app you actually can distribute the knowledge about the certificate with the application. In this case it is enough to have a self-signed certificate and pin to this certificate or its public key. But note that you cannot simply revoke the certificate in this setup in case it gets compromised. If you need this it might be easier to use the existing mechanism with public CA in addition to pinning.

Steffen Ullrich
  • 201,479
  • 30
  • 402
  • 465
  • Thanks Steffen. Since both the server side and the mobile app side certs may be rotated as required, that could be the way to go with revocation. – Puneet Feb 03 '17 at 00:01