Certificates (SSL/TLS)

Monitor your servers' web, mail and proxy certificates on one screen; obtain and renew Let's Encrypt certificates automatically, install self-signed or commercial certificates, generate CSRs and define a separate certificate for each domain.

Global administratorAdmin console › Tools and Migration › Certificates

Status dashboard

1. Click Tools and Migration › Certificates in the left tree. The page opens immediately; wait a few seconds while the list is read from the servers.
2. The header holds the three most used actions: Let's Encrypt, Upload certificate and Domain certificate. The other tools are in the More menu: Import wildcard SSL, Install / CSR, View CSR, Proxy CA and Refresh. The menu closes when you click outside it or press Esc. Refresh is also on the console toolbar.
3. The counter cards show the number of certificates that are Total, Valid, Expiring (30d) and Expired. The colour strip on top of a card shows the state (green valid, yellow expiring, red expired); a card is highlighted when its number is above zero.
4. Below are the Let's Encrypt cards (see Status and notifications) and the Server TLS certificates table, which lists, for each server, the subject, issuer, expiry date and status of the ldap, mailboxd, mta and proxy certificates. The table fills in once Zimbra's certificate service (zmcertmgr) has read every server; on a multi-server setup this can take up to a minute.

Numbers in the figure: 1 Certificates in the tree, 2 header buttons, 3 the open More menu, 4 counter cards.

The Certificates screen: header buttons, More menu and counter cards

Installing a commercial or wildcard certificate

Each component is tested separately before installation; if there is an error, the OK button stays disabled.

1. Choose Import wildcard SSL from the More menu. The Install certificate window opens with Action: Commercial / import wildcard selected.
2. Fill in Certificate PEM (it can be the bundle your CA sent), Private key PEM and CA chain PEM.
3. Press Test. The Test result is listed under four headings as OK / Warning / Error:
   • Certificate: readable, its dates, whether the name is in the SAN.
   • Private key: its format and whether it matches the certificate.
   • CA chain: order (leaf → intermediate → root) and dates.
   • Server check: verification on the server with zmcertmgr.
4. If there is no Error, press OK. The certificate is installed and the list refreshes.
5. For the services to use the new certificate, run zmcontrol restart as the zimbra user on the server.

The install window: PEM fields, Test and OK

Bundles and key formats

You can paste the leaf, intermediate and root certificates into the certificate field in any order; the chain is ordered automatically. RSA or EC keys (PKCS#1, PKCS#8, SEC1) are read. Remove the password from a protected key first: openssl pkey -in key.pem -out key-open.pem.

If the key was generated on another machine

Zimbra uses the key on disk during installation. In this case the test shows a Warning; when you tick Upload the key to the server, the key is written to the server (the previous file is backed up) and the installation runs.

Generating a CSR

Choose Install / CSR from the More menu and select Generate CSR only as the Action; fill in CN and Subject Alt Names and press OK. Send the generated PEM text to your certificate provider. Install the certificate from your CA with the steps above.

Self-signed certificate

For test environments, choose Self-signed as the Action in the Install / CSR window and fill in CN and Subject Alt Names. Browsers warn about this certificate; use a commercial certificate in production.

A separate certificate for each domain

If you host several domains, each domain can serve its own certificate on its own address (for example zpe.profelis.net). The browser announces the name it wants when connecting (SNI); the proxy serves that name's domain certificate. Addresses without a domain certificate keep using the server certificate.

1. Click Domain certificate in the header. The Domain certificate window shows the selected domain's Current certificate.
2. Choose the domain in the Domain list and enter the name users connect to in Virtual hostname (for example mail.zpe.profelis.net). If the domain already has a name, the field is filled in.
3. If several domains share one proxy IP, or the name's DNS record does not point to this proxy, enter that IP in Virtual IP address (written to zimbraVirtualIPAddress). Otherwise leave it empty: nginx listens on the address the name resolves to.
4. Paste Certificate PEM, Private key PEM and CA chain PEM.
5. Press OK. Before saving, these are checked; if any fails, nothing is saved:
   • the key belongs to the certificate,
   • no intermediate certificate is missing,
   • the certificate covers the virtual hostname (SAN; otherwise CN; *.domain is valid),
   • it has not expired.

The Domain certificate window

The certificate is saved on the domain itself. If the virtual hostname or virtual IP is not on the domain it is added; existing values are kept. If zimbraReverseProxySNIEnabled is off it is switched on globally and the message says so. Activate a certificate saved with PEM in this window on each proxy server as the zimbra user and repeat the steps for the other domains (for domain certificates installed with Let's Encrypt or Upload certificate this step runs by itself; see below):

/opt/zimbra/libexec/zmdomaincertmgr deploycrts
zmproxyctl restart

After the restart, open the window again and click Check served certificate. The mailbox server connects to the virtual hostname (on the virtual IP if set) over HTTPS with SNI and shows the result under Served certificate:

• OK: the served certificate covers the name; its expiry date is shown.
• Mismatch: another certificate is served (usually the server certificate). Check the proxy restart, SNI and the virtual IP.
• Expired or a connection error with its reason.

From the command line: openssl s_client -connect <proxy>:443 -servername zpe.profelis.net </dev/null | openssl x509 -noout -subject -enddate

Prerequisites

zimbraReverseProxySNIEnabled must be TRUE (the window switches it on). Each virtual hostname's DNS record must point to the proxy, or the domain needs a Virtual IP address. The domain certificate's key is independent of the server CSR. SMTP (465/587) always serves the server certificate; SNI covers HTTPS and IMAPS/POP3S.

Automatic certificates with Let's Encrypt

You obtain the server certificate (proxy, MTA) or a domain's certificate from Let's Encrypt free of charge and it renews itself before it expires. The certificate is obtained by the Profelis extension on the mailbox server; no extra package is installed on the servers, and port 80 and the HTTP to HTTPS redirect are not changed.

1. Click Let's Encrypt in the header; the Let's Encrypt (automatic) window opens. To change a configured target, use Edit on its card.
2. Enter the Let's Encrypt account address in E-mail. If notifications should go to another address, untick Notifications to the LE address and fill in Notification address.
3. Enter the names the certificate must contain in Names, one per line (for example mail.zpe.profelis.net). Up to 100 names are accepted.
4. Choose the Validation method (details below): HTTP-01 (port 80), DNS (manual TXT) or DNS (RFC2136 dynamic update).
5. In Nodes, tick the servers that receive the certificate (their roles are shown in brackets).
6. Choose the Restart mode and, for automatic, the Restart time.
7. Press Pre-check. DNS and (for HTTP-01) port 80 reachability are checked for each name; nothing is saved.
8. Press Save and enable. The order starts within a minute; follow the progress in the Let's Encrypt section of the screen.

The Let's Encrypt (automatic) window

The current certificate stays in place until the new one is obtained and verified on the server with zmcertmgr verifycrt. If installation fails on a node, the previous certificate is put back on that node.

Key type (advanced settings) is RSA 4096 by default; RSA 2048 and EC P-256 are also available.

Which nodes receive the certificate

By default only externally facing roles (proxy and MTA servers) whose hostname is covered by the certificate names (exact name or *. wildcard) are selected. For example with the name alti.example.com and servers alti and bes, only alti is selected. If none matches, the local server is selected. Selected nodes receive the certificate containing the names in the list; if you use a shared name (e.g. mail.example.com), tick the nodes manually. LDAP and internal mailbox servers keep their current certificates.

Internal names

Let's Encrypt only issues certificates for names that resolve on the internet; internal names such as ldap1.lan cannot be in the certificate. If servers connect to each other by internal names (LDAP starttls, LMTP, proxy to mailbox), do not include those servers, otherwise TLS between servers breaks with a name mismatch. Nodes that are not included show as Not included.

Validation methods

HTTP-01 (port 80). For each name Let's Encrypt fetches http://<name>/.well-known/acme-challenge/<token>. The proxy redirects the request on port 80 to HTTPS; Let's Encrypt follows the redirect and does not check certificate trust at that point, so an expired or self-signed certificate is not a problem. The request reaches the Profelis extension on the mailbox and is answered from LDAP whichever mailbox server it lands on. Requirements:

• Every name must point to this installation (the proxy) in DNS and port 80 must be open from the internet.
• The proxy's zimbraReverseProxyMailMode must be redirect, both or http; in https mode port 80 is closed. The installation package does not change this value; install.sh --verify warns. To open it (as the zimbra user): zmprov ms <proxy> zimbraReverseProxyMailMode redirect and zmproxyctl restart on that proxy.
• A wildcard name (*.zpe.profelis.net) cannot be obtained with HTTP-01; choose one of the DNS methods.

DNS (manual TXT). When the order starts, the TXT records to add for _acme-challenge.<name> are shown on screen and sent by e-mail. Add them to DNS, wait for them to propagate and press TXT added, validate. Suitable for wildcards; every renewal needs a new TXT value.

DNS (RFC2136 dynamic update). The TXT records are added with a TSIG-signed dynamic DNS update and removed afterwards; every renewal runs by itself. Fields: DNS server (the primary name server that accepts updates), Port (53), Zone, TSIG key name, TSIG algorithm (hmac-sha256 or hmac-sha512) and TSIG secret (base64). To generate a key with BIND:

tsig-keygen -a hmac-sha256 pf-acme

Paste the secret value from the output into TSIG secret and give this key TXT update rights only in the zone, for example:

update-policy { grant pf-acme name _acme-challenge.mail.zpe.profelis.net. TXT; };

Once saved, the secret is never shown again; leave the field empty to keep the saved secret.

Restart modes

zmcertmgr deploycrt does not restart the services; the old certificate keeps being served until they restart, so there is no outage.

• Manual: after the new certificate is deployed, nodes go to Restart pending. Start the restart with Restart now or Schedule restart. If you do not, reminder e-mails are sent 7, 2 and 1 day before the old certificate expires.
• Automatic: nodes restart at the first Restart time after deployment (server local time, default 03:00).

Restarts are sequential: the next node does not start until the services of the previous one are up, and the server running the mailbox extension restarts last. If a node fails, the sequence stops and a notification is sent.

Certificate deployment and restarts on remote nodes use Zimbra's own channel (zmrc, the zimbra user's ssh key). On a multi-server installation install.sh --verify warns if this channel does not work; run zmupdateauthkeys as the zimbra user on all servers.

Status and notifications

In the Let's Encrypt section of the Certificates screen every target (the server certificate or a domain certificate) is a card:

1. Card title: the kind and name of the target.
2. Status pill: Active, Disabled, Waiting for first certificate, Ordering, Waiting for DNS TXT records, Deploy failed, Staging test passed, Restart pending, Deployment failed, Expired or the daily order limit.
3. The names in the certificate, Expires and Next renewal (date plus relative time such as "in 38 days") and the Restart mode.
4. The Nodes list: each server's name, only the roles that use the certificate (mailbox, proxy, mta, ldap), version and a status pill (e.g. Restarted, Not included); errors and warnings open as details under the row.

The card footer carries the actions that fit the current state (Renew now, Retry, Restart now, Schedule restart, TXT added, validate) and Edit. With no target configured the section shows a short explanation and a Let's Encrypt button. Renewal starts when the remaining time drops to a third of the certificate lifetime (about 30 days before expiry for a 90-day certificate). Renew now orders without waiting.

Let's Encrypt cards: status pill, dates and node list

E-mail notifications (subject [Profelis Sertifika] <event> - <target>, Turkish and English body; no secret or PEM): certificate renewed, restart scheduled, restarted, DNS TXT record needed, error (with its stage) and restart reminder (7, 2, 1 day).

After a restart a node counts as Restarted when the services that use the certificate and are enabled on it (mailbox, proxy, mta, ldap) are running; other stopped services, and a proxy that does not serve the new certificate on 443 (SNI serial check), are shown as a warning in the node list and in the e-mail.

The Let's Encrypt chain ends with a cross-signed intermediate root (Root YR/YE), while Zimbra's zmcertmgr verifycrt needs the self-signed root. When the chain is signed by ISRG Root X1/X2 (signature checked) the extension adds the bundled root to the chain automatically (Let's Encrypt and ready-certificate upload); /opt/zimbra/common/etc/ssl/certs does not have to be populated. Staging roots are not added.

Let's Encrypt limits

Let's Encrypt accepts at most 5 certificates per week for the same set of names and at most 5 failed validations per hour per account and name. Therefore:

• At most 3 orders are placed per target and per ACME directory in 24 hours (staging and production are counted separately). Failed attempts wait 1 hour, 6 hours and 24 hours.
• If a certificate is obtained but cannot be deployed on a node, the target stays in Deploy failed and does not order again by itself; re-ordering would use up the weekly limit quickly. Fix the cause and press Retry.
• Make the first attempt with Staging (test certificate) (advanced settings). Staging is an issuance test only: it proves that the ACME account, the order and HTTP-01/DNS validation work from the internet, and its limits are separate. A staging certificate is never deployed (nothing is written to LDAP, no deploycrt, no restart; the current certificate stays in place); the target shows Staging test passed with the issuer of the issued certificate and a notification is sent. To get a real certificate, untick Staging and save; a new order is placed on the production directory right away.

Let's Encrypt for a domain certificate

In the Domain certificate window tick Obtain automatically with Let's Encrypt. The PEM fields are hidden; E-mail, Additional names, the validation method and the restart settings appear. The names in the certificate are the Virtual hostname and the additional names.

The Domain certificate window: Obtain automatically with Let's Encrypt

For Let's Encrypt domain certificates you do not need to run zmdomaincertmgr deploycrts by hand: every proxy server that also runs the mailbox service deploys the new version itself and goes to Restart pending. Proxy-only servers (no mailbox service) show Manual action needed; on those servers run this as root after each renewal (it switches to the zimbra user itself; the screen and the e-mail show the command too):

su - zimbra -c '/opt/zimbra/libexec/zmdomaincertmgr deploycrts && zmproxyctl restart'

If you save a PEM certificate by hand on a domain with Let's Encrypt enabled, you are asked to confirm and Let's Encrypt is disabled for that domain, so the next renewal does not overwrite your certificate.

Uploading a ready certificate

Installs a certificate obtained elsewhere on all nodes in one step.

1. Click Upload certificate in the header.
2. Choose Server certificate or a domain as the Target.
3. Paste Certificate, Chain (intermediate + root) and Private key (not password protected).
4. Press Test: the key match and the chain are checked on the server. Upload is enabled only after the test passes, and is disabled again if a field changes after the test.
5. Press Upload. The certificate is written to LDAP as a new version and installed on all nodes of the target; on an error on one node it is rolled back. Restarts work the same way as for Let's Encrypt.

The Upload ready certificate window

If Let's Encrypt is enabled on the target you are asked to confirm before the upload, and Let's Encrypt is disabled for that target. Automatic renewal stays disabled even if the upload fails.

Proxy CA (client certificate authentication)

The proxy CA is the certificate authority that signs your users' client certificates: a corporate PKI, an e-signature / smart card infrastructure (for example the trust service provider that issues your organisation's cards). The nginx proxy uses it to verify the certificate a browser presents in the TLS handshake (mutual TLS). The value is stored in the zimbraReverseProxyClientCertCA attribute.

What it is not

The proxy CA is not the chain of the server certificate. The intermediate and root certificates of the server certificate are installed with Install / CSR, Upload certificate or Let's Encrypt. A proxy CA is not needed for Let's Encrypt or commercial server certificates. You only need it when browsers must prove their identity with a certificate.

When you need it

• Users should sign in with a smart card / e-signature or a certificate from the corporate PKI instead of (or in addition to) a password.
• The web interface should only be reachable from devices that hold a certificate issued by the organisation (on mode).

Requirements

1. The PEM (-----BEGIN CERTIFICATE-----) of the root CA and any intermediate CAs that issue the client certificates. Do not upload a user certificate, a server certificate or a private key; the dialog rejects them.
2. A rule that maps a user certificate to a Zimbra account (mailbox side, below).
3. A proxy restart on every proxy server after saving.

The Proxy CA dialog

1. Open Proxy CA from the More menu. Only a global administrator can open it.
2. Apply to: Global (all proxy servers), a Proxy server or a Domain. A server or domain value overrides the inherited global value.
3. Current (effective) shows the CA in effect at that scope (CN and expiry date) and the client certificate mode. The value may be inherited from a higher scope.
4. Paste the CA into New CA PEM (at most 64 KB, one or more certificates). Leave it empty to keep the current CA.
5. Choose zimbraReverseProxyClientCertMode: off, optional or on.
6. Tick Remove the CA to delete it. This is only allowed when the mode is off; choosing off is saved together with the removal.
7. Click OK. The file is uploaded with the stock UploadProxyCARequest, the content the server returns is checked again and written to the global configuration, the server or the domain. The mode is only written when it changed.

Proxy CA dialog: scope, current CA and mode, CA PEM box, client certificate mode and warning

Checks on save: only CERTIFICATE blocks, each one a CA certificate (basicConstraints CA:TRUE; an old certificate without extensions is accepted only as a self-signed root), not expired, 64 KB in total at most. With mode on/optional and no CA at that scope the save is refused.

Version 1.2.1 and earlier

Before 1.2.2 the dialog uploaded the file but did not write zimbraReverseProxyClientCertCA: the stock UploadProxyCARequest only returns the file content and stores nothing. Save a CA that was "uploaded" with an older version again with 1.2.2.

Modes

Mode	Behaviour
off (default)	No client certificate is requested. A configured proxy CA is not used.
optional	nginx asks for a certificate and verifies it against the CA if the browser sends one. Users without a certificate still sign in with a password. Recommended during the transition.
on	A certificate is required. Every browser without a valid certificate signed by this CA (administrators included) is rejected during the TLS handshake.

Do not enable a mode without a CA

With zimbraReverseProxyClientCertMode set to on or optional and no CA, zmproxyconfgen exits with Client certificate verification is enabled but no client cert ca is provided and the proxy configuration is not generated; the proxy cannot restart. The dialog refuses to save this state, but the same error occurs if the attribute is changed from the CLI.

What happens on the proxy

zmproxyconfgen (run when the proxy restarts) writes the CA to /opt/zimbra/conf/nginx.client.ca.crt, a domain-level CA to /opt/zimbra/conf/domaincerts/<domain>.client.ca.crt, and adds ssl_client_certificate and ssl_verify_client <mode> to nginx. The verification depth is set by zimbraReverseProxyClientCertDepth (default 10). The domain scope applies to the HTTPS server served under the domain's own zimbraVirtualHostname (SNI).

With mode on/optional nginx also opens a certificate sign-in server on zimbraMailSSLProxyClientCertPort (default 3443) that accepts only /certauth (web) and /certauth/admin (admin console); anything else returns 403.

Mapping a certificate to an account (mailbox side)

The proxy only verifies that the certificate chains to the CA; the mailbox decides which account the certificate belongs to. A /certauth request goes to the mailbox client certificate port; jetty rewrites /certauth/* to /service/certauth (CertAuthServlet). Related attributes:

Attribute	Scope	Meaning
zimbraMailSSLClientCertMode	global, server	Disabled (default), WantClientAuth (certificate requested, otherwise the normal sign-in page), NeedClientAuth (required). Changing it needs a mailboxd restart.
zimbraMailSSLClientCertPort	global, server	Mailbox SSL port that requests a client certificate (default 9443). Only /service/certauth is allowed on this port.
zimbraMailSSLClientCertPrincipalMap	global, domain	Comma-separated rules from a certificate field to an account, tried in order. Default SUBJECT_EMAILADDRESS=name: the e-mail address in the subject must be the account name (or an alias).
zimbraMailSSLClientCertPrincipalMapLdapFilterEnabled	global	Allows LDAP filters in mapping rules (off by default; triggers an LDAP search on every sign-in).
zimbraMailSSLClientCertOCSPEnabled	global, server	OCSP revocation check on the mailbox side (on by default).

Mapping fields: SUBJECT_<RDN> (for example SUBJECT_CN, SUBJECT_SERIALNUMBER), SUBJECT_DN, SUBJECTALTNAME_OTHERNAME_UPN, SUBJECTALTNAME_RFC822NAME. Target keys: name, zimbraId, zimbraForeignPrincipal. For card certificates without an e-mail address, the serial number field can be used, for example:

zmprov mcf zimbraMailSSLClientCertPrincipalMap 'SUBJECT_SERIALNUMBER=zimbraForeignPrincipal,SUBJECT_EMAILADDRESS=name'
zmprov ma ali@example.gov +zimbraForeignPrincipal 'cert SUBJECT_SERIALNUMBER:12345678901'

Because the mailbox verifies the client certificate itself, also add the CA to the client SSL trust store of the mailbox servers (as the zimbra user zmcertmgr addcacert /tmp/ca.pem, then zmmailboxdctl restart). zimbraMailMode must not be http. With OCSP on (the default), certificate sign-in fails and the user is sent to the password page if the OCSP responder in the certificate cannot be reached or the certificate is revoked.

To sign users in with their certificate when they open the normal address, point the domain's login/logout URLs at the certificate sign-in address (stock Zimbra method):

zmprov md example.gov zimbraWebClientLoginURL 'https://mail.example.gov:3443/certauth'
zmprov md example.gov zimbraWebClientLogoutURL '../?sso=1'

After saving

On every proxy server, as root:

su - zimbra -c 'zmproxyctl restart'

Check: /opt/zimbra/conf/nginx.client.ca.crt must contain the CA you uploaded, and grep -r ssl_verify_client /opt/zimbra/conf/nginx/includes/ must show the mode you chose.

Testing

To see that the server requests a client certificate and which CAs it accepts:

openssl s_client -connect mail.example.gov:443 -servername mail.example.gov </dev/null | grep -A3 'Acceptable client certificate CA names'

Connecting with a user certificate (certificate and key as PEM files):

openssl s_client -connect mail.example.gov:443 -servername mail.example.gov -cert user.crt -key user.key </dev/null
curl -v --cert user.crt --key user.key https://mail.example.gov:3443/certauth

In a browser: make the user certificate available to the browser (smart card middleware or .p12 import) and open https://<host>:3443/certauth; the browser asks for a certificate and, if an account matches, the web interface opens. In on mode a browser that connects without choosing a certificate must get an error page.

Troubleshooting

Symptom	Cause and fix
zmproxyctl restart fails, log says no client cert ca is provided	Mode is on/optional but there is no CA at the effective scope. Save the CA or set the mode to off: zmprov mcf zimbraReverseProxyClientCertMode off.
The browser never asks for a certificate	Mode is off or the proxy was not restarted. If the s_client output has no Acceptable client certificate CA names, the proxy configuration is not current.
400 The SSL certificate error / No required SSL certificate was sent	The user certificate does not chain to this CA or an intermediate CA is missing. Upload the intermediate CA that signs the client certificates too; the chain must not exceed zimbraReverseProxyClientCertDepth.
The certificate is accepted but sign-in fails	No account mapping: check the zimbraMailSSLClientCertPrincipalMap rule and the account's zimbraForeignPrincipal; zimbraMailSSLClientCertMode must not be Disabled on the mailbox and the CA must be in the mailbox trust store. An unreachable OCSP responder or a revoked certificate also ends on the password page (zimbraMailSSLClientCertOCSPEnabled). Details in /opt/zimbra/log/mailbox.log.
The dialog says is not a CA certificate	A user or server certificate was uploaded. Upload the CA that signs the client certificates (the card provider's root/intermediate certificate).
Remove the CA is refused	The mode at this scope is not off. Choose off and remove in the same save.

How keys are stored

• The Let's Encrypt state is kept in LDAP on the pf-cert-acme@<default domain> system account; every mailbox server reads the same state.
• The ACME account key and the TSIG secret are hidden in LDAP with Zimbra's DataSource encryption. This is obfuscation, not real encryption: anyone with LDAP read access can decode the values. Restrict LDAP access accordingly. If encryption fails, the save is refused; the secret is never written in plain text.
• The certificate's private key stays in plain text in the zimbraSSLPrivateKey attribute (on the server or domain entry), as in stock Zimbra; the proxy and zmcertmgr read it in plain text.
• Secrets and PEM contents are never logged or returned in any response. All Let's Encrypt operations are open to global administrators only and are written to audit.log.

Troubleshooting

Symptom	Cause and solution
unknown document for GetCertRequest	The Zimbra certificate manager component is not installed.
nginx: unknown directive "${web.strict.servername}" after setting a virtual IP	Fixed in patch package 120 (Zimbra PFE 10); install the current zmpatch package.
unknown document for PfCertProbeSniRequest	The served-certificate check needs the Profelis certificate extension from the same package; install it and restart mailboxd.
unknown document for PfCertVerifyRequest	The Profelis certificate extension is not loaded or mailboxd was not restarted; the zimlet uses the stock path and an external key cannot be uploaded.
Installation stops at deploycrt	The key on disk is not the one you pasted. As the zimbra user run zmcertmgr deploycrt comm and zmcontrol restart; the certificate and key are taken from LDAP.
unknown document for PfCertLeStatusRequest, no Let's Encrypt section	The certificate extension 1.2.0 or later is not installed on the mailbox servers, or mailboxd was not restarted.
Pre-check: Name does not resolve in DNS (ERR_dns_none)	The name has no A/AAAA record. Add it or choose one of the DNS methods.
Pre-check: port 80 of the name does not reach this installation (ERR_probe_mismatch)	The name points to another server, port 80 is closed (proxy in https mode, firewall) or the jetty redirect is missing. Check the certificate lines in the install.sh --verify output; after a Zimbra update run install.sh again and restart mailboxd.
Invalid host name (ERR_bad_name) or wildcard names need a DNS method (ERR_wildcard_needs_dns)	Correct the name; for *.domain choose DNS (manual TXT) or RFC2136.
TSIG secret must be base64 and at least 16 bytes (ERR_tsig_secret)	Paste the secret value from the tsig-keygen output without quotes.
Target in Deploy failed	The certificate was obtained but verifycrt/deploycrt failed on a node; the previous certificate is in place. Fix the error shown in the node list and press Retry. It does not order again by itself (Let's Encrypt weekly limit).
Node shows Manual action needed	A proxy server without the mailbox service: as root, su - zimbra -c '/opt/zimbra/libexec/zmdomaincertmgr deploycrts && zmproxyctl restart'.
Deploy or restart fails on a remote node, install.sh --verify reports zmrc ... calismadi, or a node shows Restart could not be confirmed (ERR_restart_unconfirmed)	The zimbra user's ssh keys are missing. zmrc must work in both directions between all nodes: run zmupdateauthkeys as the zimbra user on every server. A mailbox node also confirms its own restart without zmrc; if it is not confirmed within 30 minutes this error is shown.
After the restart a node is Restarted but warns other services are stopped (ERR_services_stopped, e.g. stats, zmconfigd Stopped) or Proxy still serves another certificate (ERR_sni_mismatch)	The services that use the certificate (mailbox, proxy, mta, ldap) are running, so the restart counts as successful. Typical cause: the system resolver is Zimbra's own dnscache (127.0.0.1 in /etc/resolv.conf); DNS is briefly down during the restart, zmconfigd dies at boot with UnknownHostException and the proxy configuration is generated incomplete. Remedy, as root on that server: su - zimbra -c 'zmconfigdctl start; zmproxyctl restart'; for a permanent fix list all cluster servers in /etc/hosts: on every server as root bash scripts/install-cluster-hosts.sh (the installer runs it itself; details: Installation).