Risolvere un errore di handshake SSL di Kopano su una porta personalizzata

Definisci cosa si intende per soluzione efficace

Un errore di handshake SSL di Kopano indica che client e server non sono riusciti a concordare o a completare la connessione TLS. La porta personalizzata potrebbe essere corretta per una parte della configurazione, ma errata per un'altra. Prima di modificare i certificati o le impostazioni del protocollo, identifica quale servizio è proprietario della porta e se è previsto il protocollo TLS su tale porta.

Per una configurazione funzionante, la porta prevista accetta una connessione TLS, presenta un certificato valido per il nome host utilizzato dai client e consente il completamento della fase successiva del protocollo. Un browser dovrebbe raggiungere la pagina di accesso dell'applicazione Web senza visualizzare avvisi relativi al certificato. Un client Kopano Core dovrebbe connettersi utilizzando la porta TLS corrispondente e, se configurato, il proprio certificato client attendibile. Un test TLS riuscito di per sé non dimostra che l'accesso all'applicazione Web, l'autenticazione Kopano o la consegna della posta funzionino correttamente.

Innanzitutto, separare le due configurazioni di porte comuni.

Verificato per Kopano Core: il manuale di amministrazione di Kopano Core 8.0 descrive un listener TLS nativo controllato da server_listen_tls. Il suo esempio utilizza la porta 237, afferma che la porta può essere modificata e configura i file del certificato e della CA in /etc/kopano/server.cfg. Il manuale mostra anche i client che utilizzano un https://socket server con la porta e il certificato client corrispondenti. Vedi Kopano Core: connessioni SSL e certificati e configurazioni speciali di Kopano Core .

Separatamente, per l'accesso alla WebApp: gli utenti normalmente aprono un URL del browser servito da Apache, Nginx o Kopano Web. Il TLS può terminare su quel server front-end mentre inoltra le richieste ai servizi Kopano. Il manuale di Kopano documenta il proxy HTTP verso il listener Core sulla porta 236, mentre la guida di Kopano Web documenta le impostazioni del certificato TLS in /etc/kopano/kwebd.cfg. La porta HTTPS del front-end non è automaticamente la stessa della porta TLS di Core. Consultare l' esempio di reverse proxy di Core e la guida all'installazione di Kopano Web .

Azione: annotare l'URL del client, la porta personalizzata, il processo che dovrebbe rimanere in ascolto su tale porta e se la connessione TLS termina sul proxy o su Kopano Core. Non modificare entrambi i listener contemporaneamente.

1. Verifica cosa è in ascolto sulla porta personalizzata

Sull'host Kopano, sostituire 8443quanto segue con la porta che presenta il problema:

sudo ss -ltnp | grep ':8443'

Una riga corrispondente dovrebbe mostrare un socket in ascolto. Se non è presente alcuna riga, il servizio non è associato a quella porta oppure è associato a un indirizzo diverso. Se la porta appartiene a un proxy inverso locale, esaminare l'host virtuale del proxy. Se dovrebbe essere la porta TLS nativa di Kopano Core, esaminare server_listen_tlsin /etc/kopano/server.cfg. Un processo in ascolto solo su 127.0.0.1non può accettare connessioni remote direttamente; questo potrebbe essere intenzionale quando un proxy si trova davanti.

Verifica anche il firewall dell'host, il firewall del cloud e qualsiasi bilanciatore di carico o regola NAT. La porta pubblica deve essere raggiungibile dal listener interno previsto. Un timeout o un rifiuto di connessione indicano problemi di raggiungibilità o di configurazione del listener; di per sé non indicano un certificato non valido.

2. Eseguire una scansione TLS sull'hostname e sulla porta esatti

Da una macchina client, testa l'endpoint pubblico con OpenSSL. Utilizza il nome DNS presente nel certificato, non un indirizzo IP non correlato:

openssl s_client -connect mail.example.com:8443 -servername mail.example.com -showcerts

Cerca il certificato presentato, il protocollo e la cifratura negoziati e gli eventuali errori di verifica. L' -servernameopzione invia il nome host TLS SNI; questo è importante quando un server ospita più di un sito TLS. OpenSSL documenta queste opzioni nel suo manuale s_client . Premi Ctrl+C per uscire dalla sonda interattiva.

Se il certificato non è presente, l'endpoint potrebbe utilizzare il protocollo HTTP non crittografato, la porta potrebbe essere assegnata al servizio sbagliato oppure un proxy potrebbe inoltrare le richieste a un server upstream errato. Se un certificato è presente ma il suo nome, l'emittente o la data di scadenza non sono corretti, è necessario correggere la selezione o la catena di certificati sull'endpoint TLS. Un'incongruenza del nome host non viene risolta modificando la porta del listener di Kopano Core.

Per un endpoint accessibile tramite browser, procedere come segue:

curl -v https://mail.example.com:8443/webapp/

L'output dettagliato aiuta a distinguere la verifica TLS da una risposta HTTP come un reindirizzamento, un errore 404 o un errore 502. Un errore 404 dopo un handshake completato indica un problema di percorso o di routing, non un errore di negoziazione TLS. Solo per una diagnosi una tantum, curl -vkpuò mostrare se ignorare la verifica del certificato modifica il risultato. Non lasciare i controlli dei certificati disabilitati in un browser, client o proxy.

Limite importante: il TLS nativo di Kopano Core può utilizzare certificati client. Un s_clienttest di base senza certificato client potrebbe essere rifiutato anche se il listener TLS funziona correttamente. Se il server richiede l'autenticazione del client, ripetere il test con il certificato e la chiave client autorizzati oppure con il client del servizio Kopano configurato. Non esporre mai una chiave privata in una trascrizione di comando o in un ticket di supporto.

3. Associare il protocollo al listener

Un errore comune nella configurazione delle porte personalizzate è quello di impostare un client HTTPS in modo che contatti un listener HTTP semplice, oppure di inoltrare il traffico HTTPS a un server upstream che si aspetta traffico HTTP. Lo schema e la porta devono descrivere lo stesso endpoint.

• https://mail.example.com:8443/webapp/significa che il browser si aspetta TLS sulla porta 8443.
• L'esempio documentato di Kopano Core invia HTTP tramite proxy a 127.0.0.1:236. Se la tua implementazione utilizza questo schema, il proxy upstream deve utilizzare http://, anche se la connessione pubblica del browser utilizza HTTPS.
• Per Kopano Core TLS nativo, l'esempio del manuale utilizza server_listen_tls = *:237un URL client che inizia con https://. Se si modifica la porta 237 con una porta personalizzata, aggiornare ogni client o proxy dipendente con lo stesso valore.

Verificate la presenza di righe di configurazione copiate che presentino discrepanze relative alla porta o allo schema. In una configurazione multi-server, controllate anche l'URL del server o del proxy pubblicato: un client potrebbe stabilire una connessione iniziale e poi fallire dopo che Kopano lo reindirizza a un hostname o a una porta obsoleti.

4. Riparare la configurazione del listener e del certificato

Se si tratta del listener TLS nativo di Kopano Core, modificare la configurazione esistente anziché aggiungere direttive duplicate. Di seguito è riportato un esempio semplificato per una porta personalizzata; mantenere i percorsi del certificato e l'autorità di certificazione (CA) appropriati per la propria installazione:

server_listen_tls = *:1237
server_ssl_ca_file = /etc/kopano/ssl/ca.pem
server_ssl_key_file = /etc/kopano/ssl/server.pem
server_ssl_key_pass = your-key-passphrase

Il manuale di Kopano specifica le impostazioni di listener, CA, server-key e key-pass e richiede il riavvio kopano-serverdopo questa modifica del listener nativo. Verificare che la versione installata supporti le opzioni mostrate; la struttura dei pacchetti e le direttive possono variare. Proteggere la directory delle chiavi e assicurarsi che l'account di servizio di Kopano possa leggere i file necessari.

Verificate che il certificato sia per il nome host effettivamente utilizzato dai client, che rientri nel suo periodo di validità e che includa tutti i certificati intermedi richiesti. Il manuale di Kopano specifica che i suoi componenti verificano il nome comune del certificato e i nomi alternativi del soggetto. In una configurazione TLS multi-server, il server deve anche considerare attendibile l'autorità di certificazione (CA) che ha firmato i certificati client e i certificati client autorizzati devono essere configurati. Non sostituite un certificato con uno autofirmato come scorciatoia per un servizio di browser pubblico.

Se la connessione TLS termina su Apache, Nginx o Kopano Web, configura il certificato e listenla porta personalizzata direttamente su quel front-end. Quindi imposta lo schema e la porta upstream in base al listener effettivo del back-end. Non abilitare TLS upstream solo perché il lato pubblico utilizza HTTPS; prima verifica che anche la porta del back-end supporti TLS.

5. Convalidare e ricaricare il servizio corretto

Prima di ricaricare un server web, esegui un controllo della configurazione, ad esempio sudo nginx -tper Nginx o sudo apachectl configtestper Apache. Se il test segnala un errore, correggilo prima di ricaricarlo. Utilizza il nome del servizio installato sulla tua distribuzione; ad esempio:

sudo systemctl restart kopano-server
sudo systemctl status kopano-server --no-pager

Riavvia Kopano Core solo dopo averne modificato la configurazione. Per una modifica della porta o del certificato che riguarda solo il front-end, convalida e ricarica il servizio front-end. Controlla immediatamente il registro o il log degli errori dopo la modifica e ripeti esattamente la procedura di verifica OpenSSL dalla rete client. L'handshake dovrebbe ora presentare il certificato previsto. Quindi, testa l'URL effettivo dell'applicazione Web o la connessione del client Kopano, poiché il solo successo della connessione TLS non convalida il percorso dell'applicazione o l'autenticazione.

Leggi il risultato prima di apportare ulteriori modifiche

• Nessun socket in ascolto: verificare il listener configurato, lo stato del servizio e l'indirizzo di associazione.
• Connessione rifiutata o timeout: verificare il firewall, il NAT, il bilanciatore di carico e se la porta di destinazione è raggiungibile.
• Certificato errato: verificare il certificato configurato sull'endpoint che risponde a quella porta, inclusa la selezione SNI e la catena di certificati.
• TLS funziona in locale ma non in remoto: confronta il percorso del proxy pubblico o del bilanciatore di carico con il listener locale e verifica i valori di host e porta inoltrati.
• L'handshake ha esito positivo, ma WebApp non funziona: verificare lo stato HTTP, il percorso del proxy, i log di PHP/WebApp e la connettività di Kopano Core. Proseguire a livello applicativo.
• Solo i client Core falliscono: verificare le server_socketimpostazioni di porta personalizzata, CA attendibile e certificato client. Il percorso Core TLS potrebbe richiedere l'autenticazione reciproca tramite certificato.

Una soluzione affidabile modifica solo l'endpoint responsabile dell'handshake non riuscito. Il manuale di amministrazione di Kopano Core disponibile per questa procedura è la versione 8.0.0 e i relativi esempi devono essere confrontati con i pacchetti installati e le pagine del manuale locale. Se la distribuzione utilizza una versione diversa di Kopano, un container o un proxy inverso gestito, verificare la configurazione corrente di tale componente prima di applicare le direttive di esempio.