Actualizar la conexión HTTP a SSL / TLS

Actualmente tengo un servidor que redirige automáticamente todas las solicitudes HTTP al sitio HTTPS equivalente. El problema es que parece que algunos navegadores no aceptan el certificado SSL (StartSSL.com) o no admiten SNI, por lo tanto, reciben una advertencia de Certificado y el usuario no continuará navegando en el sitio web.

¿Existe algún mecanismo que intente hacer que el navegador use HTTPS en lugar de HTTP simple y cuando eso no funciona (por ejemplo, el certificado no es aceptado o SNI no es compatible) continúa usando HTTP.

Actualmente estoy usando Apache 2.4 con múltiples hosts virtuales con los que todos redirigen la conexión HTTP Redirect / https://domain.example/.

Un navegador nunca debería degradarse por sí solo a http si https no funciona, porque todo lo que un atacante debería hacer es hacer que https no esté disponible (por ejemplo, bloquear el puerto 443). Entonces, la única forma en que esto se puede hacer es instruir al navegador desde el servidor para que lo haga, por ejemplo, enviando una redirección http. Por supuesto, esto debe enviarse a través de una conexión segura (de lo contrario, un intermediario podría fingirlo), pero desafortunadamente es exactamente su problema que la conexión segura falle.

En resumen: No, no es posible y es mejor así.

Por cierto, todos los navegadores modernos admiten SNI, pero no todas las aplicaciones (por ejemplo, aplicaciones Java, etc.) lo hacen. Si tiene varios dominios en el servidor web pero estas aplicaciones solo necesitan uno solo, puede establecer el certificado para este dominio como predeterminado. De lo contrario, necesitaría obtener un certificado (más caro) que contenga todos los dominios necesarios como nombres alternativos de sujeto.

Edite con otra idea: lo que podría intentar hacer es descargar una imagen de su lado como https y verificar el éxito con un controlador onerror en la etiqueta img. Tal vez esto no active una advertencia visible para el usuario, sino que simplemente no se cargue. Y si tiene éxito, sabe que el acceso https es posible y redirige al usuario.

Aparte de eso, debe preguntarse por qué quiere ofrecer https si acepta el acceso con http también. O bien hay datos que deberían protegerse o no. Siempre que ofrezca un respaldo a http, es fácil para un atacante aplicar http en lugar de https.

En primer lugar, debería ser posible especificar un certificado para usar para todos los clientes que carecen de soporte SNI. Esto significa que de todos los dominios alojados en esa dirección IP, puede tener al menos uno de ellos trabajando para clientes sin SNI.

Lo que podría hacer al redirigir de http a https es una redirección de dos etapas. La primera redirección de http a https usa el nombre de dominio, que aseguró que funcionaría con o sin soporte SNI. Debería incluirse la URL original completa, de modo que desde este sitio https pueda redirigirse a la correcta después.

El nombre de dominio, que funciona con o sin SNI, puede comportarse de manera diferente dependiendo de si el cliente admite SNI. De esa manera, sabría que el cliente admite SNI antes de redirigirlo a un dominio, que requiere SNI.

Cómo configurar esto exactamente en Apache va a ser un poco difícil de adivinar (ya que nunca configuré Apache con más de un certificado). Supongo que la forma de hacerlo sería crear hosts virtuales basados ​​en nombres para todos los dominios, incluido el dominio intermedio.

Luego, cree un host virtual predeterminado para clientes sin SNI, que usa el mismo certificado que el que usa el nombre. Esos dos hosts virtuales con un certificado idéntico enviarán diferentes redirecciones a los clientes dependiendo de si son compatibles con SNI.

Finalmente, habilitaría IPv6 en el servidor. Con IPv6, obtiene suficientes direcciones IP para poder asignar una a cada host virtual. El mismo conjunto de hosts virtuales puede tener un nombre basado en IPv4 e IP basado en IPv6, por lo que no tiene que duplicar ninguna configuración de esta manera.

El resultado final sería una configuración que funciona mientras el cliente admita SNI o IPv6. Solo los clientes que no admitan ninguno tendrán un problema, pero aún podrán detectarlos y un servidor diferente o un mensaje de error.

En cuanto a los clientes que no les gusta la CA, mi única sugerencia es reconocerlos por su agente de usuario y manejarlos como parezca apropiado. Asegúrese de tener un enlace al sitio https, en el que pueden hacer clic en caso de que, por error, haya demasiados clientes.

Solo una conjetura: ¿podría ser que no tiene una directiva SSLCertificateChainFile en su configuración de apache que incluye el archivo sub.class1.server.ca.pem que necesita para StartSSL?