Beyond HTTPS: monitoring SSL for SMTPS, IMAPS, FTPS, and LDAPS
Most SSL monitoring tools only check port 443. But the same expirations and chain breaks hit mail servers, FTP gateways, and LDAP directories — and when those certs fail, the symptoms look nothing like a browser warning. Here's how TLS works for each protocol, the STARTTLS trap that catches teams out, and why monitoring needs to speak each protocol natively.
When an HTTPS certificate expires, you find out fast. A visitor hits the site, sees a full-page red warning, and you get a Slack message within minutes. The browser is the smoke detector — loud, annoying, hard to miss.
Now imagine your SMTP relay's certificate expires. There's no browser. No popup. No 503. What happens instead is that your transactional email provider's SMTP client opens a TCP connection, starts a TLS handshake, fails certificate verification, and — depending on the client — either falls back to plaintext (silently transmitting credentials in the clear), retries with backoff, or drops the message entirely. The first sign of trouble is usually a customer asking why they never got their password reset.
The same pattern repeats across every non-HTTPS TLS service in your stack. Mail submission, mail retrieval, file transfer, directory lookups for SSO — all of them rely on TLS, none of them have a browser in front of them, and most SSL monitoring tools only check port 443.
Why HTTPS gets all the attention
Two reasons. First, browsers do an enormous amount of certificate
validation work on every page load and surface failures with the full
weight of a security warning. That makes HTTPS the only TLS protocol
where end users actively notice problems. Second, the dominant SSL
monitoring tooling grew up to serve marketing and SRE teams whose first
question is "is the website up?" — so checking https://example.com
became the default and the rest of the protocol surface area got
ignored.
But the protocol surface area is large and growing. A typical SaaS backend in 2026 might rely on:
- SMTPS for outbound transactional mail (Mailgun, SendGrid, AWS SES all sit behind TLS).
- IMAPS / POP3S for any product that reads inbound mail (helpdesk ingestion, mail-to-ticket, email parsing pipelines).
- FTPS for partner file exchange — yes, still, especially in fintech, healthcare, logistics, and EDI.
- LDAPS for any directory-backed SSO, including Active Directory, FreeIPA, and most enterprise auth backends.
Every one of these has the same cert lifecycle problems as HTTPS: expiry, chain breaks, mismatched hostnames, weak ciphers, accidental TLS downgrade after a config change. The difference is that nobody is watching them.
The STARTTLS trap
Here's where a lot of teams get tripped up. Each of these protocols has two ways to do TLS:
| Mode | How it works |
|---|---|
| Implicit TLS | The connection is TLS from byte zero. The client opens the socket and starts the TLS handshake immediately. Uses a dedicated port. |
| STARTTLS / AUTH TLS | The connection starts as plaintext. The client sends a protocol-specific command (STARTTLS, AUTH TLS) to upgrade the session to TLS in-place. Uses the same port as the plaintext protocol. |
In practice, the modern port assignments look like this:
| Protocol | Implicit TLS port | STARTTLS port |
|---|---|---|
| SMTPS | 465 | 587 (mail submission), 25 (relay) |
| IMAPS | 993 | 143 |
| POP3S | 995 | 110 |
| FTPS | 990 | 21 |
| LDAPS | 636 | (rarely used) |
Why does this matter for monitoring? Because a tool that just opens a
TCP socket and tries to start a TLS handshake will work fine on the
implicit-TLS ports and fail on the STARTTLS ports — not because TLS is
broken, but because the server is still expecting plaintext protocol
commands. A monitor that doesn't know to send STARTTLS to port 587 or
AUTH TLS to port 21 will report a false negative ("connection error")
when in fact the certificate is healthy.
The reverse failure is worse. If a monitor blindly sends STARTTLS to
an implicit-TLS port like 465, the server interprets the plaintext
command as garbage, drops the connection, and the monitor reports
"protocol error" when the cert is fine.
Protocol-aware monitoring isn't a nice-to-have here. It's the difference between a working alert and three false positives a day until somebody turns the alert off.
What goes wrong, per protocol
SMTPS. The dominant failure mode is hostname mismatch on the MX record's TLS certificate. Mail clients vary wildly in strictness — some fall back to plaintext on cert failure (a quiet downgrade attack vector), others fail closed. If you operate an outbound relay, you also have to worry about MTA-STS, DANE, and TLS-RPT, all of which assume your certificate chain is actually valid and reachable.
IMAPS / POP3S. Most users don't see the error message; their mail client just keeps re-prompting for the password every couple of minutes. Support tickets pile up before anyone connects it to a cert problem. iOS Mail and Outlook are particularly opaque about which TLS error they hit.
FTPS. FTP's two-channel design (control + data) means the certificate has to be valid for both connections. Misconfigured load balancers and NAT in front of FTPS servers are a chronic source of "the cert is fine but data transfers hang" tickets.
LDAPS. This is the dangerous one. When LDAPS breaks, the symptom isn't "SSL error" — it's "users can't log in." Every authentication attempt that hits the broken cert path fails. If you're running LDAPS-backed SSO, an expired LDAPS cert is a full authentication outage, often with a several-minute delay before anyone realizes it isn't a code deploy.
What protocol-aware monitoring looks like
A monitor that actually catches these problems has to do more than open a TCP socket. It has to:
- Choose the right TLS mode per port. Implicit TLS for 465 / 993 / 995 / 990 / 636; STARTTLS / AUTH TLS for 587 / 143 / 110 / 21.
- Speak the protocol up to the TLS hello. That means reading the
server greeting, parsing multi-line responses (especially SMTP
EHLOandSTARTTLS), and validating the upgrade response before sending the TLS ClientHello. - Validate the certificate without depending on the OS trust store. The cert that a corporate machine trusts may not be the cert that a customer's mobile mail client trusts. You want to see what an unprivileged client sees.
- Capture the same signals you'd want for HTTPS. Expiry, chain completeness, hostname match, negotiated TLS version, cipher suite. "It's not expired" isn't the same as "it's healthy."
- Run from outside your own network. An LDAPS certificate that validates from the same VPC as the directory server might be using a private CA that no client can reach. The only useful test is from where the client actually lives.
Closing
The thing that makes mail, FTP, and LDAP TLS dangerous is exactly that they're silent. There's no browser warning, no inbox notification, no red bar at the top of a page. The first signal is usually a customer ticket, and by then the outage clock has been running for hours.
If you're already monitoring HTTPS, extending coverage to the rest of your TLS surface is the single highest-leverage change you can make to your reliability posture in 2026. StableSSL's agents speak all six protocols natively — HTTPS, FTPS, SMTPS, IMAPS, POP3S, LDAPS — including both implicit-TLS and STARTTLS modes, so you can monitor a mail relay or an LDAPS directory the same way you monitor a website. Add your domain and the next renewal won't be the one you find out about from a support ticket.