OpenID sobre SSL con certificado autofirmado

Question

Configuré mi propio proveedor de Id abierto en mi servidor personal y agregué un redireccionamiento a https en mi archivo de configuración de apache. Cuando no utilizo una conexión segura (cuando deshabilito la redirección) puedo iniciar sesión bien, pero con la redirección no puedo iniciar sesión con este mensaje de error:

La conexión subyacente se cerró: No se pudo establecer una relación de confianza para el canal seguro SSL/TLS.

Supongo que esto se debe a que estoy usando un certificado autofirmado.

¿Alguien puede confirmar si el certificado autofirmado es el problema? Si no, ¿alguien tiene alguna idea de cuál es el problema?

Answer 1

La principal ventaja de usar SSL para su URL OpenID es que le da a la parte que confía un mecanismo para descubrir si el DNS ha sido manipulado. Es imposible para la parte dependiente saber si una URL de OpenID con un certificado autofirmado se ha visto comprometida.

Existen otros beneficios que obtiene al usar SSL en la URL de punto final de su proveedor (más fácil de establecer asociaciones, sin escuchas de los datos de extensión) que aún se mantendrían si utilizó un certificado autofirmado, pero consideraría que ser secundario.

Answer 2

Parece que sí. El cliente de su servidor OpenID no confía en la autoridad de certificación raíz.

Answer 3

(Descargo de responsabilidad: soy nuevo en OpenID, entonces podría estar equivocado aquí.) La comunicación entre el Open ID Consumer (por ejemplo, StackOverflow) y el Open ID Provider (su servidor) no requiere HTTPS - funcionará igual de bien y de forma segura a través de HTTP simple. Lo que debe hacer es configurar su servidor para cambiar a HTTPS solo cuando le muestre su página de inicio de sesión. En ese caso, solo su navegador debe preocuparse por el certificado autofirmado. Puede importar el certificado a su PC y todo será tan seguro como, por ejemplo, con un certificado emitido por Verisign.

Answer 4

OpenID está diseñado de una manera transparente de redireccionamiento. Siempre que se conserven los pares clave/valor necesarios en cada redirección, ya sea por GET o POST, todo funcionará correctamente.

La solución más fácil para lograr la compatibilidad con los consumidores que no funcionan con certificados autofirmados es usar un punto final no encriptado que redirige los mensajes checkid_immediate y checkid_setup a uno encriptado.

Hacer esto en el código del servidor es más fácil que con los redireccionamientos del servidor web, ya que el primero puede manejar más fácilmente las solicitudes POST, al tiempo que mantiene el código unido. Además, puede usar el mismo punto final para manejar todas las operaciones de OpenID, independientemente de si debe o no ser servido a través de SSL, siempre que se realicen las verificaciones adecuadas.

Por ejemplo, en PHP, el redireccionamiento puede ser tan simple como:

// Redirect OpenID authentication requests to https:// of same URL 
// Assuming valid OpenID operation over GET 
if (!isset($_SERVER['HTTPS']) && 
     ($_GET['openid_mode'] == 'checkid_immediate' || 
     $_GET['openid_mode'] == 'checkid_setup')) 
    http_redirect("https://{$_SERVER['HTTP_HOST']}{$_SERVER['REQUEST_URI']}"); 

medida que el valor openid.return_to fue generado contra un HTTP plano de punto final, en lo que se refiere al consumidor, es solamente tratar con un servidor no encriptado Asumiendo la operación apropiada de OpenID 2.0 con sesiones y nonces, cualquier información que pase entre el consumidor y su servidor no debe revelar información explotable. Las operaciones entre su navegador y el servidor OpenID, que son explotables (detección de contraseñas o secuestro de cookies de sesión) se realizan a través de un canal encriptado.

Además de mantener ocultos a los intrusos, realizar las operaciones de autenticación a través de SSL le permite utilizar el indicador de cookies HTTP secure. Esto agrega otra capa de protección para las operaciones checkid_immediate, si desea permitirlo.