Setup guide
Caddy setup guide for sslcertificates.io
This guide explains how to connect Caddy to sslcertificates.io, what credentials to prepare, and how to operate safely in Test (Let's Encrypt Staging) and Live (publicly trusted issuance) environments.
What this integration does
Caddy deployment Prefers pointing Caddy at the platform ACME directory. File/admin API cert load is used only when ACME is not appropriate. ssh/WinRM sessions use pinned host keys. Caddy admin API load or ACME endpoint mode
Category: Web Servers & Load Balancers. Public integration page: /integrations/caddy.
Outcomes
- Discover the Caddy resources that terminate TLS
- Install a replacement certificate
- Verify the public TLS endpoint
- Keep the previous certificate for rollback
Prerequisites
- A Caddy environment you operate
- API or agent access with permission to install certificates
- Restricted service account. Commands are allowlisted: Caddy admin API load or ACME endpoint mode. Known-host verification is mandatory.
Authentication and credentials
Authentication mode in the catalog: api_token.
Fields the connection form expects: Host (required); Username (required); SSH/WinRM private key (optional); Password (optional); Known hosts pin (required); Certificate path (optional)
Store secrets in a password manager while you paste them once into sslcertificates.io. Values are encrypted at rest and are not shown again after save. Prefer narrowly scoped credentials over admin passwords.
Restricted service account. Commands are allowlisted: Caddy admin API load or ACME endpoint mode. Known-host verification is mandatory.
Permissions (least privilege)
Restricted service account. Commands are allowlisted: Caddy admin API load or ACME endpoint mode. Known-host verification is mandatory.
User-supplied shell is rejected. A successful file write is not enough; the TLS endpoint must present the new fingerprint.
Connect in the workspace
- Sign in to sslcertificates.io
- Open Integrations
- Choose Caddy
- Enter the connection details
- Test the connection
- Select the resources you want to manage
After Test connection succeeds, run Discover so the platform lists zones, subscriptions, domains, or deploy targets you are allowed to see. Select only resources this organization should manage.
Test vs Live certificate environments
Test uses Let's Encrypt Staging as the CA directory. Staging certificates are not trusted by browsers; use them to prove DNS-01, HTTP-01, deploy scripts, and webhooks without consuming production rate limits.
Live uses Let's Encrypt Production (or a commercial CA you connect) for publicly trusted certificates. The integration connection is the same; only the API key environment and CA selection on the certificate order change.
Create separate API keys labeled Test and Live. Do not reuse a Live key in CI that hammers validation endpoints.
Deployment and verification
After issuance, deployment connectors install the leaf and chain (and private key when applicable), bind the certificate to the site or listener, reload or apply configuration where required, and optionally verify the public TLS handshake.
Treat HTTP 200 from a vendor API as incomplete success. Compare the SHA-256 fingerprint of the certificate served on port 443 to the leaf you expect. The platform may keep a .prev or rollback copy — use it if a bad deploy breaks HTTPS.
Capabilities referenced for this integration: atomic_write, config_test, reload, tls_verify, rollback.
Rollback
If verification fails after deploy, restore the previous certificate using the integration rollback path or manual vendor UI, then open a ticket with the order id and X-Request-Id.
Discovery
Discovery runs only after authentication succeeds. The integration enumerates resources the credential may read — hosted zones, subscriptions, domains, clusters, or load balancers depending on Caddy. If discovery returns empty, the credential is usually too narrow or pointed at the wrong account or region.
Renewal and ongoing operation
When Caddy participates in deployment or DNS automation, renewals re-use the same connection. Watch webhook events such as certificate.renewal_failed and verify the external endpoint after every replacement. A renewed certificate in inventory is not proof HTTPS serves the new leaf.
Disconnect and credential rotation
Open Workspace → Integrations → Caddy → Disconnect to remove stored credentials from this organization. DNS integrations should delete only TXT records the platform created for ACME challenges. Rotate vendor tokens on a schedule; update the integration, run Test connection, and revoke the old credential at the vendor.
Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| Test connection fails immediately | Wrong host, region, or token | Re-copy credentials; confirm clock skew and TLS to the vendor API |
| Discovery is empty | Scoped IAM/token cannot list resources | Widen read permissions temporarily, discover, then tighten |
| Order stuck validating | DNS or HTTP challenge not public yet | Inspect the order challenges; wait for propagation; POST validate |
| Deploy reported success but HTTPS unchanged | Old cert still bound on the edge | Compare served SHA-256 to expected leaf; reload or bind again |
insufficient_scope from sslcertificates.io API |
API key missing abilities | Mint a key with integrations:write and certificates:write |
Stable API error codes are documented at /docs/errors. Include X-Request-Id when contacting support.
Official vendor documentation
Related reading
/docs/integrations— how connectors relate to the REST API/docs/test-vs-live— Test (Staging) vs Live (Production) issuance/docs/troubleshooting— order states and verification/integrations/web-servers-load-balancers— other Web Servers & Load Balancers integrations