I am trying to proxy a mobile app (with Fiddler), which sends a client certificate to the server it connects to. I would think that capturing traffic with Tcpdump, retrieving the client certificate and using it with fiddler would be enough to bypass this.

However, when I capture packets using Tcpdump without a proxy, I notice that the server sends some certificates, asks for a client certificate, and the client sends an empty certificate (certificate's length was 0). After the whole SSL process, application data is sent normally, and the app works fine after that. The fact that a certificates length 0 is accepted made me think that any certificate would be accepted, but this does not seem to be the case.

I do indeed pass a fake certificate to Fiddler, and I see a similar entry again (certificates length 0), such that makes me think that I am missing something on how the client sends the certificate.

After the SSL process, I get a server Encrypted Alert and the app won't work at all. So, I am wondering, why do I get a 0 certificate's length even though I send a certificate? Even if fake, shouldn't I be seeing it in Tcpdump?

1 Answer 1


In TLS, after presenting its own certificate, the server may ask for a client certificate (CertificateRequest message). The request contains the list of the CA names that the server will use to validate the certificate. The client must then respond with a Certificate message containing a matching certificate: the client will scan the certificate it owns for one which has been issued, directly or indirectly, by a CA whose name is one of the names specified by the server.

If the client does not have a matching certificate, then it must send a Certificate message with an empty list (which is what you observe)(in SSL 3.0, in that situation, the client omitted the Certificate message altogether, but since TLS 1.0 an empty Certificate is mandated).

When the client does not present a certificate, it is up to the server to decide what to do next. The server may accept the connection nonetheless. In IIS configuration, that's the difference between "request certificate" and "require certificate". Among possible behaviours, the server may accept the connection at the SSL level, and then fall back to an application-level authentication protocol within the tunnel (that, from the outside, would appear as "encrypted application data").

Therefore, either you do not have a matching certificate on the client side, or the client does not notice that his certificates are matching, e.g. for lack of an intermediate CA (in the case root -> intermediateCA -> end-entity, and the server sends the name of the root, but the client knows only "end-entity").

  • that totally makes sense, i was thinking on similar lines, but the problem is that there's no other authentication happening. I do see a 0 length cert sent, so it seems as if the client cannot find a cert. It does work though when not using a proxy but does not when i do use one :/
    – Spyros
    Commented Jul 23, 2013 at 14:09
  • The behavior is that the app hangs when a proxy is used. I have tcpdumped both situations and both times a 0 cert is sent. The only difference is that when proxied, no application data is sent, only an encrypted alert, and the app hangs. I am wondering whether this is some kind of protection.
    – Spyros
    Commented Jul 23, 2013 at 14:13
  • Might you need the server cert, and not the client cert then?
    – schroeder
    Commented Jul 23, 2013 at 21:08
  • no, i have already bypassed the server cert, this is a client cert needed here.
    – Spyros
    Commented Jul 24, 2013 at 5:01
  • +1, server asked for RSA Sign, does this mean, the certificates i placed in client is not signed with respective ca, the same which is used to sign server cert?
    – Farhan
    Commented Nov 20, 2016 at 8:14

You must log in to answer this question.

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