Domains & DNS
Never let a certificate take your site down
Every TLS certificate you serve, found for you and kept in one list — one row per certificate, however many places you found it. InfraNest reads them from your monitors, from a scan, from public logs and from your providers, tells you what is wrong with each in plain words, and only wakes you when a renewal has actually failed.
Free plan · No credit card · First certificates found in under a minute
- Found without you listing them
- One row per certificate, not per sighting
- Quiet until a renewal actually fails
- We never hold your private key
Sectigo RSA Organization Validation Secure Server CAIssuerMonitorDiscovered, not monitoredIgnore
A live SSL monitor watches this certificate — an expiry, chain break or outage is caught the moment it happens. Discovered certs with no monitor are a blind spot; adding one links it automatically on the next run.
Add SSL monitorCAAIssuer not authorized by the domain’s CAA policyIgnore
The domain’s DNS rules for who may issue certificates (its CAA records) don’t include this certificate’s issuer — either a setup mistake to fix, or a certificate someone obtained that you didn’t expect.
Manage CAAShow 6 passedHide passed
Works with your certificate sources
You do not have to know where they all are
The certificates that take a site down are the ones nobody wrote in the spreadsheet — on a load balancer somebody set up two years ago, on a mail server, on an internal service. So the Add screen does not start with a form. It starts by telling you which of your own registered domains have no certificate at all, which is usually why you are there. Past that, six routes feed the same inventory: every SSL monitor you already run, a scan of any hostname, Certificate Transparency logs, your providers’ and registrars’ APIs, a bulk PEM import for your own tooling, and a paste box. Each certificate is then matched to the domain it belongs to — apex, subdomain or wildcard — including retroactively, when you add that domain months later.
- The domains you own with nothing serving them, listed before you type anything
- A scan reads a hostname directly — including self-signed, expired and mismatched ones
- AWS ACM, Cloudflare, DigitalOcean, Hetzner, IONOS, TransIP, Namecheap, Porkbun, Openprovider and SSL.com
- Post a batch of PEMs from your own tooling — up to 500 a call, deduped, so a job can re-post its whole set
Scan a live endpoint, import a certificate you already have, or start from a domain that has none.
Registered domains InfraNest has no certificate for. Scan one to detect a certificate it’s already serving.
Enter a public host and we’ll connect, read the certificate it’s serving, and add it to the inventory — including self-signed or expired ones, so the health checks can flag them.
Paste a PEM you already have. Best for certificates not yet deployed anywhere.
-----BEGIN CERTIFICATE----- MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAw DQYJKoZIhvcNAQELBQAwTzELMAkGA1UEBhMCVVMxKTAn … -----END CERTIFICATE-----
Every certificate, and the one thing wrong with each
The inventory groups by registered domain, so twelve subdomain certificates roll up under the name you think of them by, and each group says how many renew themselves and how many nothing is watching. The column that earns the screen is Needs attention: not a status code, but the single thing wrong with that certificate written in words — discovered but not monitored, expired, not trusted by browsers. Each group header counts how many renew themselves, which is the distinction the alerting is built on: 30, 14, 7, 3 and 1 day for the ones you renew, silence until the final day for the ones that renew themselves.
- Grouped by domain, with per-group counts for auto-renew and unmonitored
- Auto-renewing certificates stay quiet until one day out, so a warning means the renewal failed
- A certificate inside its warning window is not an outage — no false incident, no red on your status page
- Search, source and usage filters, an issues-only toggle, and saved views
What it protects, and how you know
A certificate is one row, and the row answers two questions. What does it cover — every name on it, so a wildcard or a five-name SAN certificate stops hiding what it is responsible for. And how do we know — every sighting kept behind it, naming the source and when it last saw this exact certificate. That second list is why there is one row rather than four: the same certificate found by your monitor, by a scan, by the provider API and in a public log is matched on fingerprint, then on issuer and serial, and folded into a single entry instead of four things to renew.
- Matched on fingerprint, then issuer and serial, then SAN set for metadata-only rows
- Every sighting kept — you can still see which source saw it and when
- Merge and split by hand for the cases the matching gets wrong, and a merge is remembered
- Load-balanced, anycast and multi-cloud deployments stay one entry with every host listed
The names this certificate secures, and where it’s being served.
Hosts where this exact certificate was observed being served (load-balanced or multi-cloud deployments collapse to one entry).
Not yet observed on a live endpoint.
- Key
- ECDSA 256-bit
- Signature
- ECDSA-SHA256
- Serial
- 95D23858
- Observed by · 2 sources
Every place InfraNest has seen this one certificate — provider imports, live monitors, Certificate Transparency logs and manual scans all fold into a single entry.
Everything else it handles
The parts that are only interesting when you need them.
One row per certificate
The same certificate seen by a monitor, a scan and a provider API collapses into one entry, matched on fingerprint, then issuer and serial. Every sighting is kept, so you can still see which source saw it and when.
Merge and split by hand
For the cases the matching gets wrong. A merge is remembered, so re-observing the certificate never recreates the duplicate.
Deployment footprint
Every host observed serving a certificate, so load-balanced, anycast and multi-cloud deployments stay one entry with the full picture.
Renewal lineage
Issued, renewed, superseded, expired — with a timeline per certificate. Auto-renewal series collapse so a 90-day rotation does not flood the list; superseded rows are kept as history, never deleted.
Cost, per certificate
A first-class annual cost feeding the spend report. Certificates from an issuer that sells nothing are recorded as free automatically and badged as such.
It will not guess a price
For a CA that sells both free and paid certificates, the price is left blank rather than filled in with a wrong €0 — a blank asks the question, a wrong number answers it. Anything you type wins.
OV and EV identity
For certificates that assert one, the vetted organisation and location the CA actually checked, captured alongside the rest.
Cross-linked both ways
A domain lists its certificates, an SSL monitor links the certificate it observes, and a certificate links back to its monitor, domain, server and credential.
See your own certificates in about a minute
Paste a hostname, or connect a provider read-only. Nothing is issued and nothing is changed.
Tracking certificates by hand vs InfraNest
The difference between a renewal spreadsheet nobody trusts and an inventory that finds the ones you forgot.
By hand
- A spreadsheet that is out of date the week after you write it
- A calendar reminder for the certificates somebody remembered
- Expiry mail on every healthy renewal, until you filter the folder
- The missing intermediate that works in your browser and fails on a phone
- No idea a certificate was issued for your domain until somebody uses it
With InfraNest
- Six routes filling one inventory without you listing anything
- One row per certificate, with every sighting behind it
- Silence on an auto-renewing certificate until the renewal actually fails
- The chain rebuilt, verdicted, and the absent intermediate offered as a download
- Public logs watched per domain against the issuers you actually authorised
One login, ten modules
Every module is in every plan, Free included — what changes is how much of each you get.
The cost of doing it separately
Buy each piece from a different tool and it adds up fast:
- Domain & DNS
- ~€30
- Uptime monitoring
- ~€29
- SSL tracking
- ~€15
- Status page
- ~€29
- Server panel
- ~€15
- Across 4–5 separate tools
- €100–150/mo
Frequently asked
How does InfraNest find my certificates?
Six ways into one inventory: the SSL monitors you already run, an on-demand scan of any hostname, Certificate Transparency logs, your providers’ and registrars’ APIs, a bulk PEM import endpoint for anything a public scan cannot reach, and a paste box for the rest. Each one is matched to the registered domain it belongs to, including retroactively if you add that domain later.
Do you store my private keys?
No, and there is nowhere to put one — the inventory is metadata, with no key column and no PEM column. We never store a private key we did not generate. When you ask for deployable files, the chain and key are fetched live from your provider and persisted nowhere: gated on write permission rather than read, rate-limited, and written to the audit log by name.
Will it email me every time Let’s Encrypt renews?
No, and that is rather the point. A certificate that renews itself stays silent until one day out, so a warning means the renewal actually failed. The 30, 14, 7, 3 and 1 day escalation is for certificates a human has to renew. A certificate inside its warning window is also not treated as an outage, so it never turns your public status page red.
Which certificate authorities does it support?
All of them. A scan and a public log do not care who issued the certificate, so any CA is inventoried and graded the same way — including your own internal CA, which is tracked alongside the public ones and can be added to a domain’s expected-issuer list so it imports quietly.
Does InfraNest issue or renew certificates?
No. Issuance and renewal stay where they are — your CA, your platform, your ACME client. InfraNest confirms the new certificate actually reached the endpoint, which is the half that usually goes wrong: the renewed-but-not-deployed case, where the certificate you hold is not the one being served.
What happens when the industry moves to shorter certificates?
Nothing you have to change. The warning window is derived from each certificate’s own lifetime rather than a fixed number of days, so the 47-day certificates the CA/Browser Forum has voted for are handled on the same logic as today’s 398-day ones.
Can I get certificates into the inventory from my own tooling?
Yes — paste a PEM, or POST to the certificates endpoint. API access is scoped by certificates.read and certificates.write token abilities, everything is org-scoped, and every mutation is audited. There are automation actions too: Scan certificate host and Link certificate, and all five certificate events carry the certificate id.
Every certificate, one inventory
Paste a hostname and see what is already out there in your name.
Free plan · No credit card required · Set up in minutes