u/certctl

Solo founder, no funding. Building certctl, an open core cert lifecycle platform, against an enterprise market dominated by Venafi (CyberArk), Keyfactor, AppViewX. Wanted to share what I've actually learned, since per this sub's rules a pure pitch isn't the format.

Lesson 1: The commercial cert market isn't actually selling certs.

Spent the first three months thinking I was building a cheaper Venafi. Was wrong. The commercial cert market is selling management software with a cert wrapped around it as the billing vehicle. Let's Encrypt commoditized DV certs in 2016. Browsers don't visually distinguish DV from EV anymore (Chrome 77, Firefox 70, both 2019). DigiCert / GlobalSign / Sectigo / Entrust still charge $200 to $500/year per cert because the cert is the loss-leader. The actual revenue is the proprietary automation portal, key vault, monitoring dashboard, and "premium support" they bundle into each cert sale.

Reframing this changed the product entirely. I'm not building a cheaper Venafi. I'm building the thing the loss-leader bundling is hiding: the management layer should be free, the cert is whoever's free CA you trust.

Lesson 2: The connector library is the moat, not the protocol code.

Enterprise CLM platforms (Venafi, Keyfactor, etc) ship native integrations for maybe 60% of what their customers actually run. The other 40% gets bridged via custom plugin frameworks written by their professional-services architects, billed at $250 to $400/hr, hundreds of hours in year one, on top of a six-to-seven-figure license. The job titles vary (Solutions Architect, Implementation Architect, Accelerator Architect, Digital Trust Architect) but the work is identical: write the integration the platform should have shipped with.

That 40% is the actual category. Native connectors for IIS, F5, Java keystores, K8s, AWS ACM, Azure Key Vault, Postfix + Dovecot, agentless SSH. That's where the real engineering work is, and commercial vendors actively avoid shipping it because the gap funds their professional services line.

Progress: 12 issuer connectors and 15 target connectors shipped so far. Each one took 1 to 3 days but maintenance is a tax forever as vendor APIs drift. This is the unglamorous work nobody else is incentivized to do, which is exactly why an OSS layer makes sense.

Lesson 3: Licensing is the conversation I keep having.

Went with BSL 1.1. Got pushback in r/freesoftware on the "non-OSI" framing. The honest reasoning: Apache 2.0 day one means AWS wraps it as a managed service before the project has a community. BSL prevents the competing-managed-service case but allows everything else (read, modify, fork, self-host, run internally). Same license HashiCorp and MariaDB use for the same reason. Still working out whether that's the right call long-term.

The forcing function in the background.

CABF SC-081v3 already cut public-CA max validity to 200 days as of March 15, 2026. 100-day in 2027. 47-day in 2029. Manual cert workflows break at that cadence. The category is going to grow roughly 4x by 2029 just from cadence pressure. This is the window for an OSS alternative to take ground.

Just launched on Product Hunt today if you want to take a look: https://www.producthunt.com/products/certctl?launch=certctl

Repo: https://github.com/certctl-io/certctl

Landing: https://certctl.io

Update on the certctl post from a couple months back.

Every commercial CLM platform ships a control plane that natively integrates with maybe 60% of what the customer actually runs. The other 40%, the load balancers, the app servers, the in-house systems, the regional CAs, the niche issuance protocols, gets bridged via custom plugin frameworks. Those plugins exist *because the platforms didn't ship native connectors*. They get written by professional-services architects on the vendor's payroll, billed back to the customer at $250–$400/hr, hundreds of hours in year one alone, on top of a six-to-seven-figure license. The job titles vary by vendor. Solutions Architect, Implementation Architect, Accelerator Architect, Digital Trust Architect, but the work is identical: write the integration the platform should have shipped with.

Also relevant, Let's Encrypt halted issuance for a couple of hours this morning over a cross-signed root issue between their Generation X and Generation Y roots. Real-world reminder that automation + multi-issuer fallback isn't a "nice to have" anymore.

What's shipped since the original post:

• 14 issuer connectors. Real implementations — DigiCert, GlobalSign, Sectigo, Entrust, AWS Private CA, Google CAS using their actual SDKs, plus the OSS path: Let's Encrypt, step-ca, Vault, EJBCA, OpenSSL, internal local CA.
• 16 target connectors. NGINX, Apache, HAProxy, Caddy, Traefik, Envoy, IIS, Java keystores, K8s secrets, F5 BIG-IP, AWS ACM, Azure Key Vault, agentless SSH deploy, and more.
• Full RFC 8555 ACME server with RFC 9773 ARI. cert-manager / certbot / lego / acme sh all just work against it.
• RFC 8894 SCEP server, native PKIMessage wire format implementation (not a thin wrapper).
• Multi-level intermediate CA hierarchy with RFC 5280 §3.2 / §4.2.1.9 / §4.2.1.10 enforcement.
• HSM-ready signer abstraction (FileDriver + MemoryDriver shipped; PKCS#11 driver next bundle).
• Approval workflow primitive — two-person integrity for compliance-tier issuance.
• Append-only audit at the database level.
• HTTPS-only TLS 1.3 control plane.

Repo moved from my personal account to its own org at https://github.com/certctl-io/certctl. Landing page at https://certctl.io. Subreddit at r/certctl if you want to follow along.

Just launched on Product Hunt today, if the project's been useful or you'd like to see it stick around, an upvote during the 24-hour window helps a lot: https://www.producthunt.com/products/certctl?launch=certctl

Still solo. Still bootstrapped. No funding, no plans for funding. Built this because the 47-day reality is going to hit a lot of teams hard and the OSS layer for fleet-wide cert lifecycle management is thin. Happy to answer questions, take feedback, or get told things are wrong.

Heads up. Let's Encrypt paused all production + staging issuance while they investigate a potential incident.

The TLDR:

• New certs and renewals are failing right now
• Existing certs are unaffected — your sites stay up
• Turn off your retry loops. Rate limits will bite hard the second issuance resumes

Status page: https://letsencrypt.status.io/

LE flagged this as "potential" - they halt preemptively whenever something looks off, so this could clear in an hour or run longer.

A month ago I posted certctl here and got useful feedback, especially around network-appliance deployment, intermediates and client cert key usage, and the lack of step-by-step guides. Some of that's been addressed, some is still open.

https://certctl.io

The biggest shift: certctl now ships three enrollment-protocol servers.

RFC 8555 ACME server with RFC 9773 ARI. cert-manager, certbot, lego, and acme.sh can issue against certctl directly. Two modes per certificate profile: trust_authenticated for east-west service-mesh certs, and challenge with full HTTP-01 / DNS-01 / TLS-ALPN-01 validation.

RFC 8894 SCEP server with native Microsoft Intune challenge dispatch and per-profile dispatch. ChromeOS, Intune, and per-fleet RA-cert plus challenge-password setups all supported on one endpoint.

RFC 7030 EST server for HTTPS-based PKCS#10 enrollment: 802.1X / Wi-Fi auth, MDM IoT, FreeRADIUS.

Multi-level CA hierarchy is now a first-class managed primitive.

Issuer connectors: 5 → 12. Added HashiCorp Vault PKI, AWS Private CA, Google CAS, DigiCert CertCentral, Sectigo, GlobalSign, EJBCA, and Entrust. ADCS still isn't shipped; a GitHub issue with your specific protocol mode would help prioritize it.

Target connectors: 3 → 15. Added Caddy, Traefik, Envoy, Postfix/Dovecot, Windows Cert Store, Java Keystore, Kubernetes Secrets, AWS ACM, Azure Key Vault, and SSH (agentless via SFTP). F5 BIG-IP via iControl REST is the first network-appliance target via the proxy-agent pattern. Palo Alto (PAN-OS XML), FortiGate (FortiOS REST), and Citrix ADC (NITRO REST) are next on the roadmap, all free V2 work under BSL.

Two-person approval for high-stakes issuance via profile-level RequiresApproval=true. Self-approval is refused.

HSM-ready signer abstraction. FileDriver shipped. PKCS#11, cloud KMS, and SSH-CA drivers slot in next.

Cloud discovery for AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager. Plus existing agent filesystem scans and network CIDR scans.

Notifiers: 2 → 6 with Slack, Teams, PagerDuty, and OpsGenie added. Per-policy severity routing. Default expiry thresholds T-30 / T-14 / T-7 / T-0.

HTTPS-only control plane on TLS 1.3. Immutable audit trail.

License is still BSL 1.1, free to self-host, no paid tier. Auto-converts to Apache 2.0 in 2076.

Try it

 git clone https://github.com/certctl-io/certctl.git
 cd certctl && docker compose -f deploy/docker-compose.yml up -d
 open https://localhost:8443

Still alpha for production. Actively maintained, shipping weekly. Open an issue if something breaks.

certctl is a self-hosted platform that automates the entire TLS certificate lifecycle, from issuance through renewal to deployment, with zero human intervention. It works with any certificate authority, deploys to any server, and keeps private keys on your infrastructure where they belong. Free, source-available under BSL 1.1, covers the same lifecycle that enterprise platforms charge $100K+/year for.

The CA/Browser Forum's Ballot SC-081v3 caps public TLS certificates at 200 days by March 2026, 100 days by 2027, and 47 days by 2029. At 47-day lifespans, a team managing 100 certificates is processing 7+ renewals per week, every week, forever. Manual workflows stop being a choice.

Certificate lifecycle tooling has historically split into two camps. Enterprise platforms charge six-figure annual licenses, take months to deploy, and bill professional-services hours at $250 to $400 per hour to write integration code that should ship with the product. Single-purpose tools (certbot, cert-manager, acme.sh) handle one slice of the problem and leave the operator to glue the rest together. certctl fills the gap — full lifecycle automation, self-hosted, free, CA-agnostic, target-agnostic. If you're stitching together certbot cron jobs across a fleet, manually renewing certs, or writing custom Adaptable scripts to bridge a commercial CLM platform to your actual infrastructure, certctl replaces all of that.

Try it

 git clone https://github.com/certctl-io/certctl.git
 cd certctl && docker compose -f deploy/docker-compose.yml up -d
 open https://localhost:8443

Quick update for anyone who saw the earlier post about the 47-day cert cliff and certctl. The two connectors that were stubbed in that post (F5 BIG-IP and IIS) have shipped end to end. Plus a lot of other capability landed that's relevant if you're managing certs across mixed network infrastructure.

What you can do now:

Rotate certs across F5 BIG-IP, IIS, NGINX, Apache, HAProxy, Caddy, Traefik, Envoy, Windows Cert Store, Java keystore, Kubernetes Secrets, AWS ACM, Azure Key Vault, SSH known-hosts, and Postfix from one place. Fifteen target types in one Go binary, no plugins or scripts.

Issue from twelve CAs natively: Let's Encrypt and any ACME CA via a built-in client, an embedded ACME server you can point cert-manager / certbot / lego at directly, a built-in local CA with sub-CA mode for chaining under an existing enterprise root, step-ca, Vault PKI, EJBCA, AWS ACM PCA, Google CAS, DigiCert, Sectigo, GlobalSign, Entrust, plus an OpenSSL / shell-script adapter for anything custom.

Run your own SCEP server (RFC 8894). Useful for network gear that speaks SCEP for cert enrollment: Cisco IOS XE, Juniper Junos PKI, ASA, FTD, ChromeOS, plus most MDM-managed mobile fleets. Native Microsoft Intune challenge dispatch with replay protection. Per-profile dispatch so a corporate-laptop fleet and an IoT-sensor fleet share one endpoint with their own RA certs and challenge passwords.

Run your own ACME server (RFC 8555 + RFC 9773 ARI). Point cert-manager, certbot, or lego at it for internal services and they'll issue through certctl's policy and audit pipeline instead of a public CA. Two operating modes per profile: a public-trust-style mode with full HTTP-01 / DNS-01 / TLS-ALPN-01 validation, or a trust_authenticated mode where the JWS-authenticated client is already the proof of identity (useful for east-west service mesh certs where there's nowhere meaningful to mount HTTP-01).

Run your own EST server (RFC 7030) for HTTPS-based PKCS#10 enrollment: 802.1X / Wi-Fi authentication, IoT device enrollment.

Build multi-level CA hierarchies in certctl directly: root to intermediate to issuing CA chains, name constraints and path-length enforcement on every CA, end-to-end RFC 5280 path validation. Useful if you want certctl to be where your enterprise PKI lives, or for per-business-unit name-constrained sub-CAs without standing up a separate ADCS forest.

Require human approval before high-stakes certs issue. Flag a profile as RequiresApproval, the request lands in a queue, a non-requester approves, the scheduler dispatches. Two-person integrity at the service layer.

Get expiry alerts at configurable thresholds (default T-30/14/7/0) routed to email, Slack, Teams, PagerDuty, OpsGenie, or webhook. Immutable audit trail for every cert action. Network scanner finds certs you forgot about by probing CIDR ranges via TLS handshake.

The proxy-agent pattern from the original post still applies for network appliances: the agent doesn't run on the firewall, switch, or load balancer itself. It runs on a Linux host or container in the same network zone and pushes certs to the device via the device's API. F5 and IIS are the first two appliance connectors. Palo Alto via PAN-OS XML, FortiGate via FortiOS REST, and Citrix ADC via NITRO REST are next on the roadmap, same pattern, all free V2 work under BSL.

Where this ends up:

If your fleet is just one or two NGINX boxes, this is more orchestration than you need. Where it earns its keep is mixed environments with load balancers, web servers, network appliances, Java backends, and a mix of internal and external CAs all needing the same rotation cycle.

Try it

 git clone https://github.com/certctl-io/certctl.git
 cd certctl && docker compose -f deploy/docker-compose.yml up -d
 open https://localhost:8443

BSL 1.1 license, free to self-host. https://certctl.io

Treat as alpha for production. Lab and dev testing reports filed as GitHub issues are the most valuable feedback right now, especially on the F5 connector if you have a non-prod BIG-IP to point it at.

previous post

https://certctl.io

Every commercial CLM platform ships a control plane that natively integrates with maybe 60% of what the customer actually runs. The other 40%, the load balancers, the app servers, the in-house systems, the regional CAs, the niche issuance protocols, gets bridged via custom plugin frameworks. Those plugins exist *because the platforms didn't ship native connectors*. They get written by professional-services architects on the vendor's payroll, billed back to the customer at $250–$400/hr, hundreds of hours in year one alone, on top of a six-to-seven-figure license. The job titles vary by vendor. Solutions Architect, Implementation Architect, Accelerator Architect, Digital Trust Architect, but the work is identical: write the integration the platform should have shipped with.

Quick update for anyone who saw the earlier post about Exchange cert rotation with certctl. The IIS deployment piece that was on the roadmap then has shipped, so the setup is meaningfully simpler now.

What's new:

certctl has a native IIS target connector. Two modes. Local mode runs PowerShell on a Windows agent installed on the box. WinRM mode lets a proxy agent on a Linux jump host connect to your Windows servers remotely, useful if you don't want agents on Exchange itself. Either way, it imports the cert via Import-PfxCertificate to the configured Windows cert store, updates the IIS binding via New-WebBinding + AddSslCertificate, and verifies the binding took via Get-WebBinding. Snapshots the existing thumbprint before the swap and rolls back to it on failure. No external script needed for the IIS-side cert install.

What still needs a post-deploy script:

For Exchange specifically, the cert still needs binding to the Exchange services (IIS, SMTP, IMAP, POP) via Enable-ExchangeCertificate. Plus connector TLS updates via Set-SendConnector / Set-ReceiveConnector if you've got hybrid TLS. That's the part certctl doesn't try to automate, because Exchange's cert binding model is its own thing. Services keyed differently from the IIS bindings, hybrid migration semantics, the cmdlets are Exchange-specific. Point a post-deploy script at the new cert thumbprint and let it run the Exchange cmdlets.

Same caveat as before:

The federation / OAuth self-signed certs are still a different beast. AD replication + Entra registration + DNS TXT timing that no external tool fully automates. WinACME doesn't either. Plan a manual window for those.

Where this ends up:

If your Exchange box is the only thing you're managing certs for, WinACME or CertifyTheWeb still does fine and has Exchange-specific automation built in. certctl earns its keep when you're managing Exchange + a bunch of other stuff (web servers, load balancers, Java keystores, AWS or Azure-side certs, network appliances) and you want one tool with one dashboard tracking everything. Especially if you've got mixed CAs, internal vs external.

For the hybrid HCW question that came up last time: same answer. If the domain names on the cert aren't changing between renewals, you don't need to re-run HCW. The Exchange Online connectors are keyed on domain names, not cert thumbprints. Renewal with the same SANs just needs the new cert bound on-prem.

Docker Compose, BSL 1.1 license, free to self-host.

previous post

Self-hosted certificate lifecycle platform with NGINX as a first-class deployment target. https://certctl.io

Every commercial CLM platform ships a control plane that natively integrates with maybe 60% of what the customer actually runs. The other 40%, the load balancers, the app servers, the in-house systems, the regional CAs, the niche issuance protocols, gets bridged via custom plugin frameworks. Those plugins exist *because the platforms didn't ship native connectors*. They get written by professional-services architects on the vendor's payroll, billed back to the customer at $250–$400/hr, hundreds of hours in year one alone, on top of a six-to-seven-figure license. The job titles vary by vendor. Solutions Architect, Implementation Architect, Accelerator Architect, Digital Trust Architect, but the work is identical: write the integration the platform should have shipped with.

The NGINX flow: agent on the box picks up a deployment job, writes the cert and key to disk, runs nginx -t to validate, then triggers a graceful reload. If nginx -t fails, the deploy aborts before reload and the previous cert keeps serving.

Cert sources: Let's Encrypt and any ACME CA via a built-in client, an embedded ACME server (RFC 8555 + RFC 9773 ARI) for pointing internal services at directly, a built-in local CA (with sub-CA mode for chaining under an existing enterprise root), step-ca, Vault PKI, EJBCA, AWS ACM PCA, Google CAS, DigiCert, Sectigo, GlobalSign, Entrust, plus an OpenSSL / shell-script adapter for anything custom.

Agent-based: private keys never leave the box. ECDSA P-256 keys generated locally on each NGINX server, CSRs submitted to the control plane, signed certs returned and deployed.

The same agent supports Apache, HAProxy, Caddy, Traefik, Envoy, IIS, Windows Cert Store, Java keystore, Kubernetes Secrets, AWS ACM, Azure Key Vault, SSH, Postfix, F5 BIG-IP alongside NGINX. Fifteen target types in one Go binary.

Renewal policies trigger automatically on configurable thresholds. Expiry alerts at T-30/14/7/1 days to email, Slack, Teams, PagerDuty, OpsGenie, or webhook. HTTPS-only control plane, TLS 1.3 pinned, fail-closed startup gate. PostgreSQL backend, React dashboard, REST API, CLI.

Quickstart on the website. 60 seconds to a seeded demo.

Try it

git clone https://github.com/certctl-io/certctl.git
cd certctl && docker compose -f deploy/docker-compose.yml up -d
open https://localhost:8443

BSL 1.1 license. Free to self-host and modify, you just can't resell as a hosted service. Every feature ships free under BSL.

Treat as alpha for production. Lab and dev testing reports filed as GitHub issues are the most valuable feedback right now.

previous post

Self-hosted certificate lifecycle platform. Issuance, renewal, deployment, revocation, discovery from one place. https://certctl.io

Every commercial CLM platform ships a control plane that natively integrates with maybe 60% of what the customer actually runs. The other 40%, the load balancers, the app servers, the in-house systems, the regional CAs, the niche issuance protocols, gets bridged via custom plugin frameworks. Those plugins exist *because the platforms didn't ship native connectors*. They get written by professional-services architects on the vendor's payroll, billed back to the customer at $250–$400/hr, hundreds of hours in year one alone, on top of a six-to-seven-figure license. The job titles vary by vendor. Solutions Architect, Implementation Architect, Accelerator Architect, Digital Trust Architect, but the work is identical: write the integration the platform should have shipped with.

Runs ACME (RFC 8555 + RFC 9773 ARI), SCEP (RFC 8894 with Microsoft Intune challenge dispatch), and EST (RFC 7030) as native server endpoints. ACME server has two per-profile auth modes: full HTTP-01 / DNS-01 / TLS-ALPN-01 validation for public-trust-style use, or trust_authenticated for internal PKI where the JWS-authenticated client is already the proof of identity.

Multi-level CA hierarchy as a first-class primitive: root to intermediate to issuing CA chains, name constraints and path-length enforcement on every CA, RFC 5280 path validation. Approval-workflow primitive on certificate profiles for high-stakes issuance: a RequiresApproval flag gates issuance behind a non-requester approval.

Twelve native CA connectors (DigiCert, Sectigo, GlobalSign, Entrust, AWS ACM PCA, Google CAS, Vault PKI, EJBCA, ACME upstream, OpenSSL / custom-CA shell adapter, step-ca, built-in local CA). Fifteen native deployment targets (NGINX, Apache, HAProxy, Caddy, Traefik, Envoy, IIS, Windows Cert Store, Java keystore, Kubernetes Secrets, AWS ACM, Azure Key Vault, SSH known-hosts, Postfix, F5 BIG-IP). Six notification channels (email, Slack, Teams, PagerDuty, OpsGenie, webhook). All in a single Go binary.

S/MIME emailProtection EKU wired end to end. PKCS12 export endpoint. HTTPS-only control plane with TLS 1.3 pinned and a fail-closed startup gate. PostgreSQL backend, React dashboard, CLI, MCP server.

Quickstart on the website. 60 seconds to a seeded demo environment.

BSL 1.1 license, free to self-host and modify, you just can't resell it as a hosted service. No paid tier, every feature ships free under BSL.

Treat as alpha for production. Lab and dev testing reports filed as GitHub issues are the most valuable feedback right now.