1

I'm having a hard time accessing sites with HSTS enabled via burp proxy in Chrome. Everything works perfectly fine with Firefox and IE, but Chrome has stopped working since yesterday.

I've followed all the instructions went through all the available documents and have reinstalled the certs and all but no luck.

Screenshots with details about the errors:

Connection Error

Chrome Config

As I mentioned, it works fine with Firefox and IE but not with Chrome.

Improve this question
7
  • Try to reinstall Burp's cert. Or try to reinstall Chrome again.
    – OscarAkaElvis
    May 3, 2017 at 6:41
  • Yeah did that already but still no luck OscarAkaElvis :( It started from yesterday, everything was working like a charm before that!
    – Prateek T
    May 3, 2017 at 6:58
  • You say that "Chrome stopped working", then show a screenshot of connecting to www.google.com failing. What happens if you connect to some other HTTPS site that isn't as associated with Google as Chrome is? How about stackoverflow.com or security.stackexchange.com, for example?
    – user
    May 3, 2017 at 8:02
  • I meant Chrome has stopped rendering the HTTPS sites, any site which is not on the secured layer works fine, but all the sites with HTTPS are giving this error. Thanks Michael, do let me know if there are any solutions? the last option would be to run the cmd to ignore ssl.
    – Prateek T
    May 3, 2017 at 8:06
  • Is the Burpsuite Certificate using a SHA-1 hash? Chrome has stopped trusting those, so your issue may be related to that.
    – Dan Landberg
    May 3, 2017 at 15:33

1 Answer 1

Reset to default
3

This is probably due to a change in Chrome 58 which now requires SAN:

Remove support for commonName matching in certificates

RFC 2818 describes two methods to match a domain name against a certificate: using the available names within the subjectAlternativeName extension, or, in the absence of a SAN extension, falling back to the commonName. The fallback to the commonName was deprecated in RFC 2818 (published in 2000), but support remains in a number of TLS clients, often incorrectly.

The use of the subjectAlternativeName fields leaves it unambiguous whether a certificate is expressing a binding to an IP address or a domain name, and is fully defined in terms of its interaction with Name Constraints. However, the commonName is ambiguous, and because of this, support for it has been a source of security bugs in Chrome, the libraries it uses, and within the TLS ecosystem at large.

The compatibility risk for removing commonName is low. RFC 2818 has deprecated this for nearly two decades, and the baseline requirements (which all publicly trusted certificate authorities must abide by) has required the presence of a subjectAltName since 2012. Firefox already requires the subjectAltName for any newly issued publicly trusted certificates since Firefox 48.

The solution to this is to regenerate the certificate on the server showing the error, or as in your case - the Burp cert.

Improve this answer
1
  • Yeah I did find that and resolved the same day, but marking it as resolved for others to follow the same methodology. Thanks @WoJ!
    – Prateek T
    May 4, 2017 at 16:15

You must log in to answer this question.

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