Remediați certificatul Zimbra expirat: Reînnoiți certificatele autosemnate în siguranță

Un server Zimbra poate părea funcțional până când utilizatorii afișează brusc un avertisment în browser, cum ar fi „certificat expirat”, clienții de e-mail refuză o conexiune SSL/TLS sau un administrator descoperă că data certificatului a expirat. Cel mai rapid răspuns sigur nu este înlocuirea imediată a fiecărei componente a certificatului. Mai întâi, determinați ce a expirat, apoi reînnoiți cea mai mică parte necesară.

Procedura actuală a Centrului Tehnic Zimbra pentru o implementare autosemnată pe un singur server folosește zmcertmgrpentru a crea și implementa certificate. Este important de menționat că Zimbra precizează că crearea unei noi autorități de certificare (CA) este opțională pentru o reînnoire obișnuită a unui certificat autosemnat; nu este nevoie să înlocuiți CA de fiecare dată când expiră certificatul serverului. Referințele oficiale utilizate pentru acest ghid au fost verificate pe 6 octombrie 2026: Regenerarea certificatului SSL autosemnat — Instrumente pentru consola de administrare și CLI pentru certificate .

De ce un certificat Zimbra expirat cauzează probleme reale de service

Zimbra utilizează certificate TLS în servicii precum interfața web, proxy, LDAP și protocoalele de e-mail. Odată ce un certificat a depășit perioada sa de valabilitate, clienții pot respinge conexiunea chiar dacă procesele Zimbra subiacente sunt încă în execuție. Prin urmare, un avertisment al browserului este doar un simptom. În funcție de topologia și politica clientului, este posibil să observați și conexiuni IMAP/POP/SMTP securizate eșuate, erori de proxy sau probleme LDAP/TLS.

Există două cazuri diferite de expirare de distins:

• Doar certificatul serverului a expirat. Acesta este cazul mai simplu. Păstrați CA-ul Zimbra existent dacă este încă valid, generați un nou certificat de server, implementați-l și reporniți serviciile.
• Certificatul de certificare Zimbra în sine a expirat. Recreați și implementați certificatul de certificare, apoi creați și implementați un nou certificat de server semnat de acel certificat de certificare. Într-o implementare multi-server, consecvența certificatului de certificare între noduri contează, așadar nu tratați un mediu multi-nod ca pe un singur server.

Înainte de a face modificări, realizați o copie de rezervă sau o instantanee actualizată, adecvată mediului dumneavoastră. Regenerarea certificatelor este în mod normal simplă, dar o copie de rezervă vă oferă un punct de recuperare dacă serverul are personalizări mai vechi, certificate instalate manual sau o topologie mixtă.

Pasul 1: Confirmați că certificatul implementat a expirat

Comutați la contul Zimbra și verificați certificatul implementat în prezent pentru serviciile locale:

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

Verificați datele de valabilitate și subiectul certificatului. Dacă certificatul este încă în perioada de valabilitate, investigați nepotrivirea numelui de gazdă, o CA autosemnată neîncrezătoare, un certificat vechi încă servit de un proxy sau o oră incorectă a serverului/clientului în loc să regenerați certificatele în mod inutil.

De asemenea, puteți verifica certificatul pe care un client la distanță îl primește efectiv pe HTTPS. Înlocuiți-l mail.example.comcu numele de gazdă la care se conectează utilizatorii:

openssl s_client -connect mail.example.com:443 -servername mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Această verificare la distanță este utilă atunci când viewdeployedcrtarată corect, dar browserele încă văd un certificat vechi, deoarece testează certificatul prezentat prin rețea și nu doar fișierele de pe disc.

Pasul 2: Verificați starea serviciului și decideți dacă este necesară și reînnoirea CA-ului

Înainte de a schimba certificatele, confirmați starea curentă a serviciului Zimbra, astfel încât să aveți o bază:

zmcontrol status

Dacă doar certificatul serverului a expirat și CA-ul Zimbra este încă valid, săriți peste recrearea CA-ului și treceți direct la comenzile server-certificate din secțiunea următoare. Acest lucru minimizează modificările aduse lanțului de încredere. Documentația Zimbra pentru servere individuale precizează explicit că crearea unui nou CA este opțională și nu este necesară de fiecare dată când reînnoiți un certificat autosemnat.

Dacă autorizația de certificare (CA) a expirat sau aveți un motiv documentat pentru a o înlocui, creați una nouă:

/opt/zimbra/bin/zmcertmgr createca -new
/opt/zimbra/bin/zmcertmgr deployca

Pasul 3: Generați și implementați un nou certificat de server autosemnat

Pentru o reînnoire simplă pe un singur server, Zimbra documentează următoarea secvență. Exemplul creează un certificat valabil timp de 365 de zile:

/opt/zimbra/bin/zmcertmgr createcrt -new -days 365
/opt/zimbra/bin/zmcertmgr deploycrt self

Dacă clienții se conectează prin mai multe nume DNS, generați certificatul cu numele alternative ale subiectului necesare, în loc să presupuneți că numele de gazdă implicit este suficient. Instrumentul de certificare Zimbra acceptă -subjectAltNames. De exemplu:

/opt/zimbra/bin/zmcertmgr createcrt -new -days 365 -subjectAltNames "mail.example.com,webmail.example.com"
/opt/zimbra/bin/zmcertmgr deploycrt self

Folosește nume care se rezolvă cu adevărat la acest serviciu Zimbra și pe care utilizatorii sau integrările tale le folosesc efectiv. Un certificat poate fi neexpirat, dar totuși să eșueze validarea dacă numele de gazdă solicitat nu este acoperit de valorile subiect/SAN ale acestuia.

Nu utilizați această procedură autosemnată pentru a suprascrie accidental un certificat comercial/de încredere publică. Dacă serverul dvs. ar trebui să utilizeze un certificat comercial, opriți-vă aici și urmați în schimb procedura de implementare a certificatelor comerciale Zimbra.

Pasul 4: Verificați implementarea, reporniți Zimbra și testați din partea clientului

Confirmați că Zimbra a implementat noul certificat:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Apoi reporniți Zimbra astfel încât serviciile să încarce noul certificat:

zmcontrol restart

După finalizarea repornirii, executați:

zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Rezultatul dorit este simplu: serviciile așteptate rulează, iar certificatul implementat are acum o dată de expirare viitoare. În cele din urmă, repetați testul OpenSSL la distanță pentru numele de gazdă pe care utilizatorii îl accesează efectiv. Aceasta dovedește ce se servește în rețea după repornire.

Dacă browserul afișează în continuare certificatul vechi sau expirat

Nu regenerați imediat un alt certificat. Parcurgeți straturile rămase în ordine:

• Confirmați DNS-ul și numele de gazdă. Asigurați-vă că testați același nume de gazdă acoperit de noul certificat și că accesați serverul Zimbra dorit.
• Verificați calea proxy. Documentația de depanare a certificatelor Zimbra menționează că un proxy poate continua să prezinte un certificat vechi în anumite cazuri. Inspectați certificatul prezentat de la distanță, nu doar fișierele de certificat locale. Consultați Erori de certificat Zimbra .
• Verificați încrederea clientului. Un certificat autosemnat reînnoit poate fi valid până la data respectivă, dar în același timp nu este considerat de browsere sau clienți de e-mail de încredere. Expirarea și încrederea sunt aspecte separate.
• Verificați ora sistemului. Un ceas incorect pe server sau client poate face ca un certificat altfel valid să pară încă nevalid sau expirat.
• Verificați CA-ul. Dacă certificatul principal este nou, dar CA-ul Zimbra emitent a expirat, înlocuiți CA-ul și regenerați certificatul serverului de la noul CA.

Zimbra multi-server necesită un nivel diferit de îngrijire

Pentru o instalare cu mai multe noduri, utilizați procedura multi-server în loc să repetați orbește comenzile pe un singur server pe fiecare gazdă. Zimbra documentează crearea/implementarea CA-ului și apoi implementarea certificatului autosemnat pe noduri cu deploycrt self -allserver; de asemenea, avertizează că viewdeployedcrtraportează doar serverul local. Referința oficială este Regenerate Self-Signed SSL Certificate — Multi-Server .

Nepotrivirea CA dintre un master LDAP și replici poate crea probleme TLS și de replicare. Dacă operați o topologie multi-server, verificați lanțul CA pe fiecare nod afectat și urmați ordinea de implementare documentată.

Autoverificare: cum să știi că repararea este completă

Înainte de a închide incidentul, verificați toate următoarele:

• zmcontrol statusarată rularea serviciilor Zimbra așteptate.
• zmcertmgr viewdeployedcrtarată un certificat a cărui dată de expirare este în viitor.
• O openssl s_clientverificare la distanță returnează aceleași date noi de certificat pentru numele de gazdă public/intern pe care utilizatorii îl utilizează efectiv.
• Subiectul certificatului sau SAN-ul acoperă numele de gazdă respectiv.
• Webmail-ul și protocoalele de e-mail utilizate de mediul dvs. pot stabili conexiuni TLS.
• Dacă ați înlocuit intenționat CA-ul Zimbra, clienții sau sistemele interne care fixează sau au încredere în vechiul CA au fost actualizate după cum este necesar.

Pentru o expirare de rutină a unui singur server, cea mai puțin perturbatoare cale este de obicei păstrarea unui CA Zimbra încă valid, crearea unui nou certificat de server autosemnat, implementarea acestuia, repornirea serviciilor și verificarea certificatului din afara serverului. Înlocuiți CA-ul numai atunci când a expirat sau există un alt motiv clar pentru rotirea lui. Această abordare remediază întreruperea imediată, evitând în același timp modificările inutile ale lanțului de încredere.