OpenID su SSL con certificato autofirmato

Question

Ho impostato il mio provider di ID aperto sul mio server personale e ho aggiunto un reindirizzamento a https nel mio file di configurazione di Apache. Quando non utilizzo una connessione protetta (quando disabilito il reindirizzamento) posso accedere correttamente, ma con il reindirizzamento non riesco ad accedere con questo messaggio di errore:

La connessione sottostante è stata chiusa: impossibile stabilire una relazione di trust per il canale sicuro SSL / TLS.

Suppongo che questo sia perché sto usando un certificato autofirmato.

Qualcuno può confermare se il certificato autofirmato è il problema? Altrimenti qualcuno ha qualche idea di quale sia il problema?

Answer 1

Il vantaggio principale dell'utilizzo di SSL per l'URL OpenID è che fornisce alla parte affidante un meccanismo per scoprire se il DNS è stato manomesso. È impossibile per la parte affidataria dire se un URL OpenID con un certificato autofirmato è stato compromesso.

Ci sono altri vantaggi che si ottengono dall'utilizzo di SSL sull'URL dell'endpoint del proprio provider (più facile da stabilire associazioni, senza intercettazioni sui dati dell'estensione) che rimarrebbero comunque validi se si utilizzasse un certificato autofirmato, ma considererei questi come secondario.

Answer 2

OpenID è progettato in modo reindirizzamento trasparente. Finché le coppie chiave / valore necessarie vengono conservate ad ogni reindirizzamento, tramite GET o POST, tutto funzionerà correttamente.

La soluzione più semplice per raggiungere la compatibilità con i consumatori che non lavorano con certificati autofirmati è utilizzare un end-point non crittografato che reindirizza i messaggi checkid_immediate e checkid_setup a uno crittografato.

Eseguire questa operazione nel codice del server è più semplice rispetto ai reindirizzamenti del server Web poiché i primi possono gestire più facilmente le richieste POST, mantenendo allo stesso tempo il codice insieme. Inoltre, puoi utilizzare lo stesso end-point per gestire tutte le operazioni OpenID, indipendentemente dal fatto che debba essere servito o meno su SSL, purché vengano effettuati i controlli appropriati.

Ad esempio, in PHP, il reindirizzamento può essere semplice come:

// Redirect OpenID authentication requests to https:// of same URL
// Assuming valid OpenID operation over GET
if (!isset(
 OpenID è progettato in modo reindirizzamento trasparente. Finché le coppie chiave / valore necessarie vengono conservate ad ogni reindirizzamento, tramite GET o POST, tutto funzionerà correttamente. 

 La soluzione più semplice per raggiungere la compatibilità con i consumatori che non lavorano con certificati autofirmati è utilizzare un end-point non crittografato che reindirizza i messaggi  checkid_immediate  e  checkid_setup  a uno crittografato. 

 Eseguire questa operazione nel codice del server è più semplice rispetto ai reindirizzamenti del server Web poiché i primi possono gestire più facilmente le richieste POST, mantenendo allo stesso tempo il codice insieme. Inoltre, puoi utilizzare lo stesso end-point per gestire tutte le operazioni OpenID, indipendentemente dal fatto che debba essere servito o meno su SSL, purché vengano effettuati i controlli appropriati. 

 Ad esempio, in PHP, il reindirizzamento può essere semplice come: 

<*>

 Poiché il valore  openid.return_to  è stato generato rispetto a un end-point HTTP semplice, per quanto riguarda il consumatore, si tratta solo di un server non crittografato. Supponendo il corretto funzionamento di OpenID 2.0 con sessioni e nonces, qualsiasi informazione trasmessa tra il consumatore e il server non dovrebbe rivelare informazioni sfruttabili. Le operazioni tra il browser e il server OpenID, che sono sfruttabili (snooping della password o dirottamento dei cookie di sessione) vengono eseguite su un canale crittografato. 

 Oltre a tenere fuori gli intercettatori, l'esecuzione di operazioni di autenticazione su SSL consente di utilizzare il flag cookie HTTP  secure . Ciò aggiunge un ulteriore livello di protezione per le operazioni  checkid_immediate , se si desidera consentirlo. 
SERVER['HTTPS']) &&
        (
 OpenID è progettato in modo reindirizzamento trasparente. Finché le coppie chiave / valore necessarie vengono conservate ad ogni reindirizzamento, tramite GET o POST, tutto funzionerà correttamente. 

 La soluzione più semplice per raggiungere la compatibilità con i consumatori che non lavorano con certificati autofirmati è utilizzare un end-point non crittografato che reindirizza i messaggi  checkid_immediate  e  checkid_setup  a uno crittografato. 

 Eseguire questa operazione nel codice del server è più semplice rispetto ai reindirizzamenti del server Web poiché i primi possono gestire più facilmente le richieste POST, mantenendo allo stesso tempo il codice insieme. Inoltre, puoi utilizzare lo stesso end-point per gestire tutte le operazioni OpenID, indipendentemente dal fatto che debba essere servito o meno su SSL, purché vengano effettuati i controlli appropriati. 

 Ad esempio, in PHP, il reindirizzamento può essere semplice come: 

<*>

 Poiché il valore  openid.return_to  è stato generato rispetto a un end-point HTTP semplice, per quanto riguarda il consumatore, si tratta solo di un server non crittografato. Supponendo il corretto funzionamento di OpenID 2.0 con sessioni e nonces, qualsiasi informazione trasmessa tra il consumatore e il server non dovrebbe rivelare informazioni sfruttabili. Le operazioni tra il browser e il server OpenID, che sono sfruttabili (snooping della password o dirottamento dei cookie di sessione) vengono eseguite su un canale crittografato. 

 Oltre a tenere fuori gli intercettatori, l'esecuzione di operazioni di autenticazione su SSL consente di utilizzare il flag cookie HTTP  secure . Ciò aggiunge un ulteriore livello di protezione per le operazioni  checkid_immediate , se si desidera consentirlo. 
GET['openid_mode'] == 'checkid_immediate' ||
         
 OpenID è progettato in modo reindirizzamento trasparente. Finché le coppie chiave / valore necessarie vengono conservate ad ogni reindirizzamento, tramite GET o POST, tutto funzionerà correttamente. 

 La soluzione più semplice per raggiungere la compatibilità con i consumatori che non lavorano con certificati autofirmati è utilizzare un end-point non crittografato che reindirizza i messaggi  checkid_immediate  e  checkid_setup  a uno crittografato. 

 Eseguire questa operazione nel codice del server è più semplice rispetto ai reindirizzamenti del server Web poiché i primi possono gestire più facilmente le richieste POST, mantenendo allo stesso tempo il codice insieme. Inoltre, puoi utilizzare lo stesso end-point per gestire tutte le operazioni OpenID, indipendentemente dal fatto che debba essere servito o meno su SSL, purché vengano effettuati i controlli appropriati. 

 Ad esempio, in PHP, il reindirizzamento può essere semplice come: 

<*>

 Poiché il valore  openid.return_to  è stato generato rispetto a un end-point HTTP semplice, per quanto riguarda il consumatore, si tratta solo di un server non crittografato. Supponendo il corretto funzionamento di OpenID 2.0 con sessioni e nonces, qualsiasi informazione trasmessa tra il consumatore e il server non dovrebbe rivelare informazioni sfruttabili. Le operazioni tra il browser e il server OpenID, che sono sfruttabili (snooping della password o dirottamento dei cookie di sessione) vengono eseguite su un canale crittografato. 

 Oltre a tenere fuori gli intercettatori, l'esecuzione di operazioni di autenticazione su SSL consente di utilizzare il flag cookie HTTP  secure . Ciò aggiunge un ulteriore livello di protezione per le operazioni  checkid_immediate , se si desidera consentirlo. 
GET['openid_mode'] == 'checkid_setup'))
    http_redirect("https://{
 OpenID è progettato in modo reindirizzamento trasparente. Finché le coppie chiave / valore necessarie vengono conservate ad ogni reindirizzamento, tramite GET o POST, tutto funzionerà correttamente. 

 La soluzione più semplice per raggiungere la compatibilità con i consumatori che non lavorano con certificati autofirmati è utilizzare un end-point non crittografato che reindirizza i messaggi  checkid_immediate  e  checkid_setup  a uno crittografato. 

 Eseguire questa operazione nel codice del server è più semplice rispetto ai reindirizzamenti del server Web poiché i primi possono gestire più facilmente le richieste POST, mantenendo allo stesso tempo il codice insieme. Inoltre, puoi utilizzare lo stesso end-point per gestire tutte le operazioni OpenID, indipendentemente dal fatto che debba essere servito o meno su SSL, purché vengano effettuati i controlli appropriati. 

 Ad esempio, in PHP, il reindirizzamento può essere semplice come: 

<*>

 Poiché il valore  openid.return_to  è stato generato rispetto a un end-point HTTP semplice, per quanto riguarda il consumatore, si tratta solo di un server non crittografato. Supponendo il corretto funzionamento di OpenID 2.0 con sessioni e nonces, qualsiasi informazione trasmessa tra il consumatore e il server non dovrebbe rivelare informazioni sfruttabili. Le operazioni tra il browser e il server OpenID, che sono sfruttabili (snooping della password o dirottamento dei cookie di sessione) vengono eseguite su un canale crittografato. 

 Oltre a tenere fuori gli intercettatori, l'esecuzione di operazioni di autenticazione su SSL consente di utilizzare il flag cookie HTTP  secure . Ciò aggiunge un ulteriore livello di protezione per le operazioni  checkid_immediate , se si desidera consentirlo. 
SERVER['HTTP_HOST']}{
 OpenID è progettato in modo reindirizzamento trasparente. Finché le coppie chiave / valore necessarie vengono conservate ad ogni reindirizzamento, tramite GET o POST, tutto funzionerà correttamente. 

 La soluzione più semplice per raggiungere la compatibilità con i consumatori che non lavorano con certificati autofirmati è utilizzare un end-point non crittografato che reindirizza i messaggi  checkid_immediate  e  checkid_setup  a uno crittografato. 

 Eseguire questa operazione nel codice del server è più semplice rispetto ai reindirizzamenti del server Web poiché i primi possono gestire più facilmente le richieste POST, mantenendo allo stesso tempo il codice insieme. Inoltre, puoi utilizzare lo stesso end-point per gestire tutte le operazioni OpenID, indipendentemente dal fatto che debba essere servito o meno su SSL, purché vengano effettuati i controlli appropriati. 

 Ad esempio, in PHP, il reindirizzamento può essere semplice come: 

<*>

 Poiché il valore  openid.return_to  è stato generato rispetto a un end-point HTTP semplice, per quanto riguarda il consumatore, si tratta solo di un server non crittografato. Supponendo il corretto funzionamento di OpenID 2.0 con sessioni e nonces, qualsiasi informazione trasmessa tra il consumatore e il server non dovrebbe rivelare informazioni sfruttabili. Le operazioni tra il browser e il server OpenID, che sono sfruttabili (snooping della password o dirottamento dei cookie di sessione) vengono eseguite su un canale crittografato. 

 Oltre a tenere fuori gli intercettatori, l'esecuzione di operazioni di autenticazione su SSL consente di utilizzare il flag cookie HTTP  secure . Ciò aggiunge un ulteriore livello di protezione per le operazioni  checkid_immediate , se si desidera consentirlo. 
SERVER['REQUEST_URI']}");

Poiché il valore openid.return_to è stato generato rispetto a un end-point HTTP semplice, per quanto riguarda il consumatore, si tratta solo di un server non crittografato. Supponendo il corretto funzionamento di OpenID 2.0 con sessioni e nonces, qualsiasi informazione trasmessa tra il consumatore e il server non dovrebbe rivelare informazioni sfruttabili. Le operazioni tra il browser e il server OpenID, che sono sfruttabili (snooping della password o dirottamento dei cookie di sessione) vengono eseguite su un canale crittografato.

Oltre a tenere fuori gli intercettatori, l'esecuzione di operazioni di autenticazione su SSL consente di utilizzare il flag cookie HTTP secure . Ciò aggiunge un ulteriore livello di protezione per le operazioni checkid_immediate , se si desidera consentirlo.

Answer 3

(Dichiarazione di non responsabilità: sono nuovo di OpenID, quindi potrei sbagliarmi qui.) La comunicazione tra il consumatore Open ID (ad es. StackOverflow) e il provider Open ID (il tuo server) non richiede HTTPS - lo farà funziona altrettanto bene e in modo sicuro su un semplice HTTP. Quello che devi fare è configurare il tuo server per passare a HTTPS solo quando ti mostra la tua pagina di accesso. In tal caso, solo il tuo browser deve occuparsi del certificato autofirmato. Puoi importare il certificato sul tuo PC e tutto sarà sicuro come, ad esempio, con il certificato rilasciato da Verisign.

Answer 4

Sembra così. Il client del tuo server OpenID non si fida dell'autorità di certificazione principale.