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.