What you get
Register once and the server assigns you a userid. With the userid k3x9q2mf you get:
- A trusted wildcard certificate for
*.k3x9q2mf.07151129.xyz. - DNS names under that wildcard that resolve to whatever IP address you encode into them (the slug and double dashes are required):
Name Resolves to web--192-168-1-1.k3x9q2mf.07151129.xyz192.168.1.1web--2400-a-b--ff.k3x9q2mf.07151129.xyz2400:a:b::ff
Together they give any machine on a private network an HTTPS name that browsers and clients accept.
How it works
- You submit an ed25519 public key and receive a userid.
- Your machine generates a certificate key and a CSR locally.
- The server orders the certificate from Let's Encrypt over a DNS-01 challenge. It stores the challenge record and answers it from its own authoritative DNS server for
07151129.xyz. - You receive the certificate chain.
The certificate key stays on your machine and the server never sees it. Since the server is authoritative for the domain, no API credentials for an external DNS provider are involved.
Quick start
# generate a key and claim a userid
realssl register --server https://07151129.xyz
# obtain the certificate, write cert.pem and cert.key
realssl cert
# check the account and the certificate status
realssl whoami
The server returns the stored certificate as long as it has more than 7 days of validity left, so renewal is safe to run from cron:
17 4 * * * /usr/local/bin/realssl cert --out /etc/ssl/realssl
Each account may trigger up to 5 real issuances per day. Runs that reuse the stored certificate do not count against that limit.
Where people use it
- Self-hosted services on a homelab network.
- Development machines reachable only over a LAN or a VPN.
- Admin interfaces on a NAS, a router, or other embedded devices.
- Internal staging environments.
- Short-lived environments started by CI.
They share the same requirement: a certificate that browsers and clients accept, on a machine that has no public DNS name and no DNS provider credentials to spare.