Welcome to CertIntel

TLS certificates are everywhere. The process for managing them is often scattered across just as many places: an IIS binding, an NGINX reverse proxy, a load balancer, a firewall, a cloud service, and an internal application that nobody outside the network can reach.

An expiration reminder helps, but it answers only one question. Which certificate is actually installed? Where else is it used? Did the renewal run? Did the service start presenting the replacement? Does the certificate chain lead to a root that your clients trust?

CertIntel exists to make those questions easier to answer without maintaining a separate spreadsheet for every customer or environment.

What is CertIntel?

CertIntel is a certificate visibility and lifecycle platform. It brings together public TLS endpoint monitoring, certificate inventory, internal observations, renewal reporting, and alerts. Its Windows and Linux Agent adds local certificate monitoring and ACME issuance, installation, and renewal.

The distinction between those roles matters. The platform collects observations and shows what needs attention. The agent performs configured work on the host, including requesting and deploying certificates. Certificate private keys stay on that host.

The current platform supports several ways to build a useful picture:

• Public endpoint monitoring. Check the certificate presented by a configured public hostname and track its expiration.
• Certificate inventory and inspection. See observed sources, validity dates, names, issuers, and available chain information. The certificate detail view exposes X.509 fields that help explain what a certificate is for.
• Certificate Transparency discovery. Review certificates found through CT logs in a separate discovery list. A logged certificate is evidence of issuance; it does not prove that a particular endpoint is serving it.
• Renewal visibility. Collect agent reports and check-ins from existing renewal clients so a successful issuance and a healthy reporting process can be considered separately.
• Alerts and integrations. Configure notifications and use scoped API credentials to connect certificate reporting to your existing operations.

The certificate inventory documentation explains how observed certificates and their sources fit together. A displayed chain also needs context: organization-specific trust and hostname coverage are distinct checks, and neither should be mistaken for a guarantee about every client's trust store.

Built for more than public websites

Some of the certificates that matter most are behind a VPN or on a management network. An internal service can have a perfectly ordinary TLS listener while being unreachable from a hosted monitoring system.

The agent can probe configured internal host and port pairs from inside the network. It can also inventory configured certificate files and, on Windows, certificate stores. Platform-assigned internal endpoints let administrators manage targets centrally while an enrolled agent performs the connection locally.

This is bounded monitoring of configured sources. It is not an automatic subnet sweep. An appliance does not have to run the agent itself if an agent on another machine can reach its TLS listener.

• 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

Each source feeds public certificate metadata or probe errors into CertIntel for inventory and health review. The service stays on the internal network, and private keys stay on the host.

The internal endpoint guide describes the distinction between local monitors and platform assignments. It also explains an important troubleshooting detail: inventory probes intentionally record certificates even when they are expired or untrusted. Being observable is different from passing application trust validation.

Certificate lifecycle automation

ACME, the Automated Certificate Management Environment protocol, lets software request and renew certificates from a certificate authority. The CertIntel Agent contains its own ACME client and can run configured issuance and deployment workflows locally.

For agent-managed issuance, use Let's Encrypt or a compatible configured ACME directory. External Account Binding is supported when a provider requires it. Provider eligibility, validation requirements, and account terms still apply; selecting a directory does not bypass the CA's checks.

The agent's DNS-01 workflow uses CertIntel's delegated DNS service. You create the delegation and publish the specific _acme-challenge CNAME at your authoritative DNS provider. The agent then uses scoped delegation credentials to manage challenge TXT values at the assigned destination. It checks propagation before asking the CA to validate.

That arrangement automates the delegated challenge records. It does not give CertIntel general control of your DNS zone or eliminate the initial DNS setup. See delegated DNS-01 and ACME provider setup for the exact configuration.

After issuance, the agent performs the configured storage and installation actions and handles subsequent renewals. A replacement certificate still needs to reach the service that uses it. Monitoring the served certificate is how you close that loop.

Monitoring an internal or AD CS certificate is separate from issuing one. Do not assume that adding a certificate to inventory also configures its renewal authority or deployment workflow.

Teams that already run an ACME client can retain it. CertIntel documents reporting integrations for renewal events and check-ins, alongside public endpoint and agent-based monitoring. You can improve visibility before changing the process that owns renewal.

Built for MSPs and larger environments

A CertIntel tenant is the account or workspace. Within it, child organizations divide resources by customer, team, region, or business unit. Certificates, monitored targets, API keys, install tokens, and DNS delegations are scoped to an organization, with selected tenant-wide resources available to appropriately authorized administrators.

This matters for an MSP managing several customers: a technician's access should follow the environments they maintain. Built-in roles and organization scopes control that access; tenant administration is a separate authority. Plans determine applicable resource limits.

The organizations and roles guide describes those boundaries. For integrations, the API key guide explains how credentials are scoped. Interactive API documentation is available at /api/v1/docs on your CertIntel platform deployment.

Where we are going

Our direction is practical: make certificate state easier to inspect, make automation easier to operate, and expose useful information through APIs. The aim is fewer surprises between issuance, installation, and the next renewal.

That includes explaining the PKI details behind a confusing result. Two clients can see the same endpoint certificate and arrive at different trust decisions. A renewal job can succeed while a service continues presenting the old certificate. Good visibility needs to preserve those distinctions.

This blog will cover product changes alongside TLS, PKI, ACME, Certificate Transparency, and practical certificate troubleshooting. Start with the platform overview, explore the documentation, or read how certificate cross-signing gives clients different paths to trust.