iBaffiPro ha scritto:
Quindi per riassumere, fammi sapere se ciò che scrivo è corretto:
I certificati sono dei file che devono essere aggiunti al server Tomcat per creare una connessione HTTPS sicura tra client e server. Questi certificati contengono anche il nome dell’ente certificatore che permette al browser di capire se tale ente è valido oppure no. Tutti gli enti certificatori discendono da una serie di enti capostipiti che sono inglobati nel codice del browser. I file dei certificati contengono quindi le informazioni che permettono al browser di capire da dove deriva un preciso ente certificatore ed essenzialmente delle password utilizzate per rendere la connessione tra server e client sicura.
In realtà non proprio, diciamo un 70%
1) Qual è sostanzialmente la differenza tra un ente certificatore free ed uno a pagamento? Sicurezza? Durata del certificato? Altro?
Sicurezza in parte (è più placebo che altro).
Durata senza dubbio.
In certi casi la disponibilità di certificati *
2) Se creo con l'OS o qualche programma un certificato falso firmato da me, oltre che in locale anche sul server di produzione, è lapalissiano che il browser mi giudichi come non sicuro ma in termini fisici/tecnici la mia connessione HTTPS offrirebbe una connessione altrettanto sicura come quella di un ente certificatore di prestigio dal punto di vista informatico?
Sì
Non è un certificato falso, è solo autofirmato.
Si fa spessissimo ad esempio per fare connessioni ssh con autenticazione a chiavi pubbliche
3) Dato che il certificato contiene password e firme digitali, ovvero informazioni digitali che permettono l’individuazione certa ed inoppugnabile della provenienza di un ente certificatore,
In realtà no, il certificato contiene delle chiavi pubbliche e/o private (versione condensata).
Le password (di cifratura simmetrica) vengono scambiate mediante un protocollo particolare (in realtà tipicamente ce ne sono 3) dopo una prima fase di scambio di chiavi asimmetriche
Minimo approfondimento: esistono due grandi tipologia di cifratura.
Quelle a chiave simmetrica (ogni parte conosce la password, diciamo pippo, PRIMA del colloquio telematico), e quelle a chiave asimmetrica (ogni parte conosce la chiave pubblica dell'altro e la privata propria)
La seconda tipologia (cifratura asimmetrica) funziona a sua volta con tanti metodi diversi, due in particolare sono i più usati, uno della quali molto di più.
Come funziona? Troppo lungo da spiegare.
In sostanza Tizio e Caio vogliono cifrare il traffico che c'è tra di loro.
Però non si conoscono, non hanno una password prefissata.
Tizio e Caio iniziano a "palleggiarsi" dei dati tra di loro e, con un metodo "magico", arrivano a stabilire la stessa password, diciamo pippone27.
Adesso con quella password cifrano (con algoritmo simmetrico) i dati che si scambiano.
Nel frattempo Caio e Sempronio (un altro client) fanno di nuovo questa fase di "accordo", e stabiliscono una password diciamo plutonio12. Essa è diversa da quella di Tizio e Caio
Ecco perchè Tizio e Caio non potranno leggere il traffico di Caio e Sempronio
la funzionalità HTTPS, ovvero il software o meglio ancora il codice che rende possibile suddetta connessione, dove risiede? Metà sul browser e metà sul server, su entrambi (chrome e tomcat) oppure altrove?[/u]
Su entrambi
4) Dal punto di vista pratico, nel mio caso (ho il braccetto corto) ritieni che mi convenga impostare una connessione HTTPS fasulla ovvero firmata da me in locale ed una vera (Let's Encrypt) sul server di produzione? In pratica vorrei caricare i certificati fasulli sul server tomcat creato dal mio IDE in locale e quelli veri sul server tomcat fisico su cui metterò la WebApp.
No, non ha senso.
Basta che alteri il file hosts (locale) e "fingerai" che localhost diventi
www.ilmiobelserver.co
5) Per quanto riguarda Let's Encrypt ho letto per sommi capi una guida che spiegava come fare in modo che i certificati sul server venissero automaticamente aggiornati poco prima della scadenza ma nella stessa guida, nella parte finale, si scriveva anche che per fare ciò sarebbe stato indispensabile riavviare il server.
No, per niente.
Al massimo riavviare il server inteso come programma server web, non come macchina fisica.
Alcuni server web ricaricano i certificati senza riavviare niente (basta mandare un SIGNAL apposito)
Quest’ultimo aspetto mi ha lasciato un po’ perplesso. Posso automatizzare il riavvio del server? E’ una cosa complessa da fare? Se mentre riavvio il server qualche client era connesso sul mio sito e stava facendo qualcosa?
Può cadere la connessione
Insomma, non mi sembra una soluzione ottimale questo Let's Encrypt e questo "HTTPS free" mi sembra che comporti costi di mantenimento elevatissimi.
Scusa ma che problema c'è?
1) non usi niente
2) usi autofirmato (ma avrai sempre avvisi di ogni genere)
3) usi let's e ti adatti
4) paghi
6) Cosa succede quando il certificato scade? Il browser si limita a scrivere “Non sicuro” oppure il sito diventa irraggiungibile?
La prima