← → or click nav
github.com/johanhedin/nanoca
Written by Johan Hedin
Language: Bash Shell
License: MIT
Open-source project
nanoca

A small, file-based X.509 Certificate Authority with support for smart cards — no servers, no databases, just files.

🐚 Bash 🔐 X.509 / PKI 💳 Smart Cards 🗂 File-Based
Overview

What is nanoca?

nanoca is a lightweight Bash script that implements a fully functional X.509 Certificate Authority for use on home or private networks. It wraps openssl to manage the full certificate lifecycle — creation, signing, revocation, and CRL generation.

CA
Certificate Authority — the trusted root that issues and signs certificates.
CSR
Certificate Signing Request — a PEM file created by the requester and sent to the CA for signing.
CRT
Certificate — a signed PEM file produced by the CA from a CSR.
CRL
Certificate Revocation List — a CA-issued list of revoked certificates.
Design

Architecture — Files All The Way Down

A CA is nothing more than a directory. Each CA lives entirely in its own folder — portable, auditable, and offline by default.

📁 CA Directory
ca.key · ca.crt · ca.srl
📄 CSR
Requester-generated
Signed CRT
Stored in directory
📋 CRL
Updated on revocation

Multi-CA support

Because each CA is self-contained in a directory, you can maintain as many CAs as needed by simply using different directories. Switch between them with cd.

# Typical CA directory layout
myca/
  ├── ca.key         # CA private key
  ├── ca.crt         # CA certificate
  ├── ca.srl         # Serial counter
  ├── server.crt     # Issued certificate
  └── ca.crl         # Revocation list
Capabilities

Core Features

🏗

Create a CA

Spin up a brand-new Certificate Authority in an empty directory. Parameters are gathered interactively — no config files to write.

📝

Generate CSRs

Create Certificate Signing Requests for servers, clients, or any entity that needs a certificate, including SAN support.

✍️

Sign Certificates

Sign CSRs with your CA key to produce trusted X.509 certificates accepted by browsers and OS trust stores.

🚫

Revoke Certificates

Mark any previously issued certificate as revoked — a CA-internal operation tracked in the certificate database.

📋

Issue CRLs

Generate and distribute Certificate Revocation Lists so clients can check whether a certificate has been revoked.

💳

Smart Card Support

Generate CSRs using PKCS#11-enabled hardware tokens via pkcs11_engine and p11-kit, keeping private keys in hardware.

CLI Reference

Command Reference

nanoca create Initialise a new CA in the current directory. Prompts for all CA parameters interactively.
nanoca list List all certificates issued by this CA, including their serial numbers and status.
nanoca sign <csr> Sign a CSR with the CA key and produce a signed X.509 certificate file.
nanoca re-sign <crt> Re-sign an existing certificate — useful for renewing a certificate that is about to expire.
nanoca recreate-crl Recreate and update the Certificate Revocation List (CRL) from the current revocation database.
nanoca revoke <crt> Revoke a previously issued certificate (CA-internal operation, updates the database).
Getting Started

Typical Workflow

01

Create a new CA

Make an empty directory and run nanoca create. Answer the interactive prompts for country, organisation, and validity period.

02

Trust the CA certificate

Import ca.crt into the OS or browser trust store of every device on your network that should trust certs signed by this CA.

03

Generate a CSR for each service

Run nanoca gencsr <hostname> on the target host (or with a PKCS#11 token for hardware-backed keys).

04

Sign the CSR with your CA

cd into the CA directory and run nanoca sign <hostname.csr>. The signed certificate is written back to the CA directory.

05

Deploy & maintain

Copy the certificate to the service. Revoke with nanoca revoke and publish fresh CRLs as needed.

Advanced Feature

Smart Card & PKCS#11 Support

nanoca supports CSR generation using PKCS#11 hardware tokens (YubiKeys, smart cards, HSMs). The private key never leaves the device — only the CSR is exported and signed by the CA.

Requirements

  • OpenSSL compiled with pkcs11_engine support
  • p11-kit installed and configured
  • A compatible hardware token (YubiKey, OpenSC-compatible card)
🔑 Hardware-backed keys 🛡 Non-exportable private key 💳 YubiKey compatible
# CSR with a PKCS#11 token
nanoca gencsr --pkcs11 myservice

# Private key stays on the token
# Only myservice.csr is produced

nanoca sign myservice.csr
# → myservice.crt

Why hardware tokens?

If an attacker compromises the machine, they cannot steal the private key — it physically cannot leave the token. Ideal for VPN clients, SSH user certs, and admin workstations.

Applications

Ideal Use Cases

🏠

Home Lab TLS

Issue trusted HTTPS certificates for self-hosted services — NAS, Proxmox, Home Assistant — without self-signed certificate warnings.

🏢

Private Internal Networks

Secure internal microservices, APIs, and dashboards with mTLS using a CA that lives entirely within your network perimeter.

🔒

VPN Client Certificates

Issue client authentication certificates for OpenVPN or WireGuard, replacing or augmenting pre-shared keys with PKI.

🧪

Dev & Testing Environments

Quickly spin up a CA for local development environments. Multiple isolated CAs can co-exist for different projects or teams.

Under The Hood

Technology Stack

nanoca intentionally avoids heavy dependencies. Everything runs on tools already present on any modern Linux system.

🐚 Bash Core scripting runtime. No Python, Ruby, or Go required.
🔐 OpenSSL All cryptographic operations — key gen, signing, CRL.
🔧 awk Text processing and parsing of OpenSSL output.
📂 ls / cat / wc File listing, content display, and certificate counting.
💳 p11-kit Optional — PKCS#11 bridge for smart card support.

Zero external dependencies for basic use

As long as bash and openssl are available, nanoca works. The PKCS#11 integration (p11-kit) is purely optional and only needed when using hardware tokens.

Summary

Why nanoca?

Strengths

  • Zero installation — just copy the script
  • No database, no server, no daemon to manage
  • Fully offline-capable — air-gapped friendly
  • Multiple CAs via simple directory layout
  • Hardware token support for strong key protection
  • Easy to audit — it's just a bash script
  • Perfect for home labs and private networks

Limitations / Considerations

  • Not designed for large-scale enterprise PKI
  • No web UI — CLI only
  • PKCS#11 requires correct OpenSSL engine support
  • No ACME / automatic renewal protocol
  • Manual CRL distribution (no OCSP responder)
  • Requires Linux/macOS (Bash environment)
github.com/johanhedin/nanoca Shell MIT License Home & Private Networks