Me está costando mucho acceder a sitios con HSTS habilitado a través de burp proxy en Chrome, todo funciona perfectamente bien con Firefox e IE, pero Chrome ha dejado de funcionar desde ayer.
He seguido todas las instrucciones, he revisado todos los documentos disponibles y he reinstalado los certificados y todo, pero sin suerte -
Capturas de pantalla con detalles sobre los errores:
Como mencioné, funciona bien con Firefox e IE pero no con Chrome.
Esto probablemente se deba a un cambio en Chrome 58 que ahora requiere SAN:
Eliminar soporte para la coincidencia de CommonName en certificados
RFC 2818 describe dos métodos para hacer coincidir un nombre de dominio con un certificado: utilizando los nombres disponibles dentro del extensión SubjectAlternativeName o, en ausencia de una SAN extensión, volviendo al nombre común. El retroceso a la commonName está en desuso en RFC 2818 (publicado en 2000), pero el soporte permanece en varios clientes TLS, a menudo de forma incorrecta.
El uso de los campos subjectAlternativeName lo deja sin ambigüedades Si un certificado está expresando un enlace a una dirección IP o una nombre de dominio, y está completamente definido en términos de su interacción con Restricciones de nombre. Sin embargo, el nombre común es ambiguo, y debido a esto, su soporte ha sido una fuente de errores de seguridad en Chrome, el bibliotecas que utiliza, y dentro del ecosistema TLS en general.
El riesgo de compatibilidad para eliminar commonName es bajo. RFC 2818 tiene En desuso esto por casi dos décadas, y los requisitos de línea de base (que deben cumplir todas las autoridades de certificación de confianza pública) ha requirió la presencia de un subjectAltName desde 2012. Firefox ya requiere el subjectAltName para cualquier nueva publicación de confianza pública Certificados desde Firefox 48.
La solución a esto es volver a generar el certificado en el servidor que muestra el error, o como en su caso, el certificado Burp.
Lea otras preguntas en las etiquetas tls proxy ssl-interception burp-suite