Beyond HTTPS: Comprehensive SSL Monitoring for SMTPS, IMAPS, and Other Non-Web Services

When you think about SSL/TLS certificate monitoring, your mind probably jumps straight to HTTPS. Websites, web applications, APIs – these are the poster children for TLS, and their certificate expiry outages are often the most visible. But what about all the other critical services that rely on TLS encryption? Your email servers, database connections, VPNs, and various custom applications also use certificates, and their expiry can be just as, if not more, disruptive.

In this article, we’ll dive into the often-overlooked world of SSL monitoring for non-HTTPS services like SMTPS and IMAPS. We'll explore why these services demand your attention, how they differ from HTTPS from a monitoring perspective, and practical strategies to ensure their certificates never expire unnoticed.

Why Non-HTTPS Services Need Just as Much Attention

Think about your organization's daily operations. While your website might be a public face, services like email, database connections, and internal APIs are often the backbone.

Consider these scenarios:

  • Email (SMTPS, IMAPS, POP3S): If the certificate on your email server expires, clients (Outlook, Thunderbird, mobile apps) will suddenly be unable to connect securely. Users will see certificate warnings, or worse, email delivery and retrieval will grind to a halt. This impacts internal communication, customer support, and transactional emails.
  • Databases (PostgreSQL, MySQL, MongoDB): Many modern applications connect to databases over TLS for enhanced security. An expired certificate on your database server means your applications can no longer establish secure connections, leading to complete application downtime.
  • LDAPS (LDAP over SSL): Active Directory or other LDAP directories often use TLS for secure authentication and directory lookups. If this certificate expires, user authentication for various systems could fail, locking users out.
  • VPNs (OpenVPN, WireGuard, IPsec): Many VPN solutions rely on certificates for server and client authentication. An expired server certificate can prevent users from connecting to your internal network securely.

The common thread here is that while the application layer protocol differs, the underlying TLS layer is identical to HTTPS. The consequences of expiry are equally severe, often leading to internal outages that can be harder to diagnose quickly because they don't manifest as a public-facing "website down" alert.

The Core Challenge: Different Protocols, Same TLS Layer

The fundamental mechanism for establishing a secure connection using TLS is largely the same across all services. A client connects to a server, they perform a TLS handshake, the server presents its certificate, and if everything validates, an encrypted channel is established.

The key difference for monitoring purposes lies in how the TLS handshake is initiated:

  • Implicit TLS (or "SSL/TLS on connection"): With implicit TLS, the client immediately initiates a TLS handshake upon connecting to a dedicated port. There's no prior plain-text communication. Examples include IMAPS on port 993, SMTPS on port 465, and POP3S on port 995.
  • Explicit TLS (or "STARTTLS"): With explicit TLS, the client first connects to a standard, plain-text port. After an initial unencrypted exchange, the client sends a specific command (e.g., STARTTLS for SMTP, STLS for IMAP, AUTH TLS for FTP) to upgrade the connection to TLS. Examples include SMTP submission on port 587 (or legacy port 25), IMAP on port 143, and POP3 on port 110.

This distinction is crucial because your monitoring tool or script needs to know which method to use to correctly initiate the TLS handshake and retrieve the certificate.

How to Manually Check Certificates on Non-HTTPS Services

The openssl s_client command-line tool is your best friend for manual inspection of TLS certificates on virtually any service. It allows you to simulate a client connection and examine the certificate presented by the server.

Let's look at some concrete examples:

1. Implicit TLS (e.g., IMAPS on port 993)

For services that immediately start with TLS, the command is straightforward:

openssl s_client -connect imap.example.com:993 -showcerts -servername imap.example.com

Explanation:

  • -connect imap.example.com:993: Specifies the host and port to connect to.
  • -showcerts: Displays the entire certificate chain received from the server.
  • -servername imap.example.com: This is critical for Server Name Indication (SNI). Just like with HTTPS, many servers host multiple services or domains and use SNI to determine which certificate to present. Always include this unless you're absolutely sure SNI isn't in use or relevant.

After running this command, you'll see a lot of output. Look for sections like:

---
Certificate chain
 0 s:/CN=imap.example.com
   i:/C=US/O=Let's Encrypt/CN=R3
-----BEGIN CERTIFICATE-----
... (Actual certificate data) ...
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=imap.example.com
issuer=/C=US/O=Let's Encrypt/CN=R3
...
notBefore=Jan 1 00:00:00 2024 GMT
notAfter=Apr 1 23:59:59 2024 GMT
...
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    ...
    Verify return code: 0 (ok)

The notBefore and notAfter dates tell you the validity period. Verify return code: 0 (ok) indicates that OpenSSL successfully built a certificate chain to a trusted root and the certificate is valid at the time of connection. Any other return code (e.g., 20 for unable to get local issuer certificate, 21 for unable to verify the first certificate) indicates a problem.

2. Explicit TLS (e.g., SMTPS Submission on port 587)

For services that use STARTTLS, you need to tell openssl s_client to issue the STARTTLS command:

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

Explanation:

*