421 Solicitud mal dirigida


11

De vez en cuando aparece el siguiente error 421:

Solicitud mal dirigida

El cliente necesita una nueva conexión para esta solicitud, ya que el nombre de host solicitado no coincide con la Indicación de nombre del servidor (SNI) en uso para esta conexión.

Sin embargo, al actualizar el navegador se borra el error y la página se carga normalmente. La próxima vez que cargue la página no se producirá un error y, como tal, el patrón parece bastante aleatorio. El único patrón que puedo ver es que esto puede suceder cuando estoy redirigiendo una página usando el encabezado ("Ubicación:". $ Url);

Tengo un certificado de dominio múltiple PositiveSSL de Comodo. Mis servidores son Apache en un servicio de alojamiento web compartido, por lo que no tengo acceso a la configuración.

Cargo páginas de un dominio y dentro de la página hay enlaces a un segundo dominio en el certificado.

Todo lo que he leído sobre este error parece indicar que este problema está relacionado con que se trata de un certificado multidominio.

Lo que me gustaría saber es si hay algo en el lado de codificación de la página web (php) de las cosas que puede causar esto (y puede solucionarse) o si se trata de un error de configuración o posiblemente un error del servidor y solo mi servicio de alojamiento puede arreglalo.

Hasta el momento, mi servicio de alojamiento no ha podido proporcionar nada y solicité volver a llamar con la hora exacta que sucede a continuación para que puedan investigarlo. Cualquier ayuda sería apreciada ya que no estoy demasiado seguro de que puedan resolver esto.

ACTUALIZACIÓN Ok, casi un par de años después y decidí que era hora de lidiar con eso. Pude resolver la mayoría de los problemas eliminando mis dominios estáticos que servían imágenes y javascript. Sin embargo, todavía estaba usando un segundo dominio para parte de este contenido y Safari en particular todavía me daba problemas.

Investigué más y encontré otro artículo que habla sobre esto aquí . Exactamente lo que @Kevin describe. El artículo confirmó que sucede en Safari. Entonces, siguiendo el consejo, me puse a obtener certificados separados para cada dominio. Estoy en un host compartido (Webhostinghub) y descubrí que ahora ofrecen SSL gratis (AutoSSL) que se renueva automáticamente. Parecía demasiado bueno para ser verdad. Me prepararon con 5 certificados gratuitos. Hasta aquí todo bien. Incluso puedo intentar volver a habilitar los dominios estáticos para probar. Si todo esto funciona, ahorraré $ para arrancar como un bono y dejaré que mis certificados de Comodo expiren en julio.


¿Está alojando múltiples sitios web en el mismo servidor Apache Y utilizando el mismo certificado SSL Y el error ocurre al cambiar entre estos nombres de dominio?
John Hanley

Si la respuesta es SÍ, verifique si la dirección IP de cada dominio se asigna al mismo servidor virtual. En caso afirmativo, tiene dos opciones (que se me ocurren): 1) Emitir certificados SSL por separado para cada nombre de dominio. 2) Mueva los servidores web para que cada dominio esté en diferentes servidores (diferentes direcciones IP). Dado que está en un alojamiento compartido, la opción 1 es probablemente la mejor solución. Puede probar esta solución usando Let's Encrypt para emitir varios certificados gratuitos para instalar en los otros servidores web.
John Hanley

Pregúntele a su proveedor de alojamiento si pueden desactivar mod_http2.
John Hanley

@JohnHanley - re # 1, sí, es el mismo SSL con 6 dominios. No es fácil saber exactamente cuándo ocurre el error. El escenario principal es que estoy en un dominio que extrae contenido (imágenes y js) de otros dos dominios. Re # 2: La dirección IP es definitivamente la misma: creo que emitir certificados separados cada nombre de dominio sería bastante más costoso. Investigué Let's Encrypt pero mi proveedor no lo admite. Mi proveedor en los últimos 6 meses ha ofrecido certificados gratuitos, por lo que cuando llegue la renovación este mes, cambiaré y veré qué sucede. Re # 3 - no pueden deshabilitar mod_http2. Gracias
mseifert

En realidad, todos los proveedores admiten Let's Encrypt a menos que lo bloqueen específicamente. Los certificados SSL son los mismos sin importar dónde los obtenga. La única diferencia es el tipo de validación (DV, OV, EV) y el formato / empaque del archivo. Apache es tan popular que todos los apoyan. Siempre y cuando su proveedor lo ayude a cargar su propio certificado (certificado y clave privada), puede usar la validación de DNS para evitarlos. Si no admiten cargar su propio certificado, entonces cambiaría de proveedor.
John Hanley

Respuestas:


14

Esto es causado por la siguiente secuencia de eventos:

  1. El servidor y el cliente son compatibles y usan HTTP / 2.
  2. El cliente solicita una página en foo.example.com.
  3. Durante la negociación de TLS, el servidor presenta un certificado que es válido para ambos foo.example.comy bar.example.com(y el cliente lo acepta). Esto podría hacerse con un certificado comodín o un certificado SAN.
  4. El cliente reutiliza la conexión para realizar una solicitud bar.example.com.
  5. El servidor no puede o no desea admitir la reutilización de conexiones entre dominios (por ejemplo, porque configuró su SSL de manera diferente y Apache quiere forzar una renegociación de TLS), y sirve HTTP 421.
  6. El cliente no vuelve a intentar automáticamente con una nueva conexión (consulte, por ejemplo, el error de Chrome # 546991 , ahora corregido). El RfC relevante dice que el cliente PUEDE reintentar, no que DEBE o DEBE. No volver a intentarlo no es particularmente fácil de usar, pero puede ser deseable para una herramienta de depuración o una biblioteca HTTP.

El evento n. ° 6 está fuera de su control, pero dependiendo del software del servidor, el n. ° 5 puede ser reparable. Consulte la documentación HTTP / 2 de su servidor para obtener más información sobre cómo y cuándo envía HTTP 421. Alternativamente, puede emitir certificados separados para cada dominio, pero eso genera más gastos administrativos y puede que no valga la pena. También puede desactivar HTTP / 2 por completo, pero eso probablemente sea excesivo en la mayoría de los casos.


Tengo un certificado Comodo PositiveSSL Multi-Domain, que de hecho es un certificado SSL único. Ir a certificados separados es un esfuerzo y / o gasto significativo en este momento. Los principales problemas surgieron al intentar tener dominios estáticos sin cookies para servir mis imágenes. No valía la cantidad de 421 que estaba recibiendo. Por el momento, he deshabilitado los dominios estáticos. Todavía tengo algunos recursos compartidos entre dominios, pero la cantidad de 421 ha disminuido drásticamente. Actualmente no vale la supuesta eficiencia. Algún día, probaré tu recomendación cuando tenga más tiempo.
mseifert

Gracias por la explicación detallada. Si bien esto es bastante un problema molesto (y sólo se dio cuenta que cuando se usa Safari, en gran parte), encuentro la cadena de acontecimientos que conducen a este problema bastante interesante :)
fritzmg

1

Tal vez esto sea útil para alguien.

Recibí este error cuando intenté cambiar la configuración de mi host virtual apache a HTTPS pero solo cambié el puerto de 80 a 443 y olvidé agregar

   SSLEngine on
   SSLCertificateFile "/opt/lampp/htdocs/localhost.crt"
   SSLCertificateKeyFile "/opt/lampp/htdocs/localhost.key"

Configuración que causa el error 421:

<VirtualHost mydoamin.local:443>   <-- fistly I 
       DocumentRoot "/opt/lampp/htdocs/mydomain/"
       ServerName www.mydomain.local
</VirtualHost>

La configuración correcta:

<VirtualHost mydoamin.local:443>
       DocumentRoot "/opt/lampp/htdocs/mydomain/"
       ServerName www.mydomain.local
       SSLEngine on
       SSLCertificateFile "/opt/lampp/htdocs/localhost.crt"
       SSLCertificateKeyFile "/opt/lampp/htdocs/localhost.key"
</VirtualHost>

-1

Tuve el mismo problema. Cambiar a dos SSL de una sola ranura hizo el truco.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.