New self-hosted tool tlswatch audits TLS certificates and legacy protocol support

A new self-hosted utility called tlswatch has emerged to help infrastructure teams monitor the health and security of their Transport Layer Security (TLS) configurations. Released by developer Sjoerd305, this tool goes beyond simple expiration alerts by auditing certificate chains, signature strengths, and the presence of deprecated protocols like TLS 1.0. It operates as a single Go binary with a SQLite backend, designed for easy deployment in environments where teams manage their own software stacks.

What happened

tlswatch actively probes hostnames and IP addresses to inspect the TLS certificates currently being served. Unlike standard uptime monitors that might only check if a HTTPS port is open, this tool examines every address behind a domain name. This capability is critical for detecting stale nodes hidden behind load balancers that might still be serving expired or misconfigured certificates. The system supports checks on any port, handling both implicit TLS and STARTTLS protocols used by services such as SMTP, IMAP, POP3, FTP, and PostgreSQL.

The tool also performs deep configuration audits. It runs daily tests to identify servers that still accept insecure connections via SSL 3.0, TLS 1.0, or TLS 1.1. It evaluates cipher suites for weaknesses, including export-grade, NULL, anonymous, DES, RC4, and 3DES options. Based on these findings, tlswatch assigns a configuration grade from A to F for each target, providing clear reasons for any deductions. It also detects edge cases such as RSA certificates served alongside ECDSA ones, or default certificates served without Server Name Indication (SNI), which can break specific clients.

Key details

• Single binary deployment: The application runs as one Go binary with a web UI and a SQLite database, requiring no additional services.
• Comprehensive protocol support: Checks any port for implicit TLS or STARTTLS, covering email, database, and file transfer services.
• Legacy detection: Identifies servers accepting TLS 1.0, 1.1, or SSL 3.0 and grades configuration security from A to F.
• Distributed probing: Uses "nodes" to probe internal networks that the main server cannot reach, updating themselves automatically.
• Certificate Transparency matching: Compares publicly issued certificates against those actually served to detect unused or rogue certificates.
• Flexible alerting: Sends notifications via email, Telegram, Slack, Discord, ntfy, or webhooks, with support for bulk acknowledgements.

Background

Transport Layer Security (TLS) is the standard protocol for encrypting data transmitted over the internet. While most administrators monitor certificate expiration dates to prevent service outages, the security of a TLS implementation depends on more than just validity periods. Servers must also enforce strong cryptographic standards and reject outdated protocols that are vulnerable to attack. Legacy protocols like TLS 1.0 and 1.1 have known weaknesses and are deprecated by major industry bodies, yet they often remain enabled on servers by default or due to legacy application requirements.

Certificate Transparency (CT) is a public ledger system that logs all issued TLS certificates. Monitoring CT logs helps organizations detect unauthorized certificate issuance. However, a certificate appearing in the log does not guarantee it is correctly deployed on the intended servers. Tools that only monitor CT logs may miss configuration errors, while tools that only check live servers may miss unauthorized issuances. tlswatch bridges this gap by cross-referencing public issuance data with live server probes.

Why it matters

For teams running self-hosted software, maintaining a secure TLS posture is complex. Infrastructure often includes a mix of public-facing web servers and internal services like databases or mail servers that use STARTTLS. Standard uptime monitors typically treat TLS as a black box, only verifying that a connection can be established. They rarely inspect the certificate chain, check for weak ciphers, or validate that all IP addresses behind a load balancer are using the correct certificate. This blind spot can lead to security vulnerabilities or intermittent failures that are difficult to diagnose.

tlswatch addresses these gaps by providing a unified view of certificate health and configuration security. By assigning a grade to each target, it gives operators a quick way to prioritize remediation efforts. The ability to probe internal networks via distributed nodes means that even services isolated from the public internet can be monitored for compliance with security policies. This is particularly valuable for organizations that need to enforce strict cryptographic standards across their entire infrastructure, not just their public websites.

What you can do

• Deploy a test instance: Use the provided Docker Compose file to run tlswatch locally and explore its interface without committing to a production setup.
• Audit internal services: Configure nodes to probe internal ports such as 587 for SMTP or 5432 for PostgreSQL to ensure STARTTLS is correctly implemented.
• Review configuration grades: Check the A-F grading for your public endpoints to identify and disable legacy protocols like TLS 1.0 or weak cipher suites.
• Monitor Certificate Transparency: Enable CT watching to receive alerts if certificates are issued for your domains but not served by your known infrastructure.
• Export inventory data: Use the CSV export feature to maintain an external record of all certificates, their expiration dates, and where they are served.
• Integrate with existing alerts: Connect tlswatch to your current notification channels, such as Slack or Telegram, to ensure certificate warnings reach the right team members.