tlsx

A TLS library with automation. HTTPS by default through a light-weight library and/or CLI. Similar to mkcert.

Features

• 🔒 SSL Support (HTTPS by default)
• 0️⃣ Zero-Config & Zero-Setup HTTPS
• 🛠️ Configurable Library & CLI
• 🔀 Multi-domain Support
• 🏗️ Cross-platform System Trust Store Integration
• 🌐 ACME / Let's Encrypt (real certs + wildcards, zero dependencies)

Install

bun install -d @stacksjs/tlsx

# or, invoke immediately
bunx @stacksjs/tlsx
npx @stacksjs/tlsx

Please note, we are looking to publish this package to npm under the name tlsx.

Here's to hoping npm will release the name for us 🙏🏽

Get Started

There are two ways of using this reverse proxy: as a library or as a CLI.

Library

Given the npm package is installed:

import type { AddCertOptions, CAOptions, CertificateOptions, TlsConfig, TlsOptions } from '@stacksjs/tlsx'
import { addCertToSystemTrustStoreAndSaveCert, cleanupTrustStore, config, forge, generateCertificate, pki, removeCertFromSystemTrustStore, storeCertificate, tls } from '@stacksjs/tlsx'

// Generate a certificate for a single domain
const cert = await generateCertificate({
  domain: 'example.com',
  rootCA: existingCA,
  validityDays: 365,
})

// Generate a certificate for multiple domains
const multiDomainCert = await generateCertificate({
  domains: ['example.com', 'api.example.com', '_.example.com'],
  rootCA: existingCA,
  validityDays: 365,
})

// Generate a certificate with both primary domain and additional domains
const combinedCert = await generateCertificate({
  domain: 'example.com',
  domains: ['api.example.com', '_.example.com'],
  rootCA: existingCA,
  validityDays: 365,
})

// Store and trust the certificate
await addCertToSystemTrustStoreAndSaveCert(cert, rootCA.certificate)

// Remove a specific certificate
await removeCertFromSystemTrustStore('example.com')

// Remove a certificate with a specific name
await removeCertFromSystemTrustStore('example.com', {}, 'My Custom Certificate Name')

// Clean up all TLSX certificates from the system trust store
await cleanupTrustStore()

// Clean up certificates matching a specific pattern
await cleanupTrustStore({}, 'My Custom Pattern')

CLI

# Generate certificate for a single domain
tlsx secure example.com

# Generate certificate for multiple domains
tlsx secure -d "example.com,api.example.com,_.example.com"

# Generate certificate with primary domain and additional domains
tlsx secure example.com -d "api.example.com,_.example.com"

# Generate certificate with custom validity and organization
tlsx secure example.com --validity-days 365 --organization-name "My Company"

# Revoke a certificate for a domain
tlsx revoke example.com

# Revoke a certificate with a specific name
tlsx revoke example.com --cert-name "My Custom Certificate"

# Clean up all TLSX certificates from the system trust store
tlsx cleanup

# Clean up certificates matching a specific pattern
tlsx cleanup --pattern "My Custom Pattern"

# List all certificates
tlsx list

# Verify a certificate
tlsx verify path/to/cert.crt

# Show system configuration and paths
tlsx info

# Show all available options
tlsx secure --help

# Show version
tlsx version

Trusting the Root CA

# Install the local Root CA into the system trust store (mkcert-style, idempotent)
tlsx install

# Export it for another device: pem (default), der, or an Apple configuration profile
tlsx export-ca --format mobileconfig --out ~/Desktop/root-ca.mobileconfig

# Print the exact steps for a platform: macos, ios, windows, debian, rhel, android, linux-nss
tlsx trust-instructions --platform ios

# Remove the Root CA from the trust store again
tlsx uninstall

On Linux, install writes the CA anchor where the distribution reads it, /usr/local/share/ca-certificates with update-ca-certificates on Debian and Ubuntu, /etc/pki/ca-trust/source/anchors with update-ca-trust on the RHEL family, detected from /etc/os-release. NSS databases are still updated when a browser profile is present. This is what makes a headless server work: it has no browser profile, so the NSS-only path found nothing to update and reported success while trusting nothing.

export-ca covers the other machines on the network. One caveat is worth knowing before you debug the wrong thing: on iOS, installing the profile is only half the job, and full trust must then be enabled under Settings, General, About, Certificate Trust Settings. Until it is, Safari reports the certificate as invalid, which reads like a wrong certificate rather than a missing setting.

Details, including the per-store report installCA returns, are in the trust store docs.

ACME / Let's Encrypt

In addition to local, self-signed development certificates, tlsx ships a dependency-free ACME (RFC 8555) client that obtains and renews real, publicly-trusted certificates from Let's Encrypt — including wildcards via the DNS-01 challenge. It uses only node:crypto and the global fetch (no external libraries), generating P-256 keys, hand-building the CSR, and signing every request as an ES256 JWS.

By default it targets Let's Encrypt staging (untrusted, but un-rate-limited — ideal for testing). Pass staging: false (library) or --prod (CLI) for real, trusted certificates.

Challenge methods

• dns-01 — required for wildcard certificates (*.example.com). The

  client publishes a _acme-challenge.<host> TXT record via a DnsProvider (a built-in Porkbun provider is included; the interface is open for Route53/others). Set PORKBUN_API_KEY and PORKBUN_SECRET_KEY.

• http-01 — for non-wildcard domains. The client registers the challenge

  response in an Http01Store; a webserver listening on port 80 (e.g. rpx) serves GET /.well-known/acme-challenge/<token> from that store.

Library

import { obtainCertificate, PorkbunDnsProvider } from '@stacksjs/tlsx'

// Wildcard via DNS-01 (Porkbun), production cert:
const { certPem, keyPem, chainPem, fullChainPem, notAfter, accountKeyPem } = await obtainCertificate({
  domains: ['example.com', '_.example.com'],
  method: 'dns-01',
  dnsProvider: new PorkbunDnsProvider(), // reads PORKBUN_API_KEY / PORKBUN_SECRET_KEY
  email: 'admin@example.com',
  staging: false, // real cert; omit/true for Let's Encrypt staging
})
// Persist `accountKeyPem` to reuse the same ACME account next time.

// HTTP-01 (no wildcard) — wire the shared store into your :80 webserver:
import { defaultHttp01Store, Http01Store } from '@stacksjs/tlsx'

// in your :80 handler:
//   const keyAuth = defaultHttp01Store.handlePath(req.url)
//   if (keyAuth) return new Response(keyAuth)
const result = await obtainCertificate({
  domains: ['example.com'],
  method: 'http-01',
  email: 'admin@example.com',
  staging: false,
})

obtainCertificate returns { certPem, keyPem, chainPem, fullChainPem, accountKeyPem, notAfter }: the leaf certificate, its PKCS#8 private key, the intermediate chain, a leaf+intermediates bundle, the ACME account key (persist to reuse the account), and the certificate's expiry Date.

CLI

# Issue a wildcard cert via DNS-01 (Porkbun), production
PORKBUN_API_KEY=... PORKBUN_SECRET_KEY=... \
  tlsx acme:issue --domains "example.com,_.example.com" --method dns-01 --dir ./certs --prod

# Issue a single-domain cert via HTTP-01 (needs a webserver on :80), staging
tlsx acme:issue --domains example.com --method http-01 --dir ./certs

# Reuse/persist an ACME account key across runs
tlsx acme:issue -d example.com --method http-01 --dir ./certs --account-key ./acme-account.key

# Renew everything in a directory that expires within 30 days
tlsx acme:renew --dir ./certs --days 30 --prod

Output filenames (written into --dir): for a domain example.com the CLI writes example.com.crt (the full leaf+chain bundle) and example.com.key (plus example.com.chain.crt when an intermediate chain is present). A wildcard *.example.com is written as _wildcard.example.com.crt / _wildcard.example.com.key (mkcert/Let's Encrypt convention). tlsx acme:renew re-derives the domains from each certificate's SANs and rewrites the same files.

Configuration

tlsx can be configured using a tls.config.ts (or tls.config.js) file and it will be automatically loaded when running the tlsx command.

// tlsx.config.{ts,js}
import type { TlsConfig } from '@stacksjs/tlsx'

export default {
  domain: 'stacks.localhost',
  hostCertCN: 'stacks.localhost',
  caCertPath: path.join(os.homedir(), '.stacks', 'ssl', `tlsx.localhost.ca.crt`),
  certPath: path.join(os.homedir(), '.stacks', 'ssl', `tlsx.localhost.crt`),
  keyPath: path.join(os.homedir(), '.stacks', 'ssl', `tlsx.localhost.crt.key`),
  altNameIPs: ['127.0.0.1'],
  altNameURIs: ['localhost'],
  organizationName: 'stacksjs.org',
  countryName: 'US',
  stateName: 'California',
  localityName: 'Playa Vista',
  commonName: 'stacks.localhost',
  validityDays: 180,
  verbose: false,
} satisfies TlsConfig

Then run:

tlsx

To learn more, head over to the documentation.

Testing

bun test

Changelog

Please see our releases page for more information on what has changed recently.

Contributing

Please review the Contributing Guide for details.

Community

For help, discussion about best practices, or any other conversation that would benefit from being searchable:

Discussions on GitHub

For casual chit-chat with others using this package:

Join the Stacks Discord Server

Postcardware

"Software that is free, but hopes for a postcard." We love receiving postcards from around the world showing where tlsx is being used! We showcase them on our website too.

Our address: Stacks.js, 12665 Village Ln #2306, Playa Vista, CA 90094, United States 🌎

Sponsors

We would like to extend our thanks to the following sponsors for funding Stacks development. If you are interested in becoming a sponsor, please reach out to us.

• JetBrains
• The Solana Foundation

Credits

• Chris Breuer
• All Contributors

License

The MIT License (MIT). Please see LICENSE for more information.

Made with 💙