Welcome to CertIntel

Most teams don't have a certificate problem until the day they do. Then it turns out the certificate that just expired was bound in IIS on one box, copied to an NGINX proxy on another, uploaded to a load balancer, and also sitting on a firewall nobody has logged into since the person who set it up left. The calendar reminder fired on time. It just didn't say where the certificate lived.

That's the gap CertIntel is built for. An expiry reminder answers one question. The ones that actually cost you an outage are different: which certificate is installed right now, where else is that same certificate used, did last night's renewal actually run, is the service presenting the new one yet, and does the chain it sends lead somewhere clients trust?

What CertIntel is

CertIntel is a certificate visibility and lifecycle platform. It watches public TLS endpoints, keeps an inventory of the certificates it sees, takes observations from inside your network through an agent, collects renewal reports, and raises alerts. The Windows and Linux agent is also an ACME client, so it can request, install and renew certificates on the hosts where it runs.

We keep those two roles separate on purpose. The platform collects observations and tells you what needs attention. The agent does the configured work on the host, including requesting and deploying certificates. Private keys stay on that host. The platform never has them and doesn't need them.

A few pieces make up the picture today:

• Public endpoint monitoring. Point it at a hostname and it checks the certificate that hostname presents and tracks when it expires.
• Certificate inventory. Every certificate that's been observed, with where it was seen, its dates, names, issuer and whatever chain information came with it. The detail view shows the X.509 fields that explain what a certificate is actually for.
• Certificate Transparency discovery. Certificates for your names found in CT logs, in their own list. A CT entry proves something was issued. It doesn't prove any particular server is serving it, so we don't mix the two.
• Renewal visibility. Agent reports and check-ins from whatever renewal client you already run, so "the issuance succeeded" and "the thing that reports to us is healthy" can be judged separately.
• Alerts and integrations. Notifications, plus scoped API credentials for wiring certificate state into tooling you already have.

The certificate inventory documentation goes into how observed certificates and their sources fit together. One thing worth saying up front: when the inventory shows you a chain, that's what was observed, not a verdict. Whether a given client trusts that chain, and whether the certificate covers the hostname that client used, are separate checks.

Built for the certificates behind the VPN

Plenty of the certificates that matter most aren't reachable from the internet. A management interface on a storage array, an internal API, a domain controller's LDAPS listener. They all speak TLS. A hosted monitoring service can't see any of them.

The agent can. It probes internal host and port pairs from inside the network, inventories certificate files you point it at, and on Windows reads the certificate stores you select. Internal endpoints can also be assigned from the platform, so an administrator defines the targets centrally and an enrolled agent on the right network makes the connections.

This is bounded monitoring of things you configured. It is not a subnet sweep, and it won't discover hosts you didn't tell it about. The upside of that is predictability: nothing gets scanned that you didn't ask for. It also means an appliance doesn't need to run the agent itself. Any agent that can reach its TLS listener can report on it.

• Internal TLS endpointsAgent probes configured hosts and ports
• Certificate filesAgent reads configured local files
• Windows certificate storesAgent inventories selected stores
• Platform-assigned endpointsAgent runs centrally scheduled internal probes

CertIntel

What crosses the wire is certificate metadata and probe results. The service stays internal and the private key stays on the host.

The internal endpoint guide covers the difference between monitors the agent owns and targets assigned from the platform. It also explains a detail that trips people up: inventory probes record a certificate even when it's expired or untrusted. That's deliberate. Seeing a bad certificate is the point. Whether it passes validation is a different question, answered elsewhere.

Issuing and renewing

ACME is the protocol Let's Encrypt made famous: software proves it controls a name, and a CA issues a certificate without a human in the loop. The agent has its own ACME client and runs the issuance and deployment steps you configure, locally.

It works with Let's Encrypt or any compatible ACME directory, and supports External Account Binding for providers that require it. The CA's own rules still apply. Picking a directory in CertIntel doesn't get you past a provider's eligibility checks or terms.

For DNS-01 validation the agent uses CertIntel's delegated DNS service. You publish one _acme-challenge CNAME at your DNS provider, pointing at the delegation. From then on the agent writes challenge TXT records at that destination using credentials scoped to just that, waits for them to propagate, and then asks the CA to validate. CertIntel never has write access to your zone. You do the one-time CNAME; the agent handles the churn after that. The exact setup is in delegated DNS-01 and ACME provider setup.

Once the certificate is issued the agent stores and installs it the way you configured and takes care of future renewals. That still leaves the question every renewal setup has to answer: did the service actually pick up the new certificate? A successful renewal and a service still presenting the old file look identical from the ACME client's point of view. Monitoring what's served is how you find out.

Monitoring a certificate and issuing it are separate things. Adding an internal or AD CS certificate to the inventory doesn't make CertIntel responsible for renewing it, and nobody should assume it does.

If you already run certbot, win-acme or something similar and it works, keep it. CertIntel can take renewal reports and check-ins from existing clients alongside its own monitoring, so you can get the visibility first and decide later whether to move the renewals.

Built for MSPs and larger environments

A CertIntel tenant is the account. Inside it, child organizations split things up by customer, team, region, or whatever makes sense. Certificates, monitored targets, API keys, install tokens and DNS delegations all belong to an organization, and a handful of tenant-wide resources are visible to administrators with the right role.

If you're an MSP, this is the part that matters. A technician who looks after three customers should see those three and nothing else. Built-in roles and organization scopes handle that, tenant administration is its own permission, and plan limits apply per resource.

The organizations and roles guide spells out the boundaries. The API key guide covers how credentials are scoped for integrations, and every CertIntel deployment serves interactive API documentation at /api/v1/docs.

Where this is going

The plan isn't complicated. Make certificate state easy to inspect, make the automation easy to run, and expose what we know through APIs so you can build on it. Fewer surprises between issuance, installation and the next renewal.

Part of that is explaining the PKI behind a confusing result instead of hiding it. Two clients can look at the same server and disagree about whether to trust it. A renewal can succeed while the service keeps serving the old certificate. A monitoring tool that flattens those situations into a green tick isn't helping.

We'll use this blog for product changes and for the practical side of TLS, PKI, ACME and Certificate Transparency: the things that come up when you're actually responsible for the certificates. To get started, have a look at the platform overview or the documentation, or read about how certificate cross-signing gives clients different paths to trust.