crear - OpenID sobre SSL con certificado autofirmado
instalar certificado ssl apache windows (4)
Configuré mi propio proveedor de identificación abierta 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 correctamente, 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 es porque 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?
(Descargo de responsabilidad: soy nuevo en OpenID, por lo que podría estar equivocado aquí.) La comunicación entre el Open ID Consumer (por ejemplo, ) y el Open ID Provider (su servidor) no requiere HTTPS, funcionará igual que bien y de forma segura a través de HTTP sin formato. 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.
El principal beneficio de usar SSL para su URL de OpenID es que brinda a la parte que confía un mecanismo para descubrir si se ha manipulado el DNS. Es imposible para la parte dependiente saber si una URL de OpenID con un certificado autofirmado ha sido comprometida.
Hay otros beneficios que obtiene al usar SSL en la URL de punto final de su proveedor (más fácil de establecer asociaciones, sin escuchar los datos de la extensión) que aún se mantendrían si utilizó un certificado autofirmado, pero los consideraría secundarios.
Suena así. El cliente de su servidor OpenID no confía en la autoridad de certificación raíz.
OpenID está diseñado de una manera redireccionada y transparente. 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 lidiar más fácilmente con las solicitudes POST, a la vez 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, la redirección 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'']}");
Como el valor openid.return_to se generó frente a un punto final HTTP simple, en lo que respecta al consumidor, solo se trata de un servidor no cifrado. 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 checkid_immediate operaciones checkid_immediate , si desea permitirlo.