Risolvi il problema del certificato Zimbra scaduto: rinnova in sicurezza i certificati autofirmati.

Un server Zimbra può sembrare funzionante finché gli utenti non si imbattono improvvisamente in un avviso del browser come "certificato scaduto", i client di posta elettronica rifiutano una connessione SSL/TLS o un amministratore scopre che la data di scadenza del certificato è passata. La soluzione più rapida e sicura non è sostituire immediatamente tutti i componenti del certificato. Innanzitutto, individuate quali componenti sono scaduti e poi rinnovate la parte più piccola necessaria.

La procedura attualmente disponibile nel Tech Center di Zimbra per la distribuzione di certificati autofirmati su un singolo server prevede zmcertmgrla creazione e la distribuzione degli stessi. È importante sottolineare che Zimbra afferma che la creazione di una nuova Autorità di Certificazione (CA) è facoltativa per il rinnovo di un normale certificato autofirmato; non è necessario sostituire la CA ogni volta che il certificato del server scade. I riferimenti ufficiali utilizzati per questa guida sono stati verificati il ​​6 ottobre 2026: Rigenerazione del certificato SSL autofirmato - Server singolo e Console di amministrazione e Strumenti CLI per i certificati .

Perché un certificato Zimbra scaduto causa seri problemi di servizio

Zimbra utilizza certificati TLS per diversi servizi, come l'interfaccia web, il proxy, LDAP e i protocolli di posta elettronica. Quando un certificato non è più valido, i client possono rifiutare la connessione anche se i processi Zimbra sottostanti sono ancora in esecuzione. Un avviso del browser è quindi solo uno dei sintomi. A seconda della topologia e delle policy dei client, potrebbero verificarsi anche errori di connessione sicura IMAP/POP/SMTP, errori del proxy o problemi con LDAP/TLS.

Esistono due diversi casi di scadenza da distinguere:

• Solo il certificato del server è scaduto. Questo è il caso più semplice. Mantieni l'attuale CA di Zimbra se è ancora valida, genera un nuovo certificato server, distribuiscilo e riavvia i servizi.
• L'autorità di certificazione (CA) di Zimbra è scaduta. Ricreala e distribuiscila, quindi crea e distribuisci un nuovo certificato server firmato da tale CA. In una distribuzione multi-server, la coerenza della CA tra i nodi è fondamentale, quindi non trattare un ambiente multi-nodo come un singolo server.

Prima di apportare modifiche, crea un backup o uno snapshot aggiornato, appropriato al tuo ambiente. La rigenerazione dei certificati è solitamente semplice, ma un backup ti offre un punto di ripristino nel caso in cui il server presenti personalizzazioni precedenti, certificati installati manualmente o una topologia mista.

Passaggio 1: Verificare che il certificato distribuito sia effettivamente scaduto

Passa all'account Zimbra e verifica il certificato attualmente distribuito ai servizi locali:

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

Verifica le date di validità e l'oggetto del certificato. Se il certificato è ancora valido, invece di rigenerare i certificati inutilmente, indaga su eventuali incongruenze del nome host, un'autorità di certificazione autofirmata non attendibile, un vecchio certificato ancora utilizzato da un proxy o un orario server/client errato.

È inoltre possibile verificare il certificato che un client remoto riceve effettivamente tramite HTTPS. Sostituire mail.example.comcon il nome host a cui si connettono gli utenti:

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

Questo controllo remoto è utile quando viewdeployedcrtil certificato appare corretto ma i browser continuano a visualizzarne uno obsoleto, perché verifica il certificato presentato sulla rete anziché limitarsi a controllare i file presenti sul disco.

Passaggio 2: Verificare lo stato del servizio e decidere se è necessario rinnovare anche l'autorizzazione CA.

Prima di modificare i certificati, verifica lo stato attuale del servizio Zimbra in modo da avere un punto di riferimento:

zmcontrol status

Se solo il certificato del server è scaduto e la CA di Zimbra è ancora valida, si può saltare la ricreazione della CA e passare direttamente ai comandi relativi al certificato del server nella sezione successiva. In questo modo si riducono al minimo le modifiche alla catena di fiducia. La documentazione di Zimbra per server singoli afferma esplicitamente che la creazione di una nuova CA è facoltativa e non è necessaria ogni volta che si rinnova un certificato autofirmato.

Se l'autorità di certificazione (CA) è scaduta o se si dispone di un motivo documentato per sostituirla, è necessario crearne una nuova:

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

Passaggio 3: Generare e distribuire un nuovo certificato server autofirmato

Per un rinnovo semplice su un singolo server, Zimbra documenta la seguente sequenza. L'esempio crea un certificato valido per 365 giorni:

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

Se i client si connettono tramite più di un nome DNS, generare il certificato con i nomi alternativi del soggetto (Subject Alternative Names, SAM) richiesti anziché presumere che il nome host predefinito sia sufficiente. Lo strumento di certificazione di Zimbra supporta questa -subjectAltNamesfunzionalità. Ad esempio:

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

Utilizza nomi che si risolvano effettivamente in questo servizio Zimbra e che siano effettivamente utilizzati dai tuoi utenti o dalle tue integrazioni. Un certificato può essere ancora valido, ma non superare comunque la convalida se il nome host richiesto non è coperto dai suoi valori Subject/SAN.

Non utilizzare questa procedura di autofirma per sovrascrivere accidentalmente un certificato commerciale/pubblico. Se il tuo server deve utilizzare un certificato commerciale, interrompi qui e segui invece la procedura di implementazione dei certificati commerciali di Zimbra.

Passaggio 4: Verificare la distribuzione, riavviare Zimbra ed eseguire il test dal lato client.

Conferma che Zimbra ha distribuito il nuovo certificato:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Quindi riavvia Zimbra in modo che i servizi carichino il nuovo certificato:

zmcontrol restart

Al termine del riavvio, eseguire:

zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Il risultato desiderato è semplice: i servizi previsti devono essere in esecuzione e il certificato distribuito deve avere una data di scadenza futura. Infine, ripetere il test OpenSSL remoto sull'hostname a cui gli utenti accedono effettivamente. Questo dimostra cosa viene effettivamente servito sulla rete dopo il riavvio.

Se il browser mostra ancora il certificato vecchio o scaduto

Non rigenerare immediatamente un altro certificato. Procedi con i livelli rimanenti nell'ordine corretto:

• Verifica il DNS e il nome host. Assicurati di testare lo stesso nome host coperto dal nuovo certificato e di raggiungere il server Zimbra previsto.
• Verifica il percorso del proxy. La documentazione di Zimbra sulla risoluzione dei problemi relativi ai certificati indica che in alcuni casi un proxy può continuare a presentare un certificato obsoleto. Esamina il certificato presentato in remoto, non solo i file del certificato locale. Consulta la sezione Errori relativi ai certificati di Zimbra .
• Verifica l'affidabilità del client. Un certificato autofirmato rinnovato può essere valido in base alla data di scadenza, pur non essendo considerato attendibile da browser o client di posta elettronica. Scadenza e affidabilità sono due questioni distinte.
• Verifica l'ora di sistema. Un orologio mal impostato sul server o sul client può far apparire un certificato altrimenti valido come non ancora valido o scaduto.
• Verifica l'autorità di certificazione (CA). Se il certificato foglia è nuovo ma la CA emittente di Zimbra è scaduta, sostituisci la CA e rigenera il certificato del server dalla nuova CA.

Zimbra multi-server richiede un livello di attenzione diverso

Per un'installazione multi-nodo, utilizzare la procedura multi-server anziché ripetere ciecamente i comandi per server singolo su ogni host. Zimbra documenta la creazione/distribuzione della CA e la successiva distribuzione del certificato autofirmato su tutti i nodi con deploycrt self -allserver; avverte inoltre che viewdeployedcrtriporta solo il server locale. Il riferimento ufficiale è Rigenera certificato SSL autofirmato - Multi-server .

Una mancata corrispondenza della CA tra un server master LDAP e le repliche può causare problemi TLS e di replica. Se si utilizza una topologia multi-server, verificare la catena CA su ogni nodo interessato e seguire l'ordine di implementazione documentato.

Autoverifica: come capire se la riparazione è completa

Prima di chiudere l'incidente, verificare tutti i seguenti elementi:

• zmcontrol statusmostra i servizi Zimbra previsti in esecuzione.
• zmcertmgr viewdeployedcrtmostra un certificato la cui data di scadenza è futura.
• Una openssl s_clientverifica da remoto restituisce le stesse date di validità dei nuovi certificati per il nome host pubblico/interno effettivamente utilizzato dagli utenti.
• Il soggetto del certificato o SAN copre quel nome host.
• La webmail e i protocolli di posta elettronica utilizzati nel tuo ambiente possono stabilire connessioni TLS.
• Se hai sostituito intenzionalmente la CA di Zimbra, i client o i sistemi interni che si affidano alla vecchia CA sono stati aggiornati come richiesto.

Per la scadenza di routine di un certificato CA su un singolo server, la soluzione meno invasiva consiste solitamente nel mantenere valida una CA Zimbra, creare un nuovo certificato server autofirmato, distribuirlo, riavviare i servizi e verificare il certificato dall'esterno del server. Sostituire la CA solo quando è scaduta o in presenza di un altro valido motivo per la sua rotazione. Questo approccio risolve l'interruzione immediata del servizio evitando modifiche non necessarie alla catena di fiducia.