Burp Suite User Forum

Create new post

Invalid certificate generated

Jonathan | Last updated: Aug 01, 2021 04:15PM UTC

The certificate generated contains a country code of PortSwigger which does not conform to the RFC which says that the country code should have a length of 2 https://datatracker.ietf.org/doc/html/rfc3280#page-96 This results in the python crypto library not working when trying to read the certificates. Here are two related issues, one in the python crypto library, and another in mitmproxy which I was trying to use when I discovered the issue. https://github.com/pyca/cryptography/issues/3857 https://github.com/mitmproxy/mitmproxy/issues/4713

Michelle, PortSwigger Agent | Last updated: Aug 02, 2021 01:00PM UTC

Thanks for your message. We've raised this with the team on your behalf and have linked this thread so we can post back here with any updates. In the meantime, you could create your own certificate with a valid country code and import that for Burp to use. I hope that helps, please let us know if you have any questions.

Quinn | Last updated: Oct 28, 2021 11:39PM UTC

Hi Michelle! This is an issue my team is running into with a number of Burp Suite Professional users who are trying to use Burp alongside other tooling, so I just wanted to bump this thread with another sample. In particular, the Erlang programming language requires that the country code is exactly 2-characters, and the Erlang team considers this behaviour to be a non-bug, and so any tooling that is built in Erlang or Elixir is failing in the same way. More info here: https://bugs.erlang.org/browse/ERL-668 We're able to workaround the problem by recommending that these users use their own certificate, however a nicer out-of-the-box experience would be really appreciated! Thank you!

Ben, PortSwigger Agent | Last updated: Oct 29, 2021 10:24AM UTC

Hi Quinn, Thank you for the further information. I have added this information to the request that Michelle initially created in our development system so that our developers are aware of it. As Michelle previously noted, we will update this forum thread if we have any further news to share about this feature.

Simon | Last updated: Jun 26, 2023 03:55PM UTC

Hello, I also subscribe to this issue. Android interception doesn't work anymore as it should due to this bug. We lost a lot of time to nail down the TLS "fatal alert: certificate_unknown" error shown in the Dashboard to this countryName field issue.

Ben, PortSwigger Agent | Last updated: Jun 27, 2023 07:08AM UTC

Hi Simon, Are you able to clarify which version of Android you are using and how you are installing the Burp CA certificate on the Android device?

Simon | Last updated: Jun 27, 2023 03:42PM UTC

Hi Ben, Issue encountered on Android 12 and 10. Burp CA is installed first as a user CA through Android Settings UI, then automatically elevated as a System CA through a Magisk module (which itself relies on mount points as /system is not writable). The certificate correctly appears among the System CA. When using the certificate automatically created by Burp, TLS handshakes systematically fail with errors shown in Burp dashboard: mostly "fatal alert: certificate_unknown", a few "fatal alert: unknown_ca". The WiFi connection is detected as limited by the device, Playstore won't work, etc. I then manually created a certificate mostly identical to the one generated by Burp, the only change being the countryName (cn) field being set to a two letters value (as per RFC requirements, see the first post). I imported this certificate in Burp, installed it on the cellphone using exactly the same process as above, then the HTTPS interception suddenly works flawlessly.

nobug | Last updated: Jun 27, 2023 04:46PM UTC

Hi Ben, I am sorry to insert irrelevant msg to this thread. This is because I want to report a bug about the new UI of Web Security Academy Learning Materials, but when I try to create a new bug post here, I failed as the js file of google reCAPTCHA failed in loading because of CSP, maybe another bug :{

Ben, PortSwigger Agent | Last updated: Jun 28, 2023 11:20AM UTC

Hi Simon, Just to clarify, are you seeing this issue with browser based traffic or app based traffic (or both)? If it is browser based traffic, which browser do you normally use?

Ben, PortSwigger Agent | Last updated: Jun 28, 2023 11:21AM UTC

Hi nobug, Please feel free to email us directly at support@portswigger.net with any feedback about the new Web Academy UI.

Simon | Last updated: Jun 28, 2023 01:16PM UTC

Hi Ben, This issue affects primarily App based traffic interception (browsers by default raise different issues which are unrelated to this topic and not linked to any bug). It can notably be observed with Android and Google default applications: - Connectivity check fails (the internet connection is detected as "Limited"). - Playstore won't work, other Google apps such as Youtube won't work either. On Burp side only plain HTTP traffic is intercepted (mainly HTTP 204 page requests) and HTTPS traffic fails with TLS errors on the dashboard. Once the certificate's countryName field is fixed everything above functions correctly and is correctly intercepted by Burp.

Ben, PortSwigger Agent | Last updated: Jun 29, 2023 09:00AM UTC

Hi Simon, Thank you for the additional information. We can add this detail to the existing development ticket that we have.

Simon | Last updated: Jun 29, 2023 03:06PM UTC

Thanks Ben. Is there any visibility on the resolution date for this issue? It is two years old already and changing the countryName doesn't seem very complex or likely to have any negative impact. It would save Burp users from loosing time and their sanity ;). Otherwise, would it be possible to update the "Configuring an Android device to work with Burp Suite Professional" procedure (https://portswigger.net/burp/documentation/desktop/mobile/config-android-device), which doesn't work in its current version, to mention that it is required to replace the automatically generated CA certificate with a manually created one ?

Ben, PortSwigger Agent | Last updated: Jun 30, 2023 12:59PM UTC

Hi Simon, We cannot really provide an ETA for any given issue or feature. Any bug/feature request goes through a triage process whereby the impact and level of work required are assessed before commitment to carrying out work on whatever the item is. It sounds like, in terms of getting something done quickly, that altering the documentation might be the way to go in the immediate future. I can talk to the content team to see if we can get this in place for future reference.

Simon | Last updated: Jul 04, 2023 08:59AM UTC

Hi Ben, Thank you for your feedback.

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