Post-transfer cosmetic + release-critical URL refresh after moving the
repo from github.com/shankar0123/certctl to github.com/certctl-io/certctl
(2026-05-03). GitHub HTTP redirects continue to forward old URLs forever,
so existing operators are not broken — but aligns the canonical
references with the new owner so:
- procurement engineers / contributors browsing the docs see the right
URL on first read
- operators copying the agent install one-liner hit the new path
directly without going through a redirect
- the Helm chart's default image repository points at the canonical org
registry path
- the OnboardingWizard rendered to first-run UI users shows the new
URL in the install snippets and doc anchor links
- the GitHub Actions release workflow pushes container images to
ghcr.io/certctl-io/certctl-{server,agent} (was: shankar0123)
- the release-notes Markdown body in release.yml — which gets stamped
into every future release page — references the post-transfer
cert-identity (cosign keyless signing now uses the certctl-io
workflow URL) and the post-transfer SLSA provenance source-uri.
Without this, every cosign verify / slsa-verifier command on a
v2.1.0+ release would fail because the cert-identity-regexp would
not match the signing identity GitHub Actions OIDC issues post-
transfer. Old releases (v2.0.67 and earlier) keep their immutable
release-notes pointing at the shankar0123 path and remain
verifiable via their own published instructions.
Customer impact:
- Operators on ghcr.io/shankar0123/certctl-{server,agent}:latest
silently freeze on whatever tag was current at transfer time. They
get no errors; they just stop receiving updates. The next release
notes need a one-line callout (Phase 3.1 of cowork/transfer-
certctl-to-org.md) telling them to update their image path to
ghcr.io/certctl-io/certctl-{server,agent}.
- All other URLs (git clone, install one-liner, raw.githubusercontent
URLs, browser links, GitHub API) continue to resolve via permanent
HTTP redirects. The sweep is cosmetic for those.
Files swept (30 total):
.github/workflows/release.yml — IMAGE_NAMESPACE, source-uri,
cosign cert-identity-regexp, IMAGE= snippet (5 refs total).
CHANGELOG.md, README.md — anchor links, badges, install one-liner,
cosign verify snippets in operator-facing sections.
api/openapi.yaml — info / externalDocs URLs.
install-agent.sh — GITHUB_REPO const + systemd unit Documentation=
field.
deploy/ENVIRONMENTS.md, deploy/helm/{CHART_SUMMARY,INDEX,
INSTALLATION,README}.md, deploy/helm/certctl/{Chart.yaml,
README.md,values.yaml}, deploy/helm/examples/values-*.yaml —
chart docs + image repository defaults across dev / prod-ha
overrides.
docs/{certctl-for-cert-manager-users,connector-iis,connectors,
migrate-from-acmesh,migrate-from-certbot,quickstart,test-env,
why-certctl}.md — operator-facing doc URLs.
examples/{acme-nginx,acme-wildcard-dns01,multi-issuer,
private-ca-traefik,step-ca-haproxy}/docker-compose.yml +
examples/step-ca-haproxy/step-ca-haproxy.md — example image:
paths and accompanying narrative.
web/src/pages/OnboardingWizard.tsx — first-run-UI URL refs (curl
install one-liners, agent docker image path, doc anchor links).
Files intentionally NOT swept (Choice A from cowork/transfer-certctl-
to-org.md):
go.mod, go.sum — module declaration stays github.com/shankar0123/
certctl. Existing imports compile because Go uses the path
declared in go.mod, not the URL it was fetched from. Internal-
only project; no external Go consumers; rename will land as a
mechanical sed when one materializes.
~250 *.go files — every import remains github.com/shankar0123/
certctl/internal/...
deploy/test/f5-mock-icontrol/go.mod — separate test sub-module;
same Choice A logic; module path stays.
Files intentionally NOT swept (other reasons):
README.md lines 244-245 — Scarf-pixel docker-pull commands.
shankar0123.docker.scarf.sh/... is a Scarf-account hostname
(per-user, not per-repo) and the pixel keeps tracking pulls
against the operator's personal Scarf account. Migrating to a
certctl-io Scarf account is a separate decision (create org
Scarf account → re-create package → update README).
deploy/test/f5-mock-icontrol/f5-mock-icontrol — checked-in
compiled binary with shankar0123/certctl baked into Go build
info via the sub-module path. Out of scope for a URL sweep;
will refresh on the next `make test-integration` rebuild.
Verification:
gofmt: clean (no .go files touched).
go vet ./...: clean (verified at this SHA in 1.3 of the transfer
checklist; no .go changes since).
go build ./...: clean (same).
go test -short on representative packages: green (same).
Diff shape: 30 files, 74 insertions / 74 deletions, net-zero size,
pure URL substitution.
7.0 KiB
Migrating from Certbot to certctl
You have 50 Let's Encrypt certificates across 10 servers, managed by a mix of Certbot cron jobs and manual renewals. Certbot handles issuance, but you lack inventory visibility, centralized alerting, and audit trails. This guide walks you through moving to certctl while keeping your existing certificates and ACME account.
Why Migrate
Certbot renews certs in isolation. If a renewal fails on one server, you don't know until the cert expires. certctl gives you a single pane of glass: see all certs across all servers, get alerts 30/14/7 days before expiry, track who renewed what when, and verify each deployment succeeded via TLS fingerprint validation.
What You Keep
- Your existing Certbot ACME account key and Let's Encrypt account
- All issued certificates in
/etc/letsencrypt/live/ - Certbot's renewal history and hooks
You will not re-issue any certificates. certctl discovers them and takes over renewal scheduling.
Step-by-Step Migration
1. Deploy certctl Control Plane
Option A: Docker Compose (quickest for evaluation)
cd /opt/certctl
docker compose up -d
# Dashboard & API: https://localhost:8443 (self-signed cert — use --cacert ./deploy/test/certs/ca.crt for the default compose stack)
# Default API key in logs (grep CERTCTL_API_KEY docker logs certctl-server)
Option B: Kubernetes (Helm)
helm install certctl deploy/helm/certctl/ \
--set auth.apiKey=YOUR_SECURE_KEY
2. Deploy Agents to Each Server
On each of your 10 servers running Certbot:
# Linux amd64 (adjust for your architecture)
curl -sSL https://github.com/certctl-io/certctl/releases/download/v2.1.0/certctl-agent-linux-amd64 \
-o /usr/local/bin/certctl-agent
chmod +x /usr/local/bin/certctl-agent
# Create config
sudo mkdir -p /etc/certctl /var/lib/certctl/keys
sudo tee /etc/certctl/agent.env > /dev/null <<EOF
CERTCTL_SERVER_URL=https://certctl-control-plane.example.com:8443
CERTCTL_SERVER_CA_BUNDLE_PATH=/etc/certctl/tls/ca.crt
CERTCTL_API_KEY=your-api-key-here
CERTCTL_DISCOVERY_DIRS=/etc/letsencrypt/live
CERTCTL_KEY_DIR=/var/lib/certctl/keys
EOF
sudo chmod 600 /etc/certctl/agent.env
# Start agent
sudo systemctl start certctl-agent # if installed via script
# OR manually:
sudo certctl-agent --server https://... --api-key ... --discovery-dirs /etc/letsencrypt/live
The agent will scan /etc/letsencrypt/live/ and report all discovered certificates to the control plane.
3. Triage Discovered Certificates
In the certctl dashboard, go to Discovery:
- See all discovered certs grouped by agent
- Status shows "Unmanaged" for certificates not yet claimed
- For each Certbot cert, click Claim and link it to managed inventory
The control plane now knows about all 50 certs and where they live.
4. Configure ACME Issuer
Go to Issuers → + New Issuer:
- Select ACME from the issuer type grid
- Fill in the type-specific fields: name, directory URL (
https://acme-v02.api.letsencrypt.org/directory), and any required config
Alternatively, configure via environment variables before starting the server:
export CERTCTL_ACME_DIRECTORY_URL=https://acme-v02.api.letsencrypt.org/directory
export CERTCTL_ACME_EMAIL=your-email@example.com
export CERTCTL_ACME_CHALLENGE_TYPE=http-01 # or dns-01 for wildcard certs
For DNS-01, also set:
export CERTCTL_ACME_DNS_PRESENT_SCRIPT=/etc/certctl/dns/present.sh
export CERTCTL_ACME_DNS_CLEANUP_SCRIPT=/etc/certctl/dns/cleanup.sh
certctl uses the same Let's Encrypt account; no new credentials needed.
5. Create Renewal Policies
Go to Policies → + New Policy to create enforcement rules:
- Name: e.g., "ACME Renewal Policy"
- Type:
expiration_window(to enforce renewal thresholds) - Severity:
high - Config: set your renewal threshold (default: 30 days before expiry)
Renewal scheduling is driven by the certificate's assigned profile and issuer. Policies add enforcement guardrails (key algorithm requirements, expiration windows, etc.).
6. Disable Certbot Cron, One Server at a Time
On the first server (start with a low-traffic one):
# Stop Certbot renewal
sudo systemctl disable certbot.timer
sudo systemctl stop certbot.timer
# Or remove the cron job
sudo rm /etc/cron.d/certbot # if managed by cron
Monitor that server in the certctl dashboard. Certctl will renew the cert ~30 days before expiry.
7. Verify First Renewal Succeeds
Wait for the renewal to trigger (or manually trigger it in Certificates → select cert → Renew). Check the dashboard:
- Certificates page: status transitions from
ActivetoRenewingtoActive - Jobs page: renewal job shows
Completedstatus - Verification tab: TLS check confirms the new cert is deployed and live
After verifying, disable Certbot on the remaining 9 servers.
8. Enable Alerting
Configure notifiers via environment variables before starting the server:
# Example: Slack alerting
export CERTCTL_SLACK_WEBHOOK_URL=https://hooks.slack.com/services/YOUR/WEBHOOK/URL
docker compose up -d
# Or email alerting
export CERTCTL_SMTP_HOST=smtp.gmail.com
export CERTCTL_SMTP_PORT=587
export CERTCTL_SMTP_USERNAME=your-email@gmail.com
export CERTCTL_SMTP_PASSWORD=your-app-password
export CERTCTL_SMTP_FROM_ADDRESS=certctl@example.com
docker compose up -d
# Other options: CERTCTL_TEAMS_WEBHOOK_URL, CERTCTL_PAGERDUTY_ROUTING_KEY, CERTCTL_OPSGENIE_API_KEY
Now you get 30/14/7-day warnings before any cert expires, across all 10 servers, in one place.
What Changes
- Renewal: Agent polls certctl for work instead of Certbot cron triggering locally. Faster failure detection (agent heartbeat every 60 seconds vs. cron running once a day).
- Deployment: certctl verifies post-deployment by probing the live TLS endpoint and comparing SHA-256 fingerprints. Catches reload failures silently.
- Audit Trail: Every renewal, deployment, and alert is logged immutably. Answer "who renewed cert X when and why" within seconds.
- Alerting: Threshold-based alerts to Slack/email/webhook 30/14/7 days before expiry, not when cert expires.
Coexistence and Rollback
During migration, certctl and Certbot can run simultaneously. The agent will discover Certbot certs even while Certbot continues renewing them. Run both for a week to build confidence.
If you need to rollback: Re-enable Certbot cron on any server:
sudo systemctl enable certbot.timer
sudo systemctl start certbot.timer
certctl will stop renewing that cert when the policy is disabled. Certbot resumes as before. Your certificates and ACME account remain untouched.
Next Steps
- Try the ACME + NGINX example — a working docker-compose you can run locally before deploying to production
- Review the Concepts Guide for terminology (profiles, policies, agents, jobs)
- Explore Network Discovery to find certificates you didn't know about
- See all Deployment Examples for other scenarios (wildcard DNS-01, private CA, step-ca, multi-issuer)