Pergunta

I configurar o meu próprio provedor de Open ID no meu servidor pessoal, e acrescentou um redirecionamento para https no meu arquivo de configuração do apache. Quando não estiver usando uma conexão segura (quando eu desativar o redirecionamento) eu posso log in fine, mas com o redirecionamento Eu não pode fazer login com esta mensagem de erro:

A conexão subjacente foi fechada:. Não foi possível estabelecer relação de confiança para o SSL / TLS canal seguro

Eu estou supondo que isso é porque eu estou usando um certificado auto-assinado.

Alguém pode confirmar se o certificado auto-assinado é o problema? Se não Alguém tem alguma idéia qual é o problema?

Foi útil?

Solução

O principal benefício de usar SSL para o seu OpenID URL é que lhe dá a terceira parte confiável um mecanismo para descobrir se o DNS foi adulterado. É impossível para a terceira parte confiável para saber se um URL OpenID com um certificado auto-assinado foi comprometida.

Há outros benefícios que você começa de usar SSL na URL do terminal do seu provedor (mais fácil de estabelecer associações, sem espionagem nos dados de extensão), que ainda espera Se você usou uma cert auto-assinado, mas eu considero aqueles que ser secundário.

Outras dicas

OpenID é projetado de forma redirecionamento transparente. Enquanto os pares de chave / valor necessárias são preservadas em cada redirecionamento, quer por GET ou POST, tudo funcionará corretamente.

A solução mais fácil para conseguir a compatibilidade com os consumidores que não funcionam com certificados auto-assinados é usar um ponto final-não-criptografada que redireciona mensagens checkid_immediate e checkid_setup a um já criptografada.

Fazer isso em seu código do servidor é mais fácil do que com redirecionamentos de servidor web como o primeiro pode lidar mais facilmente com solicitações POST, ao mesmo tempo mantendo o código juntos. Além disso, você pode usar o mesmo ponto final para lidar com todas as operações de OpenID, independentemente se é ou não deve ser servido sobre SSL, enquanto controlos adequados são feitos.

Por exemplo, em PHP, o redirecionamento pode ser tão simples 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 o valor openid.return_to foi gerado contra um ponto final HTTP simples, tanto quanto o consumidor está em causa, é apenas lidar com um servidor não-criptografada. Assumindo operação OpenID 2.0 adequada com sessões e nonces, qualquer informação que se passaram entre o consumidor eo seu sever não devem revelar informações explorável. As operações entre o navegador eo servidor OpenID, que são exploráveis ??(password bisbilhotando ou sessão de cookie hijacking) é feito por um canal criptografado.

Além de manter a bisbilhoteiros, tendo operações de autenticação ser realizada através de SSL permite que você use a bandeira secure cookies HTTP. Isso acrescenta mais uma camada de proteção para operações checkid_immediate, se desejar para permitir isso.

(Disclaimer: Eu sou novo para OpenID, então eu poderia estar errado aqui.) A comunicação entre o Open ID do Consumidor (por exemplo, StackOverflow) eo Provedor de Open ID (o servidor) não requer HTTPS - que vai funcionam tão bem e tão HTTP com segurança sobre simples. O que você precisa fazer é configurar o servidor para mudar para HTTPS apenas quando ela mostra a página de login. Nesse caso, apenas o seu navegador precisa preocupar-se com o certificado auto-assinado. Você pode importar o certificado para o seu PC e tudo vai ser tão seguro como com, digamos, certificado Verisign-emitido.

Parece que ele. O cliente do seu servidor OpenID não confiar na autoridade de certificação raiz.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top