Utilizzare i servizi di backend e di IdP con https senza problemi.

[alranel]

From @ncarandini on November 12, 2017 18:4

Una volta avviati i siti con docker-composer up, la navigazione verso tali siti con un qualsiasi browser mostra un avvertimento che lo identifica come sito non sicuro e per visualizzarlo si devono effettuare una serie di manovre che alla lunga annoiano parecchio.

Sarebbe possibile inserire nelle immagini (sia del backend che del servizio IdP) dei certificati self signed che vengano inclusi nelle root-CA dei rispettivi container in modo che la navigazione in Https non faccia scattare ogni volta tale avvertimento?

UPDATE

Dopo il commento di @alexrj ho studiato meglio la questione. Entrambe le immagini (sia del backend che del servizio IdP) contengono già certificati self-signed (e avrei dovuto capirlo subito, visto che usano senza problemi https) per cui ho cancellato la mia proposta.

Nel frattempo ho trovato la procedura da seguire per importare i certificati relativi al servizio di backend per risolvere il problema almeno per tali servizi, ma poiché i certificati sono SHA1 la cosa funziona con Edge ma non con Chrome, che da un po' di tempo non li riconosce più perché insicuri, come commentato nel loro post SHA-1 Certificates in Chrome.

La procedura è piuttosto semplice ed è riportata nel mio commento più avanti.

Copied from original issue: italia/spid-testenv-docker#13

[alranel]

From @ncarandini on December 15, 2017 17:27

Parlando con @alexrj mi sono reso conto che è sempre meglio evitare di inserire alcun certificato, anche se self signed, in un progetto. Sto lavorando a un'altra strada, se percorribile aprirò un'altra issue o meglio una pull request.

[alranel]

No beh, io mi riferivo alle implementazioni SP; non avevo capito che tu ti riferissi all'IdP di test. In ogni caso non mi pare che la soluzione che proponevi possa funzionare: per evitare gli avvisi dei browser devi usare un certificato firmato da una CA riconosciuta dal browser. Secondo me questa issue (ma non la soluzione proposta) resta valida e si può tenere aperta

[alranel]

From @ncarandini on December 16, 2017 8:34

Scusami @alexrj ma il fatto di non aggiungere un certificato self signed ad una soluzione in git-hub è una best practice, che differenza c'è tra un progetto di test di SP e uno di test di IdP ? Comunque ho molto ancora da imparare (e ci sto lavorando) sui certificati self signed e il loro uso, quindi mi riprometto di tornare su questa questione tra qualche giorno, in modo da poter contribuire con maggior cognizione di causa.

[alranel]

From @amusarra on December 16, 2017 9:10

Ciao @ncarandini Utilizzare certificati self-signed per ambienti di test è la normalità, in ambienti di certificazione e produzione di andranno poi a mettere certificati rilasciati da una CA autorevole.

Per esempio, un gruppo ha sviluppato il plugin SPID per Liferay e il loro ambiente demo utilizza dei certificati self-signed https://spid-demo.hetasan.com/come-configurare-il-plugin-liferay-spid

[alranel]

From @ncarandini on December 16, 2017 10:28

ciao @amusara, mi sono spiegato male! Sono pienamente d'accordo nell'usare i certificati self-signed e ne faccio anch'io uso nel progetto italia/spid-dotnet-sdk. La questione è se includere un certificato self signed pronto all'uso nei progetti GitHub in modo che chiunque scarichi il progetto se li trovi già pronti (tutt'al più da installare come trusted nel proprio PC) oppure, cosa che io preferisco, documentare gli step necessari affinche ciascuno si crei i propri self-signed certificate e li installi dove di dovere. Questo aspetto spesso crea difficoltà ai meno esperti che vogliono semplicemente scaricare da GitHub e avere tutto funzionante, quindi la mia attenzione è rivolta alla massima semplificazione possibile senza però incorrere in scenari anche ipoteticamente non sicuri, derivanti dalla condivisione pubblica di un proprio certificato, anche se self-signed e quindi di scarsissimo valore. Non ho ancora una risposta certa (non sono un esperto di sicurezza) ma ho notato che è prassi comune non pubblicare il certificato self signed ma dare le indicazioni su come farne uno. Aggiungo per completezza che proprio WSO2 Identity server già contiene in effetti un certificato self signed nel pacchetto di installazione (altrimenti non potrebbe fornire i suoi servizi su https) ma il certificato è inserito in un Vault quindi (se ho capito bene) in un certo qual senso è protetto. D'altra parte abbiamo il caso del servizio di backoffice dove il certificato è liberamente disponibile perché pubblicato con il progetto nella cartella certs.

[alranel]

From @ncarandini on December 16, 2017 14:54

La procedura da eseguire (in Windows) per rendere attendibile il sito di backoffice è la seguente:

1. Clonare in locale il progetto spid-testenv-backoffice.

2. Duplicare e rinominare i file ca-crt.pem e client-crt.pem che si trovano nella cartella "backoffice/certs" del progetto clonato con il suffisso .crt (o .cer, che funziona allo stesso modo).

3. cliccare col tasto destro su ca-crt.crt ed installare il certificato nella cartella dei certificati radice attendibili:

4. Allo stesso modo importare il certificato client-crt.cer, senza però forzare la destinazione:

Completata la procedura, se tutto è andato bene, aprendo il browser all'indirizzo https://localhost:8080 la pagina viene caricata da Edge senza alcun warning, mentre con Chrome il problema persiste, ma per via del fatto che la chiave self signed è di tipo SHA-1 (vedi SHA-1 Certificates in Chrome).

[mlocati]

In https://github.com/italia/spid-testenv-backoffice/pull/24 ho ricreato i certificati usanto SHA256.

Prima	Dopo