TL; DR Cuando se rechaza una conexión al acceder a un sitio web .mil a través de HTTPS repetidamente en Internet Explorer, primero el inicio de sesión en Chrome permitirá que IE se conecte cada vez que lo haga. ¿Por qué es esto?
Realizo el servicio de TI en una universidad para el cuadro estadounidense de ROTC. Así que los miembros del servicio militar en servicio activo en una red no militar, a menudo tenemos que encontrar algunas soluciones alternativas debido a esto. Uno que ha surgido con frecuencia para el Ejército es cuando intenta acceder a AKO ( enlace ) en Internet Explorer y Windows 7 ( no probado en win10) a veces arrojará un error y no se conectará, desafortunadamente no recuerdo lo que dice el error específico, pero creo que es un error de conexión de IE. En cualquier caso, la solución para esto consistentemente es ir a AKO en Google Chrome, iniciar sesión en el sitio de esa manera, luego con Chrome aún abierto, acceder a AKO en IE y funciona.
Más recientemente, un solo usuario en Windows 10 (imagen nueva, ocurrida desde el inicio) en la Fuerza Aérea recibió repetidamente el error, pero quizás más del 80% de las solicitudes,
No se puede conectar de forma segura a esta página. Esto podría deberse a que el sitio utiliza configuraciones de seguridad TLS no actualizadas o inseguras.
Por un capricho (y después de intentar cada variación de las opciones de SSL3.0 / TLS1.0 / TLS1.1 / TLS1.2) probé la solución alternativa de Chrome y funcionó de nuevo de manera consistente. Mis notas de este incidente:
-
Inicia google chrome
-
Vaya a enlace
- Iniciar sesión con los usuarios CAC
- Ejecutar Internet Explorer
- Ahora se podrá acceder a todos los sitios * .af.mil, ya que Chrome ha creado la conexión TLS requerida y IE puede ser parte de esto.
He estado usando esto por mucho tiempo pero nunca se me ocurrió por qué / cómo esto funciona. Supuse que la sesión TLS fue generada esencialmente por Chrome y luego IE se retiró de ella. Encontré esta respuesta: ¿El cifrado en HTTPS se realiza mediante el navegador o el sistema? que menciona que IE utiliza un API del sistema operativo que, en mi opinión, apoya esta teoría: / p>
Si especifica https: //, entonces el navegador se responsabiliza del cifrado. Algunos navegadores utilizan las API proporcionadas por el SO (mirando IE aquí)
Por otro lado, esta publicación parece indicar exactamente lo contrario:
Las sesiones HTTP y las sesiones SSL son entidades diferentes y no hay asignación de una a otra.
Una vez más, podría ser completamente incorrecto acerca de esta teoría, solo espero que alguien pueda explicar cuál es la verdadera causa de esto para poder entender mejor lo que estoy implementando.