No creo que sea una buena idea dejar que los usuarios decidan qué certificados son buenos y cuáles no lo son, o aceptar certificados autofirmados o no válidos en general. Al menos no creo que la mayoría de los usuarios entiendan los problemas subyacentes y puedan tomar la decisión correcta. Pero tal vez todos sus usuarios tengan una comprensión más profunda del tema y de los problemas involucrados al tomar una decisión equivocada, por lo que aquí hay una manera de transferir al menos parte de esta información al usuario:
- Para las conexiones TLS correctas que tienen un certificado válido, el nuevo certificado generado en el dispositivo de intercepción SSL será firmado por la CA proxy del dispositivo. De esta manera, no se producen advertencias en el navegador siempre que la CA proxy se importe como confiable.
- Las conexiones TLS con un certificado no válido (caducado, sujeto incorrecto, autofirmado ...) no estarán firmadas por la CA proxy, pero se creará un certificado autofirmado que contendrá la mayor parte de la información original (sujeto) , caducidad ...). Esto dará como resultado una advertencia dentro del navegador porque no está firmada por una CA de confianza y el usuario puede ver los detalles del certificado y decidir aceptarlo de todos modos.
De esta manera, solo los certificados válidos son aceptados silenciosamente por el navegador y todos los demás necesitan la intervención manual del usuario. Tenga en cuenta que estoy bastante seguro de que no todos los dispositivos de intercepción SSL tratarán con certificados no válidos como lo he descrito, por lo que debe verificar los detalles con el producto o la implementación específica que tiene en mente. Además, no toda la información sobre los motivos por los cuales un certificado no es válido se transfiere de esta manera. Especialmente, no puede distinguir entre certificados autofirmados originalmente y certificados con una cadena de confianza rota (como certificados de cadena faltantes o CA raíz no confiable) de esta manera y no tiene forma de ver al emisor original del certificado.
Pero, una vez más, no recomiendo confiar plenamente en los usuarios para decidir cuáles son los certificados buenos y malos, por lo que esta práctica debe limitarse a solo algunos sitios malos. Según mi experiencia, los únicos certificados autofirmados válidos que tiene son para dispositivos locales (enrutadores, etc.) y, por lo tanto, generalmente no deberían verse afectados por la interceptación de SSL. Los sitios públicos en Internet, en su lugar, deben usar CA públicas y casi todos lo hacen. Si no lo hacen o lo hacen mal, es mejor bloquear estos sitios. Desde mi experiencia, los sitios comunes en Internet no causarán ningún problema porque esto también causaría problemas en los navegadores y perderían a los visitantes de esta manera.