Fakecrypt

A local-first desktop workspace for creating and managing certificates.

Fakecrypt helps you build certificate chains, inspect certificate details, and keep private keys under your control on your own device. The app works offline and does not send your certificate data to a remote service.

Screenshots

Unlock your local vault

Set a master password, unlock your vault, or restore it from an encrypted backup.

Manage certificates

Create or import certificates, search and filter your inventory, and inspect certificate details and chains.

Features

• Create certificate chains: create root and intermediate authorities, plus server and client certificates issued by your local authorities.
• Import and export: import certificates with their private keys. Export a single certificate as DER .crt, a certificate and available issuer chain as PEM or PKCS#7, a server/client certificate with its private key as password-protected PKCS#12, or an available CSR.
• Inspect and organize: review certificate subjects, issuers, validity dates, fingerprints, public-key details, and chain information. Search by name or issuer and filter by certificate type.
• Protect private keys: unlock the local vault with a master password. The app encrypts private keys at rest and provides a recovery key for regaining access.
• Back up and restore: create password-protected encrypted backups and restore a vault from a backup.
• Work offline: certificate management runs locally on your device; no remote service is required.

Common use cases

• Private and self-hosted services: issue TLS server certificates for an intranet, homelab, internal API, or other service whose clients you manage.
• Development and test environments: create short-lived certificates for local apps, staging systems, and test DNS names or IP addresses.
• Two-way SSL (mutual TLS or mTLS): issue client certificates for software or users when a server is configured to request and verify client certificates. Both sides authenticate with certificates. This can include private APIs, B2B gateways, or AS4/ebMS3 endpoints that require TLS client authentication. Fakecrypt creates the certificate; the server's TLS and authorization policies must be configured separately.
• Certificate inventory: keep local records of authorities, server/client certificates, validity dates, fingerprints, and issuer chains.

Using Fakecrypt with private servers

Fakecrypt creates and exports certificates. It does not run your server, install certificates, configure TLS, or distribute trust to clients.

1. Create a root authority. Optionally create an intermediate authority beneath it, then use an issuing authority to create a server certificate. An intermediate authority created by Fakecrypt cannot issue further authorities.
2. Enter the server's real names. Add every DNS name and IP address clients will use as a Subject Alternative Name (SAN), for example api.example.test or 192.0.2.10. A matching Common Name (CN) alone does not replace the SAN required for normal hostname verification.
3. Configure the server with the leaf certificate and its private key. The PEM export contains the selected certificate followed by its available issuer chain, but does not contain a private key. PKCS#12 (.p12) can bundle a server or client certificate, its private key, and the available chain; protect its export password and transfer the file securely. A DER .crt contains only one certificate. PKCS#7 (.p7b) contains the certificate and available issuers, not a private key and not a trust decision.
4. Serve the chain correctly. Configure the TLS server to present its leaf certificate and required intermediate certificate(s). Clients normally already have the root CA as their trust anchor, so the server usually does not need to send the root certificate. Follow the server software's format and chain-file requirements.
5. Configure client trust. On each managed client, trust the public root CA certificate as described below. Keep CA private keys private; do not copy a root or intermediate CA key onto the server.

For two-way SSL (mTLS), configure the client with its client certificate and private key, and configure the server to request and verify that certificate.

The server must trust the issuing CA and apply its own authorization rules; the client must separately trust the server's certificate chain. A client certificate does not grant access by itself. Importing a PKCS#12 file into a browser or client may install a client identity; it is different from trusting a CA.

Two-way SSL with AS4, ebMS3, and B2B gateways

For an AS4 integration that uses two-way SSL/TLS client authentication, create a client certificate and, if the AS4 client supports it, export it as a password-protected PKCS#12 file for that client to use as its identity. Configure the AS4 gateway or remote endpoint to trust the issuing CA and map the authenticated certificate to the relevant partner or integration account. Follow the endpoint operator's certificate exchange and trust-store instructions.

TLS client authentication is separate from AS4 message-level signing and encryption. Some AS4 profiles require dedicated message-signing or message-encryption certificates, particular certificate policies, or separate keys for each role. Fakecrypt issues client certificates with the clientAuth extended key usage; it does not run an AS4 service, configure ebMS3, or guarantee that a certificate meets a specific partner's AS4 profile. Confirm the required key usage, algorithms, subject fields, validity, and certificate exchange process with the trading partner before using a certificate beyond a test or sandbox environment.

Browser trust and certificate-chain validation

For a normal private-CA setup, add only the public root CA certificate to the browser's or operating system's trusted certificate authorities. Do not import the root CA's private key, and do not mark each server certificate as a trusted authority. Verify the root certificate's fingerprint through a trusted separate channel before adding it. Trusting a root CA allows clients to trust certificates that chain to it, so only install roots you control and intend to trust.

The browser validates a path from the server's leaf certificate, through any intermediate certificates, to a root CA it already trusts. It also checks certificate dates, signatures, permitted usage, and whether the requested DNS name or IP address matches a SAN. Trusting the root alone is not enough if the server fails to present a required intermediate, or if the certificate does not match the address in the browser's URL.

A chain export and a trust store serve different purposes:

• A PEM or PKCS#7 chain export carries the certificate and available issuers so it can be provisioned on a server or inspected. Exporting it does not install certificates or make them trusted.

• A trust store (such as the operating system's certificate store, a browser's certificate database, or an application's configured CA bundle) records the authorities that client software accepts as trust anchors. Configure the trust store used by the specific browser or application; they do not all necessarily use the same store.

Browser and operating-system trust-store behavior varies by platform and policy. Follow the official instructions for the exact browser and device you manage. Public websites still need certificates trusted by the public browser ecosystem; a locally created private CA does not become publicly trusted.

Security notes

• Treat a private CA's key as highly sensitive. Anyone who obtains it may issue certificates that clients trusting that CA could accept. Keep it protected and offline where practical, and create encrypted backups.
• A PKCS#12 export contains a private key. Use a strong export password and a secure transfer channel. A .key export is unencrypted and should be handled accordingly.
• Installing a private root CA changes trust on that device. Do this only on devices you administer and remove the root when it is no longer needed.
• Fakecrypt stores private keys encrypted at rest in its local vault, but it does not install roots, configure browser or application trust stores, deploy server certificates, or manage your servers.

Supported platforms

The project is configured to package a Windows installer and Linux AppImage and .deb packages. Download availability depends on which builds are published with the project's GitHub releases.

Run from source

From the electron-app directory, install dependencies and start the desktop app in development mode:

npm install
npm run dev

Useful project checks:

npm run typecheck
npm test
npm run build

Release builds

GitHub Actions builds the desktop application with npm run build before packaging the Windows installer and Linux AppImage and .deb packages. Packaging scripts require the compiled out/ files; they do not compile the application themselves.

The release workflow passes --publish never to electron-builder because the subsequent GitHub CLI step uploads the packages to the published release.

Built with

Fakecrypt is built with Electron, React, and TypeScript. It uses a local SQLite database and a bundled OpenSSL runtime for certificate operations.