Burp Suite User Forum

Create new post

Proxy not working as expected with certificate-enabled website

Andy | Last updated: Feb 28, 2019 01:15AM UTC

Hi all, So I have a website that I'm attempting to delve into...let's call it "https://stupid.com/target". The website requires a selected client certificate when you first visit the page (which I have imported into the user options). Without the proxy enabled within Internet Explorer, I can visit the website, be prompted for my certificate, and then browse normally. As soon as I enable the proxy within my browser, I can no longer browse any part of the website, even if I get past the certificate first. I have tried with Interception on, and off. I also notice that no scanning options work either. The target is inside of the scope in the options.

PortSwigger Agent | Last updated: Mar 01, 2019 12:12PM UTC

You need to configure the client SSL certificate within Burp. There are instructions here: - https://portswigger.net/burp/documentation/desktop/options/ssl#client-ssl-certificates

Burp User | Last updated: Mar 02, 2019 07:07AM UTC

Hi Paul, I had already imported the client SSL in Burp's User options. I'm using a hardware token and have confirmed that it has been stored as PKCS#11 with my PIN. Since my computer is located behind a web proxy (and my target is most likely on the other side of that proxy), I have even tried configuring my web proxy as an upstream within the User options as well, but no luck there either. It seems like my traffic is getting flatly denied, even with my client certificate imported.

PortSwigger Agent | Last updated: Mar 04, 2019 08:23AM UTC

Hi Andy, sorry you did say say you had imported that. Doing a site that requires an upstream proxy and a client certificate will be tricky at first. Can I suggest you break this up. First, find a site that requires the upstream proxy, but no client certificate. Get this working; become accustomed to how that works in Burp. There's information here: - https://support.portswigger.net/customer/portal/articles/2363078-burp-suite-options-upstream-proxy-servers Once that's working, try configuring the client certificate.

fostercarly | Last updated: Nov 01, 2022 05:56AM UTC

The 400 (Bad Request) status code indicates that the server cannot or will not process the request because the received syntax is invalid, nonsensical, or exceeds some limitation on what the server is willing to process. It means that the request itself has somehow incorrect or corrupted and the server couldn't understand it. The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method . Therefore, it prevents the website from being properly displayed. The main thing to understand is that the 400 Bad Request error is a client-side error. The cause of 400 Bad Request error can be a wrongly written URL or a URL that contains unrecognizable characters. Another cause of the error might be an invalid or expired cookie. Also, if you try to upload a file that's too large. If the server is programmed with a file size limit, then you might encounter a 400 error. Expired Client Certificate This issue typically happens for a 2-Way TLS, when the certificate sent by the client is expired. In a 2-way TLS, both client and server exchange their public certificates to accomplish the handshake. The client validates the server certificate and the server validates the client certificate. During the TLS handshake if it is found that the client certificate is expired, then the server will send 400 - Bad request with the message "The SSL certificate error". The solution for this problem is that procure a new certificate and upload the certificate http://net-informations.com/q/mis/400.html

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.