Remediați erorile de federație Matrix Synapse „Verificarea certificatului SSL a eșuat”

O eroare comună a Matrix Synapse pare înșelător de simplă: clienții locali se pot conecta, proxy-ul invers este online, iar Synapse în sine poate părea sănătoasă, însă serverele de acasă la distanță nu se pot federa cu dvs. Jurnalele de pe o parte pot conține fraze precum certificate verify failed, hostname mismatch, unable to get local issuer certificate, sau o eroare generică a cererii de federare cauzată de verificarea TLS.

Cea mai rapidă metodă de a remedia acest lucru este să testați numele exact de gazdă și portul la care se rezolvă descoperirea federației Matrix, apoi să reparați certificatul, lanțul sau calea de descoperire greșită. Nu începeți prin a dezactiva verificările certificatelor. Traficul Matrix de la server la server este HTTPS, iar specificația Matrix impune ca destinația să prezinte un certificat semnat de o autoritate de certificare de încredere. Synapse menține, de asemenea, activată în mod implicit verificarea certificatelor de federație de ieșire. Consultați specificația API-ului Matrix Server-Server și documentația actuală de configurare Synapse .

1. Identificați numele de gazdă pe care federația îl validează efectiv

Înainte de a schimba Nginx, Caddy, Synapse sau DNS, determinați numele certificatului așteptat de Matrix. Răspunsul depinde de configurația dvs. server_nameși de descoperirea serverului.

Dacă numele serverului dvs. Matrix este example.comși nu delegați federația, alte servere de domiciliu încearcă în mod normal serviciul de federație asociat cu acel nume, de obicei pe TCP 8448. Dacă serviți https://example.com/.well-known/matrix/server, m.servervaloarea poate delega federația către un alt nume de gazdă, cum ar fi matrix.example.com:443. În acest caz, numele de gazdă delegat face parte din calea de validare TLS. Matrix acceptă, de asemenea, descoperirea bazată pe SRV, dar documentația Synapse recomandă .well-knowndelegarea pentru implementări tipice, deoarece este mai ușor de raționat și de configurat corect. Comportamentul autoritar este documentat în descoperirea serverelor în specificația Matrix și în delegarea federației Synapse .

curl -fsS https://example.com/.well-known/matrix/server

Un răspuns delegat poate arăta astfel:

{
  "m.server": "matrix.example.com:443"
}

Dacă fișierul lipsește sau este invalid, nu presupuneți că aceasta este în sine eroarea TLS. Matrix are reguli de descoperire de rezervă. Important este să știți ce nume de gazdă și port va contacta în final un server la distanță.

2. Reproduceți eroarea de verificare a certificatului cu OpenSSL

După ce cunoașteți endpoint-ul de federație așteptat, testați-l direct cu verificarea SNI și a numelui de gazdă. Aceasta diferențiază o problemă de identitate TLS de o problemă a aplicației Synapse.

openssl s_client   -connect example.com:8448   -servername example.com   -verify_hostname example.com   -showcerts </dev/null

Pentru o gazdă delegată pe 443, modificați atât destinația conexiunii, cât și numele de gazdă așteptat:

openssl s_client   -connect matrix.example.com:443   -servername matrix.example.com   -verify_hostname matrix.example.com   -showcerts </dev/null

Concentrați-vă pe rezultatul final al verificării și pe numele alternative ale subiectului certificatului. O conexiune poate reuși la nivelul protocolului TCP și TLS, dar verificarea identității poate eșua. De aceea, „portul este deschis” nu este suficient.

Ce înseamnă de obicei cele mai frecvente erori OpenSSL

• Nepotrivire nume gazdă: proxy-ul invers a servit un certificat pentru un nume gazdă diferit sau înregistrarea de descoperire direcționează federația către un nume gazdă care nu este acoperit de certificat.
• Imposibil de obținut certificatul emitentului local / imposibil de verificat primul certificat: serverului îi lipsește adesea un certificat CA intermediar din lanț sau depozitul de încredere al clientului nu are încredere în CA emitent.
• Certificatul a expirat / nu este încă valid: reînnoiți certificatul și verificați și ceasul sistemului atât pe server, cât și pe orice client de federație privată strict controlat.
• Certificat autosemnat: federația publică îl va respinge în mod normal. Pentru o federație privată, utilizați un CA privat și configurați explicit încrederea, în loc să dezactivați verificarea globală.

3. Remediați o nepotrivire de nume de gazdă la proxy-ul invers

O nepotrivire a numelui de gazdă este deosebit de frecventă atunci când site-ul orientat către client și endpoint-ul de federație utilizează gazde virtuale diferite. De exemplu, example.compoate găzdui un site web în timp ce matrix.example.comSynapse folosește proxy-uri. Dacă .well-knownfișierul dvs. deleagă către matrix.example.com:443, endpoint-ul TLS de pe gazda respectivă trebuie să ofere un certificat valid pentru matrix.example.com.

Pentru Nginx, inspectați gazda virtuală activă, nu doar fișierul de configurare pe care intenționați să îl utilizați:

sudo nginx -T | less

Verificați căile server_name, portul de ascultare și certificatele. O secțiune TLS tipică folosește întregul lanț de certificate:

server {
    listen 443 ssl;
    server_name matrix.example.com;

    ssl_certificate /etc/letsencrypt/live/matrix.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/matrix.example.com/privkey.pem;

    location /_matrix {
        proxy_pass http://127.0.0.1:8008;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

Validați și reîncărcați numai după ce testul de configurare reușește:

sudo nginx -t && sudo systemctl reload nginx

Synapse recomandă un proxy invers pentru implementările comune și distinge portul client obișnuit 443 de portul de federație implicit 8448. Consultați documentația oficială a proxy-ului invers Synapse pentru cerințele actuale de proxy.

4. Serviți întregul lanț de certificate

Un certificat frunză poate arăta corect într-un browser pe care îl utilizați deja și totuși să eșueze pentru un alt server principal dacă serverul dvs. nu trimite certificatul intermediar necesar. Documentația Synapse spune explicit că, atunci când Synapse în sine este configurat cu un certificat, fișierul PEM ar trebui să conțină lanțul complet; cu Certbot, asta înseamnă utilizarea fullchain.pemîn loc de doar cert.pem.

Același principiu se aplică atunci când TLS se termină la Nginx, Caddy, HAProxy sau alt proxy: configurați proxy-ul respectiv pentru a prezenta lanțul complet corect. Inspectați ce este de fapt servit, nu doar ce există pe disc:

openssl s_client   -connect matrix.example.com:443   -servername matrix.example.com   -showcerts </dev/null

Ar trebui să vedeți certificatul principal urmat de certificatul sau certificatele intermediare necesare. În general, nu este necesar ca CA-ul rădăcină să fie trimis de server, deoarece clienții au deja încredere în rădăcini prin intermediul depozitului lor de încredere.

5. Verificați DNS și Matrix Discovery pentru rutare învechită sau divizată

Dacă certificatul este corect pe o mașină, dar federația la distanță raportează în continuare un certificat diferit, este posibil ca DNS să direcționeze unii clienți în altă parte. Verificați atât înregistrările IPv4, cât și cele IPv6 și rețineți că o înregistrare A funcțională nu compensează o înregistrare AAAA învechită dacă serverele de acasă la distanță preferă IPv6.

dig +short A example.com
dig +short AAAA example.com
dig +short A matrix.example.com
dig +short AAAA matrix.example.com

De asemenea, inspectați orice înregistrări SRV ale federației pe care le utilizați intenționat:

dig +short SRV _matrix-fed._tcp.example.com

Dacă ați modificat recent .well-known, permiteți memorarea în cache. Specificația Matrix permite clienților să stocheze în cache răspunsurile de descoperire și chiar încercările de descoperire eșuate pentru o perioadă de timp. Aceasta înseamnă că o configurație poate fi corectă acum, în timp ce un server la distanță continuă temporar să utilizeze rutarea descoperită anterior.

Când există atât A, cât și AAAA, executați verificarea TLS pentru fiecare rută, dacă este necesar. Dacă un echilibrator de încărcare se conectează la mai multe noduri proxy, verificați dacă fiecare nod are același certificat și același lanț curent.

6. Remediați încrederea între CA-uri private fără a slăbi federația publică

Federația privată este principalul caz legitim în care o autoritate de certificare (CA) publică poate să nu fie potrivită. Synapse oferă federation_custom_ca_listautorități personalizate. Documentația actuală menționează un comportament important: această listă înlocuiește certificatele CA furnizate de mediul de operare. Prin urmare, dacă o setați, includeți setul complet de încredere necesar implementării dvs.

federation_custom_ca_list:
  - /etc/synapse/ca/private-federation-ca.pem

După modificarea configurației de încredere, reporniți Synapse utilizând mecanismul de service pentru instalare și inspectați jurnalele pentru erori de certificat. Implementările containerelor merită, de asemenea, o atenție specială: gazda poate avea încredere într-o CA privată, în timp ce containerul Synapse nu are. Confirmați că materialul de încredere este montat în container și că calea configurată este lizibilă din interiorul acestuia.

Synapse expune federation_certificate_verification_whitelistși comutatorul global federation_verify_certificates, dar documentația oficială restricționează aceste situații la scenarii excepționale. Dezactivarea verificării la nivel global poate face ca eroarea să dispară, lăsând în același timp problema identității subiacente nerezolvată. Pentru o federație publică obișnuită, reparați certificatul sau rutarea.

7. Verificați mai întâi repararea la nivelul TLS

După efectuarea modificărilor, repetați exact comanda OpenSSL care a eșuat anterior. Scopul este o verificare reușită a numelui de gazdă și a lanțului pentru endpoint-ul la care se rezolvă descoperirea Matrix.

Apoi, faceți o solicitare HTTPS către un punct final de federație. Pentru un punct final direct pe 8448:

curl -v https://example.com:8448/_matrix/federation/v1/version

Pentru un punct final delegat pe 443:

curl -v https://matrix.example.com/_matrix/federation/v1/version

Un rezultat TLS valid ar trebui să arate că certificatul s-a verificat cu succes. Punctul final Matrix ar trebui apoi să returneze un răspuns HTTP de la serverul principal sau de la calea proxy, în loc să eșueze în timpul validării certificatului. Punctul final al versiunii în sine este util pentru testarea accesibilității; nu dovedește că fiecare cameră sau server la distanță se va federa corect.

8. Verificați jurnalele Synapse și distingeți TLS de erorile de federație de nivel superior

Dacă verificarea TLS reușește acum, dar federația încă eșuează, nu o mai tratați ca pe o problemă de certificat. Urcați stiva și inspectați jurnalele Synapse pentru erori DNS, expirari de conexiune, erori de stare HTTP, probleme ale cheii de semnare, erori de autorizare sau întreruperi ale serverului la distanță.

În instalările bazate pe systemd, un punct de plecare comun este:

journalctl -u matrix-synapse -n 200 --no-pager

Pentru Docker, utilizați jurnalele containerului pentru serviciul dvs. Synapse. Căutați în jurul marcajului temporal al unei noi încercări de federare, în loc să vă bazați pe mesaje de certificat vechi care s-ar putea să nu mai fie relevante.

Tabel de decizie rapidă

Cum să știi că problema este într-adevăr rezolvată

Nu utilizați „serviciul a fost repornit fără erori” drept criteriu de succes. O reparație fiabilă are trei semne observabile: numele exact al gazdei federației trece verificarea numelui de gazdă, lanțul servit se validează pentru o CA de încredere și o nouă solicitare HTTPS a federației ajunge la Synapse fără o excepție de verificare TLS.

Dacă după aceste verificări, doar un singur server de acasă la distanță încă eșuează, luați în considerare memorarea în cache, depozitul de încredere al serverului respectiv sau o cale de rețea specifică punctului final. Dacă mai multe servere de acasă publice fără legătură eșuează în același mod, verificați din nou mai întâi propriul certificat, ruta IPv6, nodurile de echilibrare a încărcării și configurația de descoperire.

Pentru sistemele de producție, mențineți activată verificarea certificatelor și faceți ca reînnoirea certificatelor să fie observabilă. Soluția durabilă nu este suprimarea verificării; este asigurarea că Matrix Discovery, DNS, SNI, proxy-ul invers și lanțul de certificate descriu toate același endpoint de federație.