![\"\"](\"https:\/\/sickgaming.net\/blog\/wp-content\/uploads\/2026\/04\/make-a-private-ca-with-step-ca.jpg\")
<\/p>\n<\/p>\n
In this article you will learn how TLS (Transport Layer Security) and SSH (Secure SHell) use public\/private key-pairs to authenticate web servers you visit and linux machines you log in to. You will also learn how the TLS framework installed by default in mainstream web browsers fails to prevent MITM (Man In The Middle) attacks in critical ways. Then we will walk through setting up a private .FEDORA TLD (Top Level Domain), setting up your own private CA with the smallstep package, and using the acme-tiny package to issue certificates for a website under that private TLD.<\/p>\n
<\/span> <\/p>\n I will not cover setting up a simple “Hello World” website using your favorite web server packaged with Fedora. This needs to be up and running on HTTP to follow along. For this article, the website will be named hello.fedora.<\/p>\n Sadly, we will also explain how this does not completely solve the MITM problem – but this is already a big article. Click here<\/a> to skip the background and motivation and go directly to the HowTo.<\/p>\n While NSA director Admiral Bobby revealed that intel agencies were aware of two key, or public-key<\/a> cryptography since the 1960s, the first unclassified paper was published by Whitfield Diffie<\/a> and Martin E. Hellman<\/a> in 1976. In college, I remember playing with cryptosystems based on the knapsack problem<\/a>. These had various vulnerabilities. What revolutionized the field was publication of the RSA algorithm<\/a> in 1977. I vividly remember where I sat in the college library when I read the paper. There was some controversy over “you can’t patent algorithms”. However RSA patented their implementation (which is already protected by copyright – but that is another discussion). Yes, you can whip up a 1 line Perl implementation in a few minutes (we all did) – but a secure implementation that does not leak the private key through various side channels<\/a> is NOT trivial.<\/p>\n The original concept of public keys was to look up a recipient’s pubkey in a directory, and use it to encrypt a message that only the possessor of the corresponding private key can decrypt. This can also be used to authenticate<\/em> a correspondent via a protocol that proves they hold the corresponding private key. The basic idea is to encrypt a random token with a pubkey, the recipient decrypts the token and sends it back encrypted by your pubkey. The details are not trivial. The primary concern is MITM attacks. SSH and TLS support several widely accepted algorithms for authentication and key exchange.<\/p>\n If you think about it, that “directory” is all important. Suppose you have a “secure” phone app (without naming names) that uses a public directory to map telephone number to pubkey. Whoever runs that directory can return their own pubkey (likely a different one for each telephone number), decrypt the data, and send it on, re-encrypted to the real pubkey of the intended recipient (and the same for the other direction). I.e. – the classic MITM attack. This is why such secure applications usually provide a way to verify you have the real pubkey via an in-person meeting or alternate medium.<\/p>\n So how do you know the real pubkey for a secure (https) website? Websites provide a “certificate” saying “this pubkey is for these domain names” (and other information we are not concerned with here). Well, anyone can create such a certificate – in fact we will do so in this article – so how do you know it is truthful? The certificate is “signed” by a Certificate Authority (CA). Pubkeys can be used to sign data. For RSA, the basic concept is to compute a secure “hash” (e.g. SHA256) of the certificate data, and “decrypt” it using the private key of the CA. The signature can be verified by using the pubkey of the CA to “encrypt” the result, – which should match the hash of the signed data. RSA is nice in that decryption and encryption are symmetrical – verifying a signature<\/a> is the same operation as encrypting the signature to the owner of the privkey for the pubkey . So now, instead of every web user maintaining a private database of pubkeys for domain names, the browser has a list of trusted CAs which sign website certificates after verifying them in some way. In case a private key is compromised, CAs publish a Revocation List (which regular people rarely use) and TLS certificates always have an expiration date.<\/p>\n Note that CAs can certify data other than domain names, like the name of a company or individual. Commercial CAs generally charge a premium for this, but there are also non-profit CAs like cacert.org<\/a> that certify personal details via in-person meetings.<\/p>\n Regular Joes (“normies”) do not keep track of all this, so where does that “list of trusted CAs” come from? Well, there is a CA and Browser forum<\/a> with representatives from popular browser software makers and commercial CAs. They maintain a list of trusted CAs, and changes are voted on in public meetings with minutes published on their web page. Fedora installs this list in \/usr\/share\/pki<\/kbd>. Browsers may have their own copy. Users may add additional trusted CAs to \/usr\/share\/pki<\/kbd> or \/etc\/pki\/ca-trust<\/kbd> and browsers may have their own way of adding additional trusted CAs.<\/p>\n This all sounds well and good, BUT. The critical flaw could be called serial reliability<\/a>. The trusted CAs are trusted for any domain. So any trusted CA (including any you add) can forge a certificate for any website. DNS vulnerabilities (cache poisoning and such) are beyond the scope of this article. But we will set up a private CA which you could use to forge any website cert and fool anyone you convince to trust your CA (and can hack their DNS and\/or IP routing). The cabforum is very careful about their list. As part of hostilities, forum CAs stopped certifying .RU domains (ISO TLD for Russia). Russia promptly put up their own national CAs, which anyone can add to their browser trust store. Normies were warned NOT to do this, as the Russian CAs could then forge certs for any domain. But a moment’s thought reveals that ANY cabforum CA could go “rogue” and do the same thing. It only takes one.<\/p>\n There are solutions to this blanket trust problem, but that will require another article. <\/p>\n For illustration, we will create the .FEDORA TLD. Everyone following along will create a different instance of that TLD, and hostnames under .FEDORA will resolve to different IPs (or NXDOMAIN) depending on whose DNS server you point that TLD at. This was the motivation for creating ICANN<\/a> – a worldwide centralized DNS root (list of official TLDs). This provides a consistent namespace at the expense of absolute power (to cancel domains and TLDs) invested in ICANN. Before ICANN, admins all maintained their own DNS root, and periodically updated (manually or automatically) nameservers for well known TLDs like .COM etc. ISO defined an official list of TLDs, including country code TLDs (like .US). That worked well. The problem came with more obscure TLDs like .FREE. Companies trying to be “cool” were upset that not all customers got the same IPs for .FREE hostnames. Also admins liked having “someone else” maintain the DNS root. Hence, ICANN. There is also Opennic<\/a> which likewise has “someone else” (volunteers) maintain a root zone, with fallback to ICANN, and has its own “forum” (existing TLDs vote) to approve new TLDs.<\/p>\n Here is a bind zonefile for .FEDORA:<\/p>\n But that was a bait and switch. Setting up DNS for a private TLD is its own article. If you know how to add such a zone to your self hosted DNS – then do so. For the rest, we’ll use an even older hostname\/IP map that predates DNS: as root, edit the file \/etc\/hosts<\/kbd> on the system you will run step-ca on and append these lines:<\/p>\n Replace 192.168.100.31 with the IP of the system you are trying all this out on. Step-ca must be able to lookup the hello.fedora<\/kbd> hostname it is certifying to do the ACME protocol. We will use the \/.well-known\/acme-challenge<\/kbd> method, which does not require real DNS. The system you run acme-tiny<\/kbd> on also needs to lookup ca.fedora<\/kbd>.<\/p>\n If the smallstep package is still under review<\/a> when you read this, you’ll need to enable the copr repo<\/a> (otherwise skip this step):<\/p>\n First, we need to create our root CA. In production, this should be on a separate offline machine. For small operations, the secondary CAs can be automated, and you sign the certificates for these secondaries manually with the root CA. I would keep the root CA password on paper – can’t be hacked (but watch out for cameras). Do NOT skip the password for the root CA. Some number of systems will trust that CA for any domain. If the private key leaks, you end up with a situation like Dell faced in 2015<\/a>.<\/p>\n Let’s put the manual root CA in \/etc\/pki\/CA<\/kbd> and generate the root cert. Openssl will ask you for a key passwd, and what x509 calls “subject identifiers”. I left the state and email blank, and set city to Fedora City<\/kbd>, organization to Fedora Project<\/kbd>, organizational unit to ca<\/kbd>, and common name to ca.example.org<\/kbd>. The “-days 3650” sets the expiration to 10 years from now. The second command shows the “Issuer” information end-users will see when they ask for the issuer in an app like Firefox. The common name should normally be the hostname of the root CA, but it doesn’t really matter when the root CA is offline – and example.org is coincidentally offline by convention. How Public Keys Prevent Man-In-The-Middle Attacks<\/h2>\n
The Directory of Pubkeys is Critical<\/h3>\n
How Mainstream Browsers Know Which CAs to Trust<\/h2>\n
Create a private TLD with bind<\/h2>\n
$TTL 2H
; hello.fedora
@ IN SOA ns1 hostadmin.hello.fedora. (
2025122600 ; serial
1H ; refresh
15M ; retry
14D ; expire
6H ; default_ttl
)
@ IN NS ns1.fedora.
@ IN TXT \"v=spf1 -all\"
hello IN A\t192.168.100.31
ns1 IN\tA\t192.168.100.31
ca IN\tA\t192.168.100.31<\/pre>\n# smallstep article
192.168.100.31\thello.fedora
192.168.100.31\tca.fedora<\/pre>\nRun a private CA with step-ca<\/h2>\n
sudo dnf copr enable @fedora-review\/fedora-review-2418762-smallstep<\/pre>\n
Create root CA<\/h3>\n
![\"\ud83d\ude42\"](\"https:\/\/sickgaming.net\/blog\/wp-content\/uploads\/2026\/04\/make-a-private-ca-with-step-ca.png\")
<\/p>\n$ sudo mkdir \/etc\/pki\/CA
$ cd \/etc\/pki\/CA
$ sudo install --mode=644 \/dev\/stdin root_ca.fedora.ext <<EOF
subjectAltName=DNS:ca.example.org
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:1
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
EOF
$ sudo mkdir -m 0700 private
$ sudo openssl req -new -keyout private\/root_ca.key -out root_ca.csr
...
$ sudo openssl x509 -req -in root_ca.csr -key private\/root_ca.key -out root_ca.crt -days 3652 -sha256 -extfile root_ca.fedora.ext
Enter pass phrase for private\/root_ca.key:
Certificate request self-signature ok
subject=C=US, L=Fedora City, O=Fedora Project, OU=ca, CN=ca.example.org<\/pre>\nCreate intermediate certificate and install smallstep<\/h3>\n