I'm writing an iOS app for private use to act as a client for a PHP server. To secure the connection I'm using a self-signed SSL certificate.

Since the server is self-hosted, on the first connection inside my LAN I could be pretty sure that no MITM attacks were happening. So I saved in a file the certificate that the server sent to the client and then I bundled the downloaded certificate inside my app to check on every connection if the certificate sent by the server and the one bundled in my app were the same (SSL Pinning basically).

I know very little about MITM Attacks and security in general so my question is the following: could an attacker download the certificate (like I did) from my server and use that certificate to pretend to be the server and perform a MITM attack? Or am I misinterpreting the way man-in-the-middle works?

  • 1
    @BibLex - they could just sign a new certificate....with exactly the same information if they wanted. If you are that worried get a CA signed certificate.
    – Ramhound
    May 23, 2013 at 0:34
  • 2
    @Ramhound: An attacker could not sign a new certificate such that it is both binary identical to the original certificate, and the attacker has access to the corresponding private key. Hence, the important question is how certificates are verified and compared. May 23, 2013 at 0:55
  • @HenrickHellström - I understand that. The point of my comment is that if the author is worried about MITM attacks a self-signed certificate won't protect his users, since there is no way of knowing, if the certificate your using is actually the author's or not. The only saving grace of the author's is that the application would reject this "clone" certificate as not being the same, if were to say, be replaced on the server. If its a matter of trust the author is worried about ( and MITM attacks are exactly that because a lack of trust ) a CA signed certificate is the way to go.
    – Ramhound
    May 23, 2013 at 10:57
  • 3
    @Ramhound: Embedding the self signed certificate of the server in the software, is in principle sufficient for ensuring that the certificate sent by the server indeed belongs to the author. What you loose is the ability to transparently updating the server certificate. One might actually argue that letting a server authenticate itself to an iOS app using a commercial certificate, would introduce a vulnerability, since it is way too hard for the user to verify which CAs the device actually trusts. May 23, 2013 at 11:10
  • @HenrickHellström - You make some valid points.
    – Ramhound
    May 23, 2013 at 11:24

3 Answers 3


It is not the certificate that matters, but the private key. That one does not leave the server! To impersonate the server, the man in the middle would need to obtain that private key. The certificate itself is public data, and sent by the server to every client who asks for it by simply connecting.

(A Man in the Middle attack is a double impersonation: the attacker poses as the server when talking to the client, and the client when talking to the server. In simple SSL, with no certificate-based client authentication, the client is nominally anonymous, so mounting a successful MitM reduces to running a fake server that the clients accept as genuine. Fat luck with that, if you don't have the server's private key.)

  • So is SSL Pinning any usefull to prevent MITM?
    – BigLex
    May 23, 2013 at 0:41
  • 2
    To prevent MitM, the client must make sure that it uses the genuine server's public key. Validating the SSL certificate is about exactly that. "SSL pinning" is the simplest form of validation: the client validate the server's certificate by already knowing it. So yes, it works against MitM. May 23, 2013 at 10:49

Actually, depending on how your client implements SSL/TLS and PKI, it might be possible for an attacker to pull off something vaguely similar: For instance, read this page on how eavesdropping on secure connections might be technically possible, if sufficient attention isn't paid to the PKI part of SSL/TLS.

For short: The attacker would generate a root certificate, somehow get your client application to trust it (which is the critical part), and then act as a man-in-the-middle that generates server certificates on the fly, when your client connects to a (the) server.

Edit: Bundling the certificates the software is meant to trust with the application, rather than pulling them from a store the man-in-the-middle might compromise, is in principle sufficient to thwart this vulnerability.


Bundling certs, installing embedded certs, implementations DO NOT MATTER period. If you think this is the case, you're missing the underlying handling of certificates.

When a connection is made via the PKI infrastructure it usually works as follows:

Client (with cert) --> before connection is made, let me consult CA --> Internet
Client (with cert) --> Hey CA is this cert being used valid --> Internet CA
CA --> checks cert information
CA --> Valid cert? --> Yes --> This is a valid cert --> Client
CA --> Valid cert? --> No --> This is NOT A VALID cert --> Client

What occurs with attackers is a) they can replace YOUR valid cert with a STOLEN - SIGNED CERT and the above occurs:

Client (with signed STOLEN cert) --> Let me consult CA --> Internet
Client (with signed STOLEN cert) --> Hey CA is this cert valid?
CA --> checks cert information
(cert was not revoked)
CA --> Yes --> This is a valid cert --> Client

From what I am reading, it if the impression that when a connection is made ONLY the SPECIFIED certificate WILL BE USED and an attacker cannot outright replace that cert. It will take an enormous amount programming to pull that off. In fact, a software vendor would have to program N amount of iterations for each client to pull that off. Otherwise, a cert is a cert is a cert...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .