OpenID sobre SSL con certificado autofirmado
https://stackoverflow.com/questions/131091
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Configuré mi propio proveedor de identificación abierta en mi servidor personal y agregué una redirección a https en mi archivo de configuración de apache. Cuando no uso una conexión segura (cuando desactivo 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?
Solución
El beneficio principal de usar SSL para su URL OpenID es que le da a la parte que confía un mecanismo para descubrir si se ha alterado el DNS. Es imposible para la parte que confía saber si una URL OpenID con un certificado autofirmado se ha visto 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 espiar los datos de extensión) que aún se mantendrían si usara un certificado autofirmado, pero consideraría que son secundaria.
Otros consejos
OpenID está diseñado de forma transparente y redirigida. Mientras 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 trabajan con certificados autofirmados es utilizar un punto final no cifrado que redirige los mensajes checkid_immediate y checkid_setup a una encriptada.
Hacer esto en el código de su 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 servirse o no 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( OpenID está diseñado de forma transparente y redirigida. Mientras 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 trabajan con certificados autofirmados es utilizar un punto final no cifrado que redirige los mensajes checkid_immediate y checkid_setup a una encriptada.
Hacer esto en el código de su 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 servirse o no a través de SSL, siempre que se realicen las verificaciones adecuadas.
Por ejemplo, en PHP, la redirección puede ser tan simple como:
<*>
Como el valor openid.return_to se generó en un punto final HTTP simple, en lo que respecta al consumidor, solo se trata de un servidor no encriptado. Asumiendo una operación adecuada de OpenID 2.0 con sesiones y nonces, cualquier información transmitida entre el consumidor y su servidor no debe revelar información explotable. Las operaciones entre su navegador y el servidor OpenID, que son explotables (espionaje de contraseña o secuestro de cookies de sesión) se realizan a través de un canal cifrado.
Además de mantener a raya a los espías, que las operaciones de autenticación se realicen a través de SSL le permite utilizar el indicador de cookie HTTP secure . Esto agrega otra capa de protección para las operaciones checkid_immediate , si desea permitirlo.
SERVER['HTTPS']) &&
( OpenID está diseñado de forma transparente y redirigida. Mientras 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 trabajan con certificados autofirmados es utilizar un punto final no cifrado que redirige los mensajes checkid_immediate y checkid_setup a una encriptada.
Hacer esto en el código de su 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 servirse o no a través de SSL, siempre que se realicen las verificaciones adecuadas.
Por ejemplo, en PHP, la redirección puede ser tan simple como:
<*>
Como el valor openid.return_to se generó en un punto final HTTP simple, en lo que respecta al consumidor, solo se trata de un servidor no encriptado. Asumiendo una operación adecuada de OpenID 2.0 con sesiones y nonces, cualquier información transmitida entre el consumidor y su servidor no debe revelar información explotable. Las operaciones entre su navegador y el servidor OpenID, que son explotables (espionaje de contraseña o secuestro de cookies de sesión) se realizan a través de un canal cifrado.
Además de mantener a raya a los espías, que las operaciones de autenticación se realicen a través de SSL le permite utilizar el indicador de cookie HTTP secure . Esto agrega otra capa de protección para las operaciones checkid_immediate , si desea permitirlo.
GET['openid_mode'] == 'checkid_immediate' ||
OpenID está diseñado de forma transparente y redirigida. Mientras 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 trabajan con certificados autofirmados es utilizar un punto final no cifrado que redirige los mensajes checkid_immediate y checkid_setup a una encriptada.
Hacer esto en el código de su 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 servirse o no a través de SSL, siempre que se realicen las verificaciones adecuadas.
Por ejemplo, en PHP, la redirección puede ser tan simple como:
<*>
Como el valor openid.return_to se generó en un punto final HTTP simple, en lo que respecta al consumidor, solo se trata de un servidor no encriptado. Asumiendo una operación adecuada de OpenID 2.0 con sesiones y nonces, cualquier información transmitida entre el consumidor y su servidor no debe revelar información explotable. Las operaciones entre su navegador y el servidor OpenID, que son explotables (espionaje de contraseña o secuestro de cookies de sesión) se realizan a través de un canal cifrado.
Además de mantener a raya a los espías, que las operaciones de autenticación se realicen a través de SSL le permite utilizar el indicador de cookie HTTP secure . Esto agrega otra capa de protección para las operaciones checkid_immediate , si desea permitirlo.
GET['openid_mode'] == 'checkid_setup'))
http_redirect("https://{ OpenID está diseñado de forma transparente y redirigida. Mientras 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 trabajan con certificados autofirmados es utilizar un punto final no cifrado que redirige los mensajes checkid_immediate y checkid_setup a una encriptada.
Hacer esto en el código de su 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 servirse o no a través de SSL, siempre que se realicen las verificaciones adecuadas.
Por ejemplo, en PHP, la redirección puede ser tan simple como:
<*>
Como el valor openid.return_to se generó en un punto final HTTP simple, en lo que respecta al consumidor, solo se trata de un servidor no encriptado. Asumiendo una operación adecuada de OpenID 2.0 con sesiones y nonces, cualquier información transmitida entre el consumidor y su servidor no debe revelar información explotable. Las operaciones entre su navegador y el servidor OpenID, que son explotables (espionaje de contraseña o secuestro de cookies de sesión) se realizan a través de un canal cifrado.
Además de mantener a raya a los espías, que las operaciones de autenticación se realicen a través de SSL le permite utilizar el indicador de cookie HTTP secure . Esto agrega otra capa de protección para las operaciones checkid_immediate , si desea permitirlo.
SERVER['HTTP_HOST']}{ OpenID está diseñado de forma transparente y redirigida. Mientras 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 trabajan con certificados autofirmados es utilizar un punto final no cifrado que redirige los mensajes checkid_immediate y checkid_setup a una encriptada.
Hacer esto en el código de su 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 servirse o no a través de SSL, siempre que se realicen las verificaciones adecuadas.
Por ejemplo, en PHP, la redirección puede ser tan simple como:
<*>
Como el valor openid.return_to se generó en un punto final HTTP simple, en lo que respecta al consumidor, solo se trata de un servidor no encriptado. Asumiendo una operación adecuada de OpenID 2.0 con sesiones y nonces, cualquier información transmitida entre el consumidor y su servidor no debe revelar información explotable. Las operaciones entre su navegador y el servidor OpenID, que son explotables (espionaje de contraseña o secuestro de cookies de sesión) se realizan a través de un canal cifrado.
Además de mantener a raya a los espías, que las operaciones de autenticación se realicen a través de SSL le permite utilizar el indicador de cookie HTTP secure . Esto agrega otra capa de protección para las operaciones checkid_immediate , si desea permitirlo.
SERVER['REQUEST_URI']}");
Como el valor openid.return_to se generó en un punto final HTTP simple, en lo que respecta al consumidor, solo se trata de un servidor no encriptado. Asumiendo una operación adecuada de OpenID 2.0 con sesiones y nonces, cualquier información transmitida entre el consumidor y su servidor no debe revelar información explotable. Las operaciones entre su navegador y el servidor OpenID, que son explotables (espionaje de contraseña o secuestro de cookies de sesión) se realizan a través de un canal cifrado.
Además de mantener a raya a los espías, que las operaciones de autenticación se realicen a través de SSL le permite utilizar el indicador de cookie HTTP secure . Esto agrega otra capa de protección para las operaciones checkid_immediate , si desea permitirlo.
(Descargo de responsabilidad: soy nuevo en OpenID, por lo que podría estar equivocado aquí.) La comunicación entre Open ID Consumer (por ejemplo, StackOverflow) y Open ID Provider (su servidor) no requiere HTTPS; funciona igual de bien y de forma segura sobre HTTP simple Lo que debe hacer es configurar su servidor para que cambie 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 con, por ejemplo, un certificado emitido por Verisign.
Suena así. El cliente de su servidor OpenID no confía en la autoridad de certificación raíz.
