CA connectors
A connector is your account at a certificate authority, configured inside
NextPKI. Renewals are ordered through a connector, which is why
POST /v1/certificates/{id}/renew requires a connector_id.
Connectors are configured in the Console under Settings → Connectors; there is no connector-management API in v1.
What a connector holds
Section titled “What a connector holds”| Part | Notes |
|---|---|
| Provider | Which CA - see supported authorities |
| Credentials | Encrypted at rest with envelope encryption, never returned by any API |
| API endpoint | Overridable, which is how white-label resellers on a shared platform are supported |
| Monthly spending cap | Optional, in cents. Enforced before the order is placed |
| Issuer DN allowlist | Optional. Rejects a certificate whose issuer is not on the list |
Credentials are write-only from the outside. There is no endpoint that reads them back, and support cannot recover them either.
Guardrails
Section titled “Guardrails”These exist because an automated renewal layer with access to a paid CA account is, structurally, a machine for spending money quickly if something loops.
Spending caps. The connector’s month-to-date spend is summed and checked before the plugin is called. Over the cap, the renewal fails rather than orders.
Circuit breaker. Three failures within ten minutes pause the connector for thirty minutes. This protects both you and the CA’s rate limits from a tight failure loop.
Anomaly detection. If the renewal rate exceeds five times the connector’s established hourly baseline, renewals are flagged rather than executed. A legitimate bulk migration will trip this - raise caps and expect it.
Issuer DN allowlist. Opt-in. The issued certificate’s issuer DN is compared exactly against the allowlist. Useful when you must guarantee that certificates come from one specific issuing CA, and an early warning if a CA silently re-parents its hierarchy.
Plugins, and why 50 resellers do not mean 50 integrations
Section titled “Plugins, and why 50 resellers do not mean 50 integrations”Each provider names a plugin_code, and several providers can share one.
Most resellers do not run their own certificate infrastructure - they resell on a
platform, and they differ only in credentials, endpoint and branding.
Today, three providers share sectigo_reseller_api and three share
acme_generic. That is the model: integrating a platform gets you every reseller
on it.
plugin_kind |
Protocol |
|---|---|
rest_api |
HTTP/JSON, the common case for commercial CAs |
acme |
RFC 8555 |
soap |
Older enterprise APIs |
est |
RFC 7030, device enrollment |
scep |
Device enrollment |
custom |
Anything else, including the NextPKI private CA |
Adding a provider that reuses an existing plugin is a data change, not a code change - no deploy, no migration.
Standard versus enterprise APIs
Section titled “Standard versus enterprise APIs”Several CAs expose two different APIs: a reseller or standard API, and an
enterprise platform. They are often different enough to warrant separate plugins
rather than a flag - Sectigo already appears twice for exactly this reason, as
sectigo_scm (enterprise) and sectigo_reseller_api.
Expect the same split for others as they are implemented. From your side this is invisible: you pick a connector, and the connector knows which API it speaks.