Remediați o eroare de handshake SSL Kopano pe un port personalizat

Definiți cum arată o remediere reușită

O eroare de handshake SSL Kopano înseamnă că un client și un server nu au putut conveni asupra sau finaliza conexiunea TLS. Portul personalizat poate fi corect pentru o parte a configurării și greșit pentru alta. Înainte de a modifica certificatele sau setările protocolului, identificați serviciul care deține portul și dacă se așteaptă TLS acolo.

Pentru o configurație funcțională, portul dorit acceptă o conexiune TLS, prezintă un certificat valid pentru numele de gazdă utilizat de clienți și permite finalizarea următorului pas al protocolului. Un browser ar trebui să ajungă la pagina de conectare WebApp fără un avertisment privind certificatul. Un client Kopano Core ar trebui să se conecteze utilizând portul TLS corespunzător și, acolo unde este configurat, certificatul său de client de încredere. O sondă TLS reușită nu dovedește în sine că autentificarea WebApp, autentificarea Kopano sau livrarea e-mailurilor funcționează.

Mai întâi separați cele două configurații de porturi comune

Verificat pentru Kopano Core: Manualul de administrare Kopano Core 8.0 descrie un listener TLS nativ controlat de server_listen_tls. Exemplul său utilizează portul 237, spune că portul poate fi modificat și configurează fișierele de certificat și CA în /etc/kopano/server.cfg. Manualul arată, de asemenea, clienții care utilizează un https://socket de server cu portul și certificatul client corespondente. Consultați Kopano Core: Conexiuni și certificate SSL și Configurații speciale Kopano Core .

Separat, pentru accesul la WebApp: utilizatorii deschid în mod normal o adresă URL de browser servită de Apache, Nginx sau Kopano Web. TLS se poate termina la acel server front-end în timp ce redirecționează cererile către serviciile Kopano. Manualul Kopano documentează proxy-ul HTTP către listener-ul Core pe portul 236, în timp ce ghidul său Kopano Web documentează setările certificatului TLS în /etc/kopano/kwebd.cfg. Acel port HTTPS front-end nu este automat același cu portul Core TLS. Consultați exemplul de proxy invers Core și ghidul de instalare Kopano Web .

Acțiune: notați adresa URL a clientului, portul personalizat, procesul care se așteaptă să asculte acolo și dacă TLS se termină la proxy sau la Kopano Core. Nu modificați ambele listener-e simultan.

1. Verificați ce ascultă pe portul personalizat

Pe gazda Kopano, înlocuiți 8443mai jos cu portul care defectează:

sudo ss -ltnp | grep ':8443'

Un rând corespunzător ar trebui să afișeze un socket de ascultare. Dacă nu există niciun rând, serviciul nu este legat de acel port sau este legat de o altă adresă. Dacă portul aparține unui proxy invers local, inspectați gazda virtuală a proxy-ului. Dacă ar trebui să fie portul TLS nativ al Kopano Core, inspectați server_listen_tlsîn /etc/kopano/server.cfg. Un proces care ascultă doar pe 127.0.0.1nu poate accepta conexiuni la distanță direct; acest lucru poate fi intenționat atunci când un proxy se află în față.

Verificați și firewall-ul gazdă, firewall-ul cloud și orice echilibrator de încărcare sau regulă NAT. Portul public trebuie să ajungă la listener-ul intern dorit. O expirare sau un refuz al conexiunii indică accesibilitatea sau configurația listener-ului; nu indică în sine un certificat defect.

2. Verificați TLS pe ​​numele de gazdă și portul exacte

De pe o mașină client, testați endpoint-ul public cu OpenSSL. Folosiți numele DNS care apare în certificat, nu o adresă IP fără legătură:

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

Căutați un certificat prezentat, protocolul negociat și cifrul, precum și orice erori de verificare. Opțiunea -servernametrimite numele de gazdă TLS SNI; acest lucru este important atunci când un server găzduiește mai multe site-uri TLS. OpenSSL documentează aceste opțiuni în manualul său s_client . Apăsați Ctrl+C pentru a părăsi sonda interactivă.

Dacă certificatul lipsește, este posibil ca endpoint-ul să utilizeze HTTP simplu, portul să fie deținut de serviciul greșit sau un proxy să redirecționeze către un upstream incorect. Dacă apare un certificat, dar numele, emitentul sau expirarea acestuia sunt greșite, corectați selecția sau lanțul de certificat pe endpoint-ul TLS. O nepotrivire a numelui de gazdă nu se remediază prin schimbarea portului de ascultare Kopano Core.

Pentru un endpoint orientat spre browser, urmați cu:

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

Rezultatul detaliat ajută la distingerea verificării TLS de un răspuns HTTP, cum ar fi o redirecționare, 404 sau 502. Un mesaj 404 după o handshake finalizată este o problemă de cale sau de rutare, nu o eroare de negociere TLS. Doar pentru o singură diagnosticare, curl -vkpoate arăta dacă ocolirea verificării certificatului modifică rezultatul. Nu lăsați verificările certificatelor dezactivate într-un browser, client sau proxy.

Limită importantă: TLS-ul nativ Kopano Core poate utiliza certificate client. Un s_clienttest de bază fără un certificat client poate fi respins chiar și atunci când listener-ul TLS funcționează corect. Dacă serverul solicită autentificarea clientului, repetați testul cu certificatul și cheia clientului autorizate sau testați cu clientul de serviciu Kopano configurat. Nu expuneți niciodată o cheie privată într-o transcriere a comenzilor sau într-un tichet de asistență.

3. Potriviți protocolul cu ascultătorul

O greșeală frecventă legată de portul personalizat este configurarea unui client HTTPS pentru a contacta un ascultător HTTP simplu sau redirecționarea traficului HTTPS către un upstream care așteaptă HTTP. Schema și portul trebuie să descrie același endpoint.

• https://mail.example.com:8443/webapp/înseamnă că browserul așteaptă TLS pe ​​portul 8443.
• Exemplul documentat al Kopano Core trimite HTTP prin proxy către 127.0.0.1:236. Dacă implementarea dvs. folosește acel model, proxy-ul din amonte trebuie să utilizeze http://, chiar dacă conexiunea browserului public folosește HTTPS.
• Pentru TLS Kopano Core nativ, exemplul din manual folosește server_listen_tls = *:237și o adresă URL a clientului care începe cu https://. Dacă schimbați 237 într-un port personalizat, actualizați fiecare client sau proxy dependent la aceeași valoare.

Verificați dacă există linii de configurare copiate care nu sunt în concordanță cu portul sau schema. Într-o configurație multi-server, verificați și adresa URL publicată a serverului sau proxy-ului: un client poate finaliza o conexiune inițială și apoi poate eșua după ce Kopano îl redirecționează către un nume de gazdă sau un port vechi.

4. Reparați configurația listenerului și a certificatului

Dacă acesta este listener-ul TLS nativ al Kopano Core, editați configurația existentă în loc să adăugați directive duplicate. Următorul este un exemplu simplificat pentru un port personalizat; păstrați căile de certificat și CA-ul corespunzătoare instalării dvs.:

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

Manualul Kopano specifică setările pentru listener, CA, cheia serverului și password-ul și necesită repornirea kopano-serverdupă această modificare a listener-ului nativ. Confirmați că versiunea instalată acceptă opțiunile afișate; aspectele pachetelor și directivele pot diferi. Protejați directorul cheilor și asigurați-vă că contul de serviciu Kopano poate citi fișierele necesare.

Verificați dacă certificatul este pentru numele de gazdă pe care îl utilizează efectiv clienții, dacă se încadrează în datele sale de valabilitate și dacă include toate certificatele intermediare necesare. Manualul Kopano menționează că componentele sale verifică numele comun al certificatului și numele alternative ale subiectului. Într-o configurație TLS multi-server, serverul trebuie să aibă încredere și în CA-ul care a semnat certificatele clientului, iar certificatele client autorizate trebuie configurate. Nu înlocuiți un certificat cu unul autosemnat ca o comandă rapidă pentru un serviciu de browser public.

Dacă TLS se termină la Apache, Nginx sau Kopano Web, configurați certificatul și listenportul personalizat la acel front-end. Apoi, setați schema și portul upstream în funcție de listener-ul real al backend-ului. Nu activați TLS upstream doar pentru că partea publică folosește HTTPS; mai întâi confirmați că și portul backend deservește TLS.

5. Validați și reîncărcați serviciul corect

Înainte de a reîncărca un server web, rulați verificarea configurației acestuia, cum ar fi sudo nginx -tpentru Nginx sau sudo apachectl configtestpentru Apache. Dacă testul raportează o eroare, corectați-o înainte de reîncărcare. Folosiți numele serviciului instalat pe distribuția dvs.; de exemplu:

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

Reporniți Kopano Core numai după ce ați modificat configurația sa. Pentru o modificare a portului sau a certificatului exclusiv pentru front-end, validați și reîncărcați serviciul front-end. Verificați jurnalul sau jurnalul de erori imediat după modificare și repetați proba OpenSSL exactă din rețeaua clientului. Strângerea de mână ar trebui să prezinte acum certificatul așteptat. Apoi, testați adresa URL WebApp reală sau conexiunea clientului Kopano, deoarece succesul TLS nu validează ruta aplicației sau autentificarea.

Citiți rezultatul înainte de a schimba mai multe

• Niciun socket de ascultare: verificați listener-ul configurat, starea serviciului și adresa de legare.
• Conexiune refuzată sau expirare: verificați firewall-ul, NAT-ul, echilibratorul de încărcare și dacă portul țintă este accesibil.
• Certificat greșit: verificați certificatul configurat pe endpoint-ul care răspunde la portul respectiv, inclusiv selecția SNI și lanțul de certificate.
• TLS funcționează local, dar nu de la distanță: comparați calea proxy-ului public sau a echilibratorului de încărcare cu listener-ul local și examinați valorile gazdei și portului redirecționate.
• Strângerea de mână reușește, dar WebApp eșuează: verificați starea HTTP, calea proxy, jurnalele PHP/WebApp și conectivitatea Kopano Core. Continuați la nivelul aplicației.
• Doar clienții Core eșuează: verificați server_socketsetările lor, portul personalizat, CA-ul de încredere și certificatul clientului. Calea Core TLS poate necesita autentificare reciprocă a certificatului.

O soluție fiabilă modifică doar endpoint-ul care deține handshake-ul eșuat. Manualul Kopano Core Administrator disponibil pentru această procedură este versiunea 8.0.0, iar exemplele sale trebuie verificate în raport cu pachetele instalate și paginile de manual locale. Dacă implementarea dvs. utilizează o altă versiune de Kopano, un container sau un proxy invers gestionat, confirmați configurația curentă a componentei respective înainte de a aplica directivele eșantion.