Most certificate monitoring watches the websites your customers visit. That's the right place to start, but it's usually the smaller half of the problem. Behind the firewall, a typical company runs far more certificates than it has public websites, and nobody is watching them.
When one of those expires, there's no browser warning for a customer to report. Instead, a nightly job stops connecting to the database, the VPN refuses logins, or a service quietly falls back to an error page that only staff see. The fix takes minutes; finding the cause takes hours, because nobody remembered the certificate existed.
Where internal certificates hide
If you've never listed them, start with these:
- Intranet and staff tools: wikis, HR and finance systems, ticketing, dashboards, anything reached by an internal name such as
wiki.corp.example. - Internal APIs and microservices that talk to each other over HTTPS.
- Databases and message brokers with TLS turned on: PostgreSQL, MySQL, SQL Server, Redis, Kafka, RabbitMQ.
- Network and security appliances: firewalls, VPN gateways, load balancers, Wi-Fi controllers and access points, printers, storage arrays and their management pages.
- Identity and directory services: LDAPS on domain controllers, single sign-on servers, RADIUS.
- Monitoring and admin consoles: hypervisors, backup servers, out-of-band management (iDRAC, iLO).
Many of these never touch the internet, so a public monitor can't reach them, and their certificates are often installed by hand, once, by someone who has since moved on.
Why they break more often than public ones
- No automation. Public sites mostly renew automatically. Internal certificates are frequently issued by hand from an internal CA, with a two-year or five-year lifetime and no reminder.
- Factory defaults. Appliances often ship with a self-signed certificate valid for ten years, issued to the vendor's own hostname. It never expires in time to be noticed, but every browser and API client distrusts it, and people learn to click through the warning. That's a security problem in its own right.
- Your own CA can expire too. If the internal root or issuing CA expires, every certificate it signed stops being trusted on the same day.
- Shorter lifetimes are coming. Public certificates drop to 47 days by 2029 (how to prepare), and many organisations are shortening internal lifetimes to match. More renewals means more chances for one to fail quietly.
Why a public monitor can't see them
A monitoring service on the internet can only check what it can connect to. Internal names don't resolve outside your network, private addresses (10.x, 172.16–31.x, 192.168.x) aren't reachable, and you don't want to open firewall ports so an outside service can look in.
The agent approach
The answer is to turn the direction around. A small agent runs inside your network, where it can reach those hosts, and does what a browser does at the start of a connection: it reads the certificate each host presents. Then it reports what it saw to CertHalo over an ordinary outbound HTTPS connection.
CertHalo analyses each certificate exactly as it does a public one: expiry date, whether the chain leads to a trusted root (including your own internal root CA, if you upload it), whether the certificate covers the name you use, key strength and TLS version. You get the same grade and the same alerts: reminders before expiry, and a message when a certificate changes, breaks or can't be reached.
Today's agents read certificates from anything that speaks TLS from the first byte: HTTPS on any port, LDAPS, Redis, Kafka and RabbitMQ with TLS, and most appliance management pages. Services that switch to TLS partway through their own protocol (PostgreSQL, MySQL, SMTP, plain LDAP) aren't covered yet.
Done properly, this is safe to run inside a sensitive network:
- Certificates only. A certificate is public information that every client sees. Agents never send private keys, passwords or anything else from your servers, and CertHalo refuses a report that contains a key.
- One outbound connection. No inbound firewall rules, and CertHalo never connects into your network.
- Least privilege. An agent's key can only send reports. It can't read your results or change anything.
- Open source. Your security team can read exactly what the agent does, and run it with
--dry-runto see exactly what it would send. - It notices when it stops. If an agent misses its reports, you get a "no report" alert, so a dead agent never looks like "all fine".
A real example
While testing, we pointed an agent at a Wi-Fi access point on our own office network. It reported straight away: the access point was still serving its factory certificate, issued by its own built-in CA to the vendor's setup hostname, valid until 2031. CertHalo graded it F: the certificate doesn't cover the address staff use, and its chain isn't trusted by anything. Nothing was about to expire, but every login on that page had been teaching people to ignore certificate warnings. That's exactly the kind of certificate nobody looks at until something goes wrong.
When you need it
You'll get value from internal monitoring if any of these are true:
- You run your own certificate authority (Active Directory Certificate Services, HashiCorp Vault, step-ca, EJBCA).
- You've had an outage caused by an expired certificate that wasn't on a public website.
- Security or audit asks you to show that internal TLS is in order.
- You manage infrastructure for clients and want one view of every certificate, public and internal.
Getting started
Internal certificates are on CertHalo's Business plan. Setting up an agent takes a few minutes: create an Agent key, list your hosts, check what would be sent, and schedule it. The step-by-step guide is Monitor internal certificates with a CertHalo agent, and if your services run in Kubernetes, see Monitor Kubernetes service certificates.
Not sure what's out there yet? Find all your SSL certificates covers building the list in the first place.