Cum se instalează un certificat SSL comercial pe un server Zimbra

Un certificat SSL comercial pe Zimbra poate eșua în mai multe moduri frustrante, chiar și atunci când autoritatea de certificare spune că certificatul a fost emis corect. Cele mai frecvente probleme nu sunt de obicei certificatul în sine: cheia privată nu se potrivește cu certificatul returnat, lipsește o autoritate de certificare intermediară, numele de gazdă lipsește din numele alternativ al subiectului (SAN) al certificatului sau administratorul implementează fișierele înainte de a valida lanțul.

Cea mai sigură modalitate de a gestiona această sarcină este să o tratați ca pe o secvență de verificări, mai degrabă decât ca pe o singură comandă de „instalare certificat”. Instrumentul de certificare documentat al Zimbra, zmcertmgr, poate crea o cerere de semnare a certificatului (CSR), poate verifica cheia privată și lanțul CA, poate implementa certificatul către serviciile Zimbra și poate afișa certificatul activ în prezent. Centrul tehnic oficial Zimbra documentează aceste comenzi în ghidul său Administration Console și CLI Certificate Tools .

Cum ar trebui să arate o instalare SSL Zimbra reușită

Înainte de a schimba orice, definește rezultatul dorit. O implementare corectă ar trebui să îndeplinească toate aceste condiții:

• Lista SAN a certificatului include fiecare nume de gazdă public pe care clienții îl utilizează efectiv, cum ar fi mail.example.com.
• Certificatul emis corespunde cu cheia privată stocată pentru certificatul comercial.
• Zimbra poate valida întregul lanț, de la certificatul serverului, prin certificatele CA intermediare și până la CA rădăcină.
• zmcertmgr deploycrt commse finalizează fără o eroare de nepotrivire a cheii sau de validare a lanțului.
• Serviciile Zimbra repornesc fără probleme.
• zmcertmgr viewdeployedcrtarată certificatul așteptat.
• Un browser sau un client TLS care se conectează la numele de gazdă public vede noul certificat și un avertisment de lipsă de încredere.

Dacă una dintre aceste verificări eșuează, remediați stratul respectiv înainte de a continua. Redistribuirea repetată a acelorași fișiere rezolvă rareori o problemă de cheie, SAN sau lanț.

Înainte de a începe: alegeți fluxul de lucru potrivit pentru certificate

Pagina actuală a Centrului Tehnic Zimbra menționează că pe Zimbra 8.7 și versiunile ulterioare, zmcertmgrse execută ca zimbrautilizator. De asemenea, documentează că cheia privată comercială trebuie denumită commercial.keyîn /opt/zimbra/ssl/zimbra/commercialși că certificatul serverului plus fișierul CA-chain ar trebui să fie stocate într-un director temporar înainte de implementare.

Pasul 1: faceți o copie de rezervă a materialului certificatului curent

Nu începeți prin a șterge directorul SSL existent. Mai întâi creați o copie de rezervă pe care o puteți restaura dacă noua implementare eșuează. Ca root, un exemplu conservator este:

cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.backup-$(date +%Y%m%d-%H%M%S)

De asemenea, înregistrați certificatul implementat curent înainte de a-l modifica:

su - zimbra
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Aceasta vă oferă o bază pentru comparație după modificare. Dacă mediul dvs. are mai multe noduri Zimbra, capturați starea curentă a certificatului pe fiecare server relevant, în loc să presupuneți că sunt identice.

Pasul 2: generați un CSR cu numele de gazdă de care aveți nevoie

Pentru un nou certificat comercial, creați CSR-ul cu numele de gazdă de producție și orice SAN-uri suplimentare. Zimbra documentează următoarea sintaxă:

/opt/zimbra/bin/zmcertmgr createcsr comm -new \
-subject "/C=US/ST=CA/L=Sunnyvale/O=Example/OU=IT/CN=mail.example.com" \
-subjectAltNames "mail.example.com"

Dacă utilizatorii se conectează și printr-un alt nume, cum ar fi webmail.example.com, includeți-l în lista SAN atunci când solicitați certificatul. Clienții TLS moderni validează numele de gazdă în raport cu SAN-urile, astfel încât un certificat care pare corect doar după numele comun poate genera în continuare un avertisment de browser dacă numele de gazdă lipsește.

Verificați CSR-ul înainte de a-l trimite autorității de certificare:

/opt/zimbra/bin/zmcertmgr viewcsr comm /opt/zimbra/ssl/zimbra/commercial/commercial.csr

Punct de control: opriți-vă aici dacă numele DNS solicitate sunt greșite. Emiterea certificatului mai întâi și descoperirea ulterioară a unui SAN lipsă înseamnă, în mod normal, că este nevoie ca CA să îl emită din nou.

Pasul 3: colectați certificatul serverului și întregul lanț CA

După validare, CA-ul dumneavoastră comercial returnează în mod normal certificatul serverului plus unul sau mai multe certificate intermediare. Procedura oficială Zimbra pentru certificate comerciale cu un singur nod așteaptă certificatul serverului în format PEM și instruiește administratorii să combine certificatele CA intermediare și rădăcină într-un fișier lanț.

O structură tipică de punerea în scenă este:

/tmp/commercial.crt
/tmp/ca_intermediary.crt
/tmp/ca.crt

Apoi construiți lanțul în ordinea documentată de Zimbra:

cat /tmp/ca_intermediary.crt /tmp/ca.crt > /tmp/ca_chain.crt

Folosește fișierele furnizate de autoritatea ta de certificare pentru produsul tău de certificat exact. Nu copiază un certificat intermediar dintr-un tutorial fără legătură doar pentru că numele de marcă al CA-ului arată similar. Ierarhiile CA-urilor se schimbă în timp, iar un certificat intermediar greșit este o cauză frecventă a erorilor unable to get local issuer certificate.

Pasul 4: verificați cheia privată, certificatul serverului și lanțul înainte de implementare

Aceasta este cea mai importantă poartă de siguranță. Rulați comanda de verificare documentată ca utilizator Zimbra pe versiunile actuale de Zimbra:

su - zimbra
/opt/zimbra/bin/zmcertmgr verifycrt comm \
/opt/zimbra/ssl/zimbra/commercial/commercial.key \
/tmp/commercial.crt \
/tmp/ca_chain.crt

O verificare reușită raportează că certificatul și cheia privată se potrivesc și că certificatul este valid. Documentația instrumentelor de certificare Zimbra explică faptul că aceasta verifycrtcombină o verificare a cheii și o verificare a lanțului de certificate.

Dacă verificarea eșuează, alegeți remedierea în funcție de eroare

• Certificat și cheie privată nepotrivite: certificatul CA nu a fost emis de CSR-ul asociat cu CSR-ul curent commercial.key. Restaurați cheia corectă sau emiteți din nou certificatul de la un CSR nou.
• Nu se poate valida lanțul de certificate: pachetul intermediar/rădăcină este incomplet, în ordine greșită, a expirat sau nu este lanțul pentru acest certificat de server. Obțineți lanțul corect de la autoritatea de certificare emitentă.
• Certificat expirat: nu îl implementați. Solicitați un certificat actual și verificați, de asemenea, dacă un certificat intermediar sau o rădăcină din lanț a expirat. Zimbra documentează acest mod de eroare în ghidul său de depanare a CA-urilor rădăcină expirate .
• Numele de gazdă lipsește: verificarea poate să nu reprezinte aceeași verificare a numelui de gazdă efectuată de un browser. Inspectați SAN-urile emise și emiteți din nou dacă numele public nu este prezent.

Pasul 5: implementați certificatul comercial

Numai după ce verificarea are succes ar trebui să o implementați:

/opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/ca_chain.crt

Procesul de implementare documentat al Zimbra copiază certificatul comercial în zona sa SSL, adaugă lanțul CA, actualizează configurația certificatului și instalează materiale de certificat pentru servicii precum componentele MTA, LDAP, proxy și cutie poștală, după caz ​​pentru server.

Nu suprascrieți manual fișierele Java keystore aleatorii sau fișierele cu certificate de serviciu, cu excepția cazului în care documentația pentru versiunea dvs. exactă de Zimbra o impune în mod specific. Scopul este zmcertmgrde a menține consecvența materialului certificatului specific serviciului.

Pasul 6: reporniți serviciile Zimbra

După implementare, reporniți Zimbra:

su - zimbra
zmcontrol restart

Apoi verificați starea serviciului:

zmcontrol status

Dacă un serviciu nu revine la Running, investigați înainte de a declara modificarea certificatului finalizată. Problemele legate de certificat pot afecta LDAP, proxy, cutie poștală sau alte comunicări dependente de TLS, în special în instalările cu mai multe noduri.

Pasul 7: verificați rezultatul atât din partea Zimbra, cât și din partea clientului

Folosește mai întâi vizualizarea certificatului propriu a Zimbra:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

De asemenea, puteți verifica dacă vreun certificat de serviciu implementat este aproape de expirare:

/opt/zimbra/bin/zmcertmgr checkcrtexpiration all -days 30

În cele din urmă, testați numele public exact al gazdei pe care utilizatorii o deschid. O verificare OpenSSL utilă de pe o altă mașină este:

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

Căutați certificatul frunză așteptat, numele de gazdă corect, un lanț complet și un rezultat de verificare reușit. Apoi deschideți aceeași adresă URL HTTPS într-un browser curent. Un test al browserului este important deoarece verifică numele de gazdă la care ajung utilizatorii, nu doar fișierele de certificat de pe disc.

Când procedura standard nu este suficientă

Schimbați abordarea în loc să impuneți pașii cu un singur nod dacă se aplică oricare dintre aceste condiții:

• Zimbra multi-nod: implementarea certificatelor poate necesita acoperirea rolurilor proxy, mailbox, LDAP și MTA pe diferite gazde. Instrumentul de certificare Zimbra acceptă opțiuni multi-server, dar verificați procedura pentru topologia dvs. înainte de a le utiliza.
• Proxy-ul invers sau echilibratorul de încărcare extern termină TLS: este posibil să fie nevoie și de instalarea certificatului public pe dispozitivul respectiv. Un certificat Zimbra corect nu va schimba ceea ce văd clienții dacă TLS se termină în amonte.
• Importați o cheie existentă: asigurați-vă că este plasată acolo unde Zimbra așteaptă cheia privată comercială și că permisiunile corespund cerințelor versiunii înainte de verificare.
• CA-ul dumneavoastră furnizează doar un pachet intermediar: urmați instrucțiunile curente ale CA-ului pentru lanț, în loc să inventați un certificat rădăcină. Zimbra are nevoie de un lanț pe care să îl poată valida; fișierele exacte depind de emitent.
• Certificatul a fost reînnoit cu același nume de gazdă, dar cu o cheie diferită: actualizați cheia privată corespunzătoare înainte de verificare. Un certificat anterior commercial.keynu poate valida un certificat emis pentru o nouă pereche de chei.

Autoverificare finală

Instalarea este completă numai când toate următoarele condiții sunt adevărate: verifycrtreușește, deploycrtserviciile Zimbra revin la modul Running, viewdeployedcrtafișează noul certificat și o conexiune TLS externă la numele de gazdă real primește același certificat valid fără un avertisment privind încrederea sau numele de gazdă.

Pentru sintaxa comenzilor și comportamentul specific versiunii, utilizați documentația oficială a instrumentelor de certificare Zimbra ca referință principală. Exemplele de aici folosesc mail.example.comca substituent; înlocuiți numele, fișierele de certificat și detaliile organizaționale cu valorile emise pentru mediul dvs.