UNABLE_TO_VERIFY_LEAF_SIGNATURE on SMTP? Complete Fix Guide

Short answer: UNABLE_TO_VERIFY_LEAF_SIGNATURE means the machine connecting to a mail server could not build a trusted chain from that server's certificate up to a root certificate authority it trusts. In the large majority of cases the mail server itself is serving an incomplete certificate chain, and the fix belongs on the server, not on your connecting machine. The one fix that is never acceptable is turning certificate verification off.

• If you administer the mail server being connected to: your certificate chain is almost certainly missing its intermediate certificate - install the full chain, not just the leaf certificate.
• If you are connecting to a server you do not control (a script, an application, or a monitoring tool talking to someone else's SMTP server): the server operator has a broken chain, and nothing on your side fixes that properly - tell them, and do not work around it by disabling verification.
• If this only happens on one specific network (an office, a hotel, a VPN): you are very likely behind something that intercepts TLS traffic - see the corporate interception cause below.
• If this started suddenly on something that worked yesterday: check whether a certificate was just renewed - the new one may be missing its intermediate - or whether it simply expired.

What This Error Actually Means

UNABLE_TO_VERIFY_LEAF_SIGNATURE is a TLS certificate verification failure, surfaced by the cryptography library underneath whatever tool you are using to connect - most commonly a variant of OpenSSL - during the handshake that has to succeed before an SMTP session can proceed securely. That handshake happens whether the connection uses implicit TLS from the first byte (typically port 465) or starts in plain text and upgrades mid-connection with STARTTLS (typically port 587, and sometimes 25).

"Leaf" refers to the end-entity certificate: the specific certificate issued for the exact hostname you are connecting to, as distinct from the intermediate and root certificates that sit above it. "Verify the leaf signature" means confirming that the certificate authority named as having signed that leaf certificate really did sign it, and that this authority is one your system already trusts - either directly, or transitively through a chain that eventually reaches a trusted root. When that confirmation cannot be completed, this is the error you get.

Depending on the exact library involved, you will sometimes see the same underlying condition worded differently - "unable to verify the first certificate" is the same failure described in different words by a different tool. Both point at the same diagnosis and the same fix.

Where This Error Shows Up

The same underlying failure surfaces across a wide range of tools, and where you saw it changes what "connecting machine" actually means in the short-answer section above.

This matters because a certificate chain can verify successfully in one of these contexts and fail in another, on the exact same server, at the exact same moment - a browser and an operating system's own trust store tend to be kept current automatically, while an application or a script sometimes bundles its own separate, older, or more narrowly scoped list of trusted authorities. Seeing this error in one tool while a browser visiting the same server shows no warning at all is not a contradiction - it usually just means the two are checking against different trust stores. The fix is still the same server-side chain repair described below, since a properly complete chain is what makes verification succeed everywhere consistently.

How Certificate Chain Verification Works

A public certificate authority almost never signs your mail server's certificate directly with its most sensitive, closely guarded root key. Instead it signs with an intermediate certificate, which was itself signed by the root. Your server is supposed to present both its own leaf certificate and the intermediate certificate or certificates needed to connect that leaf back up to a root your system already trusts.

Operating systems and language runtimes ship with a bundle of trusted root certificates, but they do not ship with every intermediate certificate in existence - there are far too many, and they rotate more often than roots do. If a server sends only its leaf certificate and leaves out the intermediate, your system is holding a certificate it recognizes the shape of but cannot walk back to anything it trusts. Correctly, it refuses to treat the connection as verified rather than guessing.

The Common Causes, and How to Tell Them Apart

Five situations produce this same error. They look identical from the error text alone, so the sections below cover how to tell them apart.

Missing Intermediate Certificate on the Server

By a wide margin the most common cause. The server was configured with only its own certificate and never had the certificate authority's intermediate bundle installed alongside it - often because whoever set it up copied just the "certificate" file and skipped the separate "chain" or "intermediate" file the certificate authority also provided. The tell: a chain inspection (covered below) shows only one certificate, or the chain jumps straight from your server's certificate to something your system does not recognize as a root.

Self-Signed or Internally Issued Certificate

Some mail servers - a personal server, an internal system, a test environment - use a certificate that was never issued by a public certificate authority at all, either genuinely self-signed or signed by a private certificate authority that only that organization's own machines are configured to trust. From the outside this produces the identical error to a missing intermediate, but the real fix is different: there is no missing piece to add back, because the certificate was never meant to be publicly verifiable in the first place unless you deliberately choose to trust that specific private authority.

Expired Certificate

A certificate past its listed expiry date usually surfaces through a distinctly worded error rather than this exact one, but expired certificates and broken chains are frequently fixed in the same maintenance window - it is common to resolve one and immediately run into the other. Check the expiry date as part of the same pass rather than treating it as unrelated.

Wrong Clock on Your Own Machine

Certificate validity is time-bound - every certificate has a "not valid before" and "not valid after" date - and verification is computed against your own system's clock, not the server's. A machine with a badly wrong clock (a freshly created virtual machine, a device with a dead internal clock battery, a container image built without time sync configured) can conclude a perfectly good certificate is not yet valid or has already expired, and depending on the library involved, this can surface through the same general chain-verification failure path. It costs nothing to rule out: compare your system time against any reliable clock.

Corporate TLS Interception or Security Software

Some office networks, antivirus suites, and firewall appliances deliberately intercept encrypted connections to inspect their contents. They terminate the real TLS connection, examine it, and re-encrypt it to you using their own certificate, signed by an internal certificate authority that only that organization's managed devices are configured to trust. A script or a personal device that is not enrolled in that trust configuration sees what looks exactly like a broken chain, because from its perspective it received a certificate signed by an authority it has genuinely never heard of. The tell: inspecting the certificate chain shows an issuer name referencing your own company, a security vendor, or a network appliance rather than a public certificate authority you would recognize.

Diagnosing the Chain Yourself

One command shows you exactly what the server is presenting, which tells you which of the five causes above you are dealing with before you change anything.

openssl s_client -starttls smtp -connect mail.example.com:587 -showcerts

Replace mail.example.com:587 with the actual hostname and port you are connecting to. For port 465, drop -starttls smtp entirely and connect directly, since 465 negotiates TLS immediately rather than upgrading a plain-text connection partway through:

openssl s_client -connect mail.example.com:465 -showcerts

In the output, look for three things. The certificate chain section lists every certificate the server sent - one entry usually means the intermediate is missing. The issuer field on the top certificate tells you whether it names a public certificate authority you would recognize, a self-referential issuer matching its own subject (a self-signed certificate), or something naming your own organization or a security product (interception). The Verify return code line near the end of the output is the direct answer: 0 (ok) means verification succeeded, and anything else - commonly referencing the leaf signature or an inability to get a local issuer certificate - confirms the diagnosis and names roughly where the chain breaks.

The Correct Fix for Each Cause

Fix: Install the Full Certificate Chain

The certificate authority provides a chain or intermediate bundle file alongside the leaf certificate at issuance time. Concatenate it with the leaf certificate, in the order your mail server software expects (typically leaf first, then the intermediate or intermediates), and configure that combined file as what the server presents - not the leaf alone. If the intermediate file has been lost, the issuing certificate authority publishes it for direct download, and it can often be recovered from any other correctly configured server using a certificate from the same authority. After updating it, reload or restart the mail service and re-run the diagnostic above to confirm the chain now shows more than one certificate.

Fix: Replace a Self-Signed Certificate, or Deliberately Trust It

Two legitimate paths exist. For anything that needs to accept mail from the general internet, obtain a certificate from a public, generally trusted certificate authority instead - automated, no-cost issuance is widely available, so this is rarely a real obstacle today. For a genuinely internal mail system that only your own machines ever need to talk to, deliberately add that specific private certificate authority's root to the trust configuration of the machines that need to connect - a scoped, intentional decision naming exactly one certificate authority you have an actual reason to trust, which is a completely different action from disabling verification for every connection you will ever make.

Fix: Renew the Certificate

Issue a new certificate before or immediately after expiry, ideally through an automated renewal process so this stops recurring. Confirm the freshly renewed certificate still includes its full intermediate chain - a renewal is a common moment for the chain to go missing again if the process is not fully automated end to end.

Fix: Correct Your System Clock

Sync the affected machine's clock to a reliable time source. If this keeps happening on the same device - a container, a machine with a failing clock battery - fix the underlying time-sync configuration rather than correcting the clock manually each time it drifts.

Fix: Get the Interception Handled Properly, Not Bypassed

If you administer the network causing this, either add your organization's interception certificate to the trust configuration of whatever is failing to connect, or configure a scoped exception so mail traffic from that specific tool bypasses inspection - whichever your security policy calls for. If you do not administer the network - a guest, or a personal device on a corporate network - this generally is not yours to fix directly. Connect from a network that is not intercepting the connection, or ask whoever manages it to add the exception or provide the interception certificate for you to trust deliberately.

Why Disabling Verification Is Never the Fix

It is tempting to reach for whatever setting makes the error stop - an environment variable that tells a runtime to accept unauthorized certificates, a client library option commonly named something like "reject unauthorized" set to false, a command-line flag that skips verification entirely. Do not use any of them in anything that sends or receives real mail, for four concrete reasons.

• It does not fix anything. The broken chain, the expired certificate, or the interception is still exactly as broken as it was. You have only told your own software to stop checking, which is a fundamentally different outcome from the underlying problem being solved.
• It removes protection for every future connection made under that setting, not just this one. Anyone positioned on the network path between you and the mail server - a compromised network device, a hostile network, anything upstream - can now present any certificate at all, including a fraudulent one, and your software will accept it without complaint. That is not a hypothetical edge case; it is the exact technique an on-path attacker uses to read or alter traffic that is supposed to be encrypted, including the authentication credentials your SMTP session sends and the content of every message that follows.
• It is silent and it persists. Once that setting is in place, nothing warns you on an ongoing basis that mail - and credentials - are moving with no certificate protection at all. Everything appears to work right up until it is actually a problem, at which point there is no way to know it happened.
• No credible authority treats this as a real fix. Every maintainer of every serious TLS library documents this kind of setting as a last-resort, isolated-test-environment-only escape hatch - never something to ship in anything handling real traffic. That is the consistent, industry-wide position, not a one-off opinion.

Work through the causes and fixes above instead. If you do not control the server and its operator will not fix a broken chain, do not route real mail through that connection until they do - sending with verification disabled is not a safer alternative, it is the same risk with the warning turned off.

What this looks like in practice is usually smaller and more mundane than the word "attack" suggests: a shared office network, a public hotel connection, a misconfigured proxy somewhere between your application and the mail server - any of these can sit on the path without anyone noticing, and disabled verification means your application would trust whatever certificate any of them decided to hand it. The failure mode is not a dramatic breach announcement; it is credentials and message content moving in the clear on a connection everyone involved believed was encrypted, for as long as that setting stays in place, which in practice tends to be far longer than whoever added it originally intended.

Confirming the Fix Worked

Re-run the diagnostic command from earlier and confirm two things: the certificate chain now lists more than one certificate where it previously listed one, and the Verify return code line reads 0 (ok). Once both are true, send an actual test message end to end rather than stopping at a clean handshake - a clean chain confirms the certificate problem is solved, but a real message confirms the whole connection works as expected.

If the error originally showed up in a specific application rather than at the command line, confirm the fix there too, not only with the openssl diagnostic. As covered above, different tools can use different trust stores, so a chain that now verifies cleanly with openssl is strong evidence the server is fixed, but the specific client, script, or integration that originally failed is the one that needs to actually succeed before you consider this closed.

Related Errors You Might See Instead

Several related error strings describe the same family of problem with a different specific detail. If what you are looking at does not exactly match UNABLE_TO_VERIFY_LEAF_SIGNATURE, one of these probably does.

Preventing This on Servers You Control

• Automate certificate renewal end to end rather than renewing by hand - manual renewal is when an intermediate chain most often goes missing again.
• Run the chain diagnostic after every renewal as a standing check, rather than assuming a successful renewal also means a complete chain.
• Monitor certificate expiry proactively with an automated check or a calendar reminder well ahead of the deadline, not after something has already started failing.
• Keep the certificate authority's chain file documented or version-controlled alongside the certificate itself, so it is not lost or forgotten between renewals.
• Test from more than one vantage point after any certificate change, not just from the server itself - a chain can look complete locally while still failing for anyone connecting from outside, especially if the wrong file was reloaded or an old certificate is still cached somewhere in front of the server.
• Document who is responsible for renewal for every mail server your organization runs, including any test or internal system that quietly started accepting real mail after being set up "temporarily." Forgotten systems are where expired and incomplete chains accumulate unnoticed.

What This Means for a Connected Mailbox

If you ran into this error while trying to connect a mailbox somewhere, the cause and the fix are exactly what this page describes - the problem lives in the mail server's own certificate configuration, not in whatever tool was trying to connect to it. A trustworthy connection has to verify that certificate properly every single time; quietly skipping that check on your behalf is never something a properly built mail integration should do, for all the reasons covered above. If a mailbox will not connect because of this error, the fix is getting that mail server's own certificate chain corrected - once it presents a complete, verifiable chain, reconnecting works normally with no further changes needed on your end. Setup guidance for connecting mailboxes lives in the documentation.