Franco PKI — FAQ

Franco PKI is a complete certificate authority built from scratch: it issues and manages the digital certificates that systems use to prove who they are and encrypt their traffic, with its keys protected in security hardware.

What is a PKI?

A PKI (public key infrastructure) is the system that issues and manages digital certificates: ID cards for computers. The padlock your browser shows on an HTTPS site exists because a PKI gave that site a certificate.

  • A certificate says "this server is bank.com" and carries the signature of whoever issued it.
  • The certificate authority (CA) is the signer. If you trust the CA, you trust what it signs.
  • The CA's private key is the crown jewel: with it, anyone could issue fake certificates. That is why it lives in an HSM, a hardware device that signs without ever letting the key out.
  • Revoking cancels a certificate before it expires, for example when its key is stolen. CRLs and OCSP are how others check whether a certificate is still valid.

Companies run internal PKIs for their servers, VPNs, Wi-Fi, signed email and devices. Well-known products are Microsoft ADCS, EJBCA and HashiCorp Vault.

What is Franco PKI?

It is a complete enterprise PKI, designed and built by me, covering what products like ADCS or EJBCA offer: CA hierarchies, issuing and revoking certificates, automated renewals and full auditing.

  • Who it is for: infrastructure and security teams that issue internal certificates and need control over who may request what.
  • How it is used: a web console, a documented REST API and ACME (the same protocol Let's Encrypt uses), so servers renew their own certificates.
  • The rule behind the design: the application never holds a CA's private key, not in memory, not in the database, not in logs. It asks the HSM to sign, and the HSM keeps the key.

What does it have?

The main features, by area:

AreaWhat it doesWhat it is good for
CA hierarchyRoots, subordinates, CAs signed by an external CA, cross-signingFitting into a company's existing PKI, or migrating from one to another
CA lifecycleRenewal and key rollover without breaking what was issuedReplacing an old key without reissuing thousands of certificates
IssuanceTemplates per certificate type, requests with approval, server-generated keysEach team requests only what it is allowed to
RevocationRevoke, suspend, bulk revoke; CRL and OCSP updated at onceReacting fast to an incident
AutomationACME (like Let's Encrypt), REST API with interactive docsServers renew on their own, no human in the loop
Identity and accessSSO with Microsoft Entra ID, roles and groups, custom roles, second factor for adminsUsing the company's accounts and limiting who does what
NotificationsExpiry and pending-request alerts by email and webhooks, editable messagesNo certificate expires without someone knowing
AuditHash-chained log, signed in the HSM, SIEM export, independent verifierProving nobody altered the log, not even a database admin
MonitoringPrometheus metricsAlerts if the HSM fails or a CRL is about to expire
Self-registrationSign-up with Google, approval, personal group, quotasOpening a demo to outsiders without risk to the real PKI

How is it built?

Franco PKI architecture Three ways in (people through the web console, servers through ACME, other systems through the REST API) reach one core, ca-api. The core requests signatures from the HSM, stores data in PostgreSQL and publishes CRL and OCSP. PostgreSQL exports the audit to the SIEM and metrics. requests signatures stores data publishes exports the audit People Servers Other systems ca-api (Go): the core HSM PostgreSQL Publication SIEM and metrics Web console with SSO ACME: they renew alone REST API with API keys Permissions, templates, issuance, revocation, ACME, notifications and audit Orchestrates everything, but never holds a CA private key Keeps the CAs' keys Signs; the key stays in Certificates and users Hash-chained audit log CRL and OCSP over HTTP Anyone can verify A copy of the audit outside Prometheus and alerts

Everything goes through the core (ca-api), which decides whether each request is allowed. When something must be signed, it asks the HSM: the CA's key never reaches the application.

What is it built with?

PartTechnology
BackendGo, hexagonal architecture (a core free of infrastructure dependencies)
DatabasePostgreSQL, least-privilege roles, audit log protected by triggers
HSMPKCS#11 (SoftHSM in development, through p11-kit), Azure Key Vault and Managed HSM
FrontendReact, TypeScript, TanStack Router and Query, Tailwind
IdentityOpenID Connect (Microsoft Entra ID, Google), API keys, TOTP
ProtocolsX.509, CRL, OCSP, ACME (RFC 8555), REST API with OpenAPI
ObservabilityPrometheus, syslog RFC 5424 to a SIEM
DeploymentDocker Compose, Coolify on a VPS, behind Cloudflare

How it is tested: unit tests, integration tests against a real HSM and database, and end-to-end browser tests with Playwright. Also static analysis, and a check that the application cannot touch the HSM's files.

How can I see it running?

← Back to projects