Discover, connect, renew, deploy, verify.
Five steps, in the order a certificate needs them. The first one gives you the inventory in a day; the other four turn an expiry alert into an approval instead of a task.
Discover
Build the inventory from what is actually running.
You install the sensor with one command and verify your domains with a DNS record. The sensor reports every certificate it meets on the networks you allow; Certificate Transparency adds every publicly trusted certificate issued for your domains. Both are deduplicated into one inventory with expiry alerts.
Connect
Add the CA accounts you already have.
Each connector uses the provider’s own protocol and credentials: an ACME account for Let’s Encrypt and other ACME providers, an API key or OAuth client for commercial CAs. Credentials are stored encrypted per connector, and an issuer allowlist keeps a renewal from landing at the wrong CA.
Renew
Let renewals run through your accounts.
A renewal is requested from the inventory, the API or the MCP server, or opened by the scheduler inside the renewal window. It passes an approval queue if you want one, then a state machine tracks it from request to issued certificate, with spending caps per connector. You can supply your own CSR; otherwise a key is generated for the request and not kept.
Deploy
Put the new certificate where it is served.
The renewed certificate is delivered to the target you connected: a load balancer, a web server, a Kubernetes ingress, a cloud certificate store. Deployment follows the same approval model as renewal, so a high-impact change can wait for a second pair of eyes.
Verify
Confirm the endpoint really serves the new certificate.
After a renewal, NextPKI probes the endpoint and alerts when the old certificate is still being served, when the endpoint is unreachable, or when something unexpected answers. A renewal counts as done when the live handshake shows the new certificate, not when the CA issued it.
What stays the same in every step
- Your accounts, your contracts
- NextPKI acts through the CA accounts and permissions you give it. It never buys certificates for you and never puts itself between you and your CA commercially.
- Approval where you want it
- Routine renewals run unattended; high-impact ones can require an approver. Both leave an audit trail.
- No private keys in transit
- The sensor records public certificates only. For renewals you can supply your own CSR; a server-side key is generated only for the request and not stored.
- The same facts everywhere
- Console, API and MCP server read the same inventory, so a script and a person see the same answer.
Take control of your certificates.
Request an account, tell us in a few lines where your certificates run, and start with the inventory. Connectors and targets are set up with you during onboarding.