I recently encountered a scenario where Mobile Application is generating CSR request, call a POST API request and in response, Ask Server for certificate. Server will respond with the temporary certificate and Mobile Application will use that certificate for further API communication to prevent MiTM. This certificate will change at every login request.

as you folks might have already figured it out, SSL Unpinning won't help here because even if client trust any certificate , server won't..

As part of security testing , I want to test this API request in Burp Suite but failed to do so because without that certificate server will respond with 500. I am familiar with Client TLS setting in Burp but for that we need PKCS12 certificate with password which we don't have. I have a public key of that request certificate which mobile application is sending but i don't know how to give that publickey to burp.

Any thoughts??

2 Answers 2


You need the client's private key too (not just the certificate, which contains the client's public key).

You'll probably need some amount of client-side instrumentation (e.g., using Frida) to obtain the private key. You can use instrumentation to dump the client key pair from memory at run-time, or it might be saved to disk in the app's private storage. Once you obtain the keys, you can use them to create a P12 file that you can load into Burp.

Note that you'll either need a rooted device or a modified APK to use Frida.


An option that might work here:

  1. Stop the client request that contains the CSR.
  2. Generate your own key pair and CSR, with a private key that you know (lots of tools for this, e.g. openssl).
  3. Edit the request in Burp to replace the app-generated CSR with your own.
  4. Send the edited request.
  5. Capture the response, which should contain the signed certificate.
  6. Set that certificate, and the corresponding private key from the key pair, as Burp's client cert for the server.
  7. Send the response to the app.

This won't work (without further efforts) if the app checks that the certificate it received from the server matches the CSR it sent, or notices that Burp isn't demanding a client certificate when the real server would. However, the app likely either just trustingly uses the cert, or at best verifies that it was issued by the server's CA; in those cases, this would work.

If that doesn't work, you'll need to do something more complex. One option is simply modifying the app to not use the client cert, which should work fine because Burp is doing so, but is probably a non-trivial change since conventional pinning-removal tools probably won't suffice. The other option is to set Burp up as a full client-cert MitM as well as server-cert MitM. That would look like this:

  1. Capture the app's login request; you may need to replay this later.
  2. Capture but don't modify the app's request containing the CSR; forward it unmodified.
  3. Similarly, forward the cert response back to the app.
  4. While the app is logged in, perform steps 2-6 above using e.g. Burp Repeater.
    • You may need to start a new login session on the server, assuming that won't sign you out of the current one; replay the login request for this.
    • You do not want to send this cert (the one generated from your own key pair) to the app.
  5. If necessary, set up Burp to expect a client certificate (no need to validate it), but not pass it along to the server (it should use your own cert+privkey from above). I don't think this is needed. I'm also not sure how to do it if it is, though.
  6. Let the app resume using the session it already established, where it communicates with Burp using its own client cert (which is valid, but which stops at Burp and which Burp ignores) and Burp in turn communicated with the server using your client certificate (which is also signed by the CA but which the app would not recognize, fortunately the app never sees it).
  • thanks for ans. but as I have pointed out in question (might not be clear that much but), in my case, client (mobile app) is not verifying certificate but Server is . it means even if I generate my CSR and certificate , server will not give response for that API. Server will check certificate which client is sending and then give the response. For me challenge is to use BURP + server certificate. causefrom burp side there isn't option other than PKCS12 to give server cert along with Request. if I want to convert this Server cert to PKCS12 , i need private key which i don't have. Apr 14 at 7:11
  • I think you misunderstood. Why wouldn't the server give you a "temporary" cert, that it trusts, in response to your request that contains a CSR? If the problem is that the app also has a permanent client cert, then you need to extract the private key from the app, but you don't say anything about a permanent client cert, only the temporary one, and by necessity the API to request that temp cert can't, itself, require the temp cert or the app would never be able to get authorized in the first place!
    – CBHacking
    Apr 14 at 7:43

You must log in to answer this question.

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