Mail, LDAP & Database TLS

CertTracker monitors certificates on services that don't serve TLS on a dedicated port. Mail servers, directory servers, and databases all greet you in plaintext and then upgrade the connection to TLS on request — and their certificates expire just like the ones on a web server, only the failures are quieter. An expired SMTP cert silently breaks every outbound message; an expired LDAP cert locks out every domain-joined workstation.

This page explains the supported protocols, what to configure, and what to expect.

Supported protocols

When you add a monitor, the Protocol dropdown picks how CertTracker acquires the certificate. Choose the protocol that matches the service running on the port — the form auto-fills the canonical default port for whatever you pick.

If your server runs SMTP on a non-standard port (say 2525), pick SMTP STARTTLS in the dropdown and override the Port field. The protocol choice drives the upgrade dance; the port is just where we connect.

What CertTracker captures

Once the upgrade succeeds, every monitor type produces the same leaf-certificate metadata as a regular HTTPS monitor:

• Subject, Issuer, Serial Number, Signature Algorithm
• Public Key (algorithm + bit length)
• Subject Alternative Names
• Valid From / Expiration
• SHA-1 and SHA-256 fingerprints
• Negotiated TLS version + cipher suite
• Hostname match against the cert's CN/SAN

…and every downstream feature works identically:

• Change detection — every poll diffs the captured cert against the last one and writes any differences into Change History
• Expiration alerts — at the per-monitor threshold (default 30 days), same email pipeline as HTTPS
• TLS Audit (Business / Enterprise) — the deep audit runs the same STARTTLS dance before each protocol-version probe and each cipher-enumeration handshake, so you get real Protocol Acceptance / Cipher Suites / OCSP / chain-signature data for your mail server too
• TLS hardening advisories — weak signatures, deprecated protocols, weak ciphers all fire the same way

The one exception: HSTS only applies to HTTPS, so it's reported as — (not applicable) for non-HTTPS monitors instead of as a red advisory.

Common patterns

One mail server, three monitors. A typical Postfix + Dovecot box presents the same TLS certificate (with mx, imap, smtp SANs) on ports 25/587, 143, and 110. Each port is its own monitor with its own change history and alert configuration, but the cert data is identical — that's correct behavior, not a duplicate. You'd see different certs only if the ports were served by different processes (or different hosts behind a load balancer).

Active Directory domain controllers. AD DS exposes LDAPS on 636 and LDAP+StartTLS on 389. If you're already polling 636 as Direct TLS, you don't need a separate 389 monitor — but adding one verifies that StartTLS is actually working on the plain port, which is what Windows clients use by default for non-LDAPS lookups.

PostgreSQL behind PgBouncer. PgBouncer presents its own TLS cert if server_tls_sslmode = require is set on the upstream side. Point CertTracker at PgBouncer's listening port (typically 6432, not 5432) and pick PostgreSQL as the protocol.

Caveats

• The server must actually offer STARTTLS. Some hardened mail servers reject STARTTLS from unknown sources (greylisting) or require SMTP AUTH before the upgrade. If the poll fails with "STARTTLS refused", check the server's logs for our poller's IP — it may need to be on the allow-list.
• MonitorType is per-monitor, not per-host. Mixing protocols on one host is fine; just create one monitor per (host, port, protocol) combination.
• Database TLS isn't always enabled. MySQL 8 and recent MariaDB auto-generate a self-signed cert on first start and have TLS on by default, but PostgreSQL ships with ssl = off in most distros and older MariaDB/Docker images (e.g. some Mailcow versions) often have TLS disabled too. If a monitor for those returns "STARTTLS refused", "no TLS version accepted", or WRONG_VERSION_NUMBER, the server probably isn't configured for TLS at all — verify with openssl s_client -starttls postgres -connect host:5432 (or -starttls mysql -connect host:3306) from the same network. If openssl prints MySQL server does not support SSL. or the equivalent, that's a server-side config gap, not a CertTracker bug.
• MySQL/MariaDB rejects unknown client hosts before the handshake. Unique to MySQL: if no user account on the server has a host pattern matching the connecting client's IP, MySQL replies with error 1130 (Host '...' is not allowed to connect to this MySQL server) immediately, before sending the protocol handshake. The TCP connection looks fine but the TLS upgrade never gets a chance, and CertTracker surfaces a handshake error. If you see this against a server you know has TLS configured, create a no-privilege user on the server matching the poller's source IP:

sql CREATE USER 'certtracker'@'<poller-ip>' IDENTIFIED BY 'unused-never-authenticates'; -- Or for any host on an internal network: CREATE USER 'certtracker'@'10.0.0.%' IDENTIFIED BY 'unused-never-authenticates';

Deliberately grant nothing — the user only has to exist with a matching host pattern so MySQL sends the handshake. CertTracker never authenticates; it captures the cert during the TLS upgrade and disconnects. (Public-poller IPs are listed at the bottom of the API Tokens admin card.)
- MSSQL TLS handshake is wrapped in TDS PRELOGIN packets. Unique to MSSQL: every byte of the TLS handshake itself flows inside TDS PRELOGIN-typed packets on the wire (only the post-handshake application traffic is raw TLS). CertTracker handles this transparently — but it means deep TLS Audit (per-version + per-cipher probes) isn't available for MSSQL yet. Expiry tracking, change detection, leaf cert metadata, hostname-match advisories all work the same as every other protocol. If the audit panel shows "Audit not yet available for MSSQL," that's why; this is tracked as a future enhancement and isn't a bug.
- MSSQL needs encryption configured server-side. On a fresh SQL Server install, encryption is off by default — the server reports ENCRYPT_NOT_SUP during PRELOGIN and CertTracker correctly flags no_cert. Turn on encryption via SQL Server Configuration Manager → SQL Server Network Configuration → Protocols for MSSQLSERVER → right-click → Properties → Flags → Force Encryption = Yes. Or on Azure SQL Database, it's enabled by default.
- Pre-shared keys aren't required. CertTracker only goes as far as the server's certificate message during the handshake; it doesn't authenticate or read any data, so no credentials or shared secrets are needed for any of these protocols.

Adding a monitor

1. Monitors → + Add Monitor
2. Pick the Protocol — Port auto-fills
3. Hostname / Domain — mx + example.com, dc01 + corp.local, etc.
4. Path is ignored for non-HTTPS monitors but can be left as /
5. Add Monitor — the first poll fires within seconds; the deep TLS Audit follows on the next 24h cycle

The new monitor type shows a small colored pill (amber for mail, teal for LDAP, purple for database) next to the FQDN on the monitor list and in the detail modal so you can see at a glance how each cert is being acquired.