Skip to main content

Module 7: PKI and certificates

You have collected two browser warnings so far. OPNsense threw one in Module 4, Gitea threw another in Module 6, and both times I told you to click through and that Module 7 would fix it properly. This is that module, and by the end of it those warnings are gone because your machines genuinely trust the certificates, not because you told them to stop complaining.

That distinction is the whole subject. Anyone can make a warning go away by clicking "accept the risk" forever. Building the thing that makes the warning wrong in the first place is public key infrastructure, and it's one of those areas where the number of people who can explain it end to end is much smaller than the number of job postings that ask for it.

What's in it:

  • 7.1 what a certificate is, and why yours isn't trusted
  • 7.2 the offline root (Tier 2)
  • 7.3 the issuing CA (Tier 2)
  • 7.4 a CA that issues certificates automatically
  • 7.5 teach your machines to trust it
  • 7.6 HTTPS at last, issued automatically
  • 7.7 templates and autoenrollment: certificates nobody requests (Tier 2)
  • 7.8 revocation, CRLs, and the day it all stops (Tier 2)
  • 7.9 journal entry
  • 7.10 checkpoint

The module builds one hierarchy, top down, which is the order a real organization builds in. Tier 2 starts at 7.2 with the offline root and the issuing CA beneath it. Tier 1 starts building at 7.4, where step-ca gives you a real certificate authority in a container with no extra virtual machines, and finishes with the same working HTTPS.

Tier 1 should still read 7.2 and 7.3. They're short, they're the PKI most Windows employers actually run, and the offline-root idea in 7.2 is the concept the rest of the module hangs off. This is the same arrangement Module 4 used for the firewall lessons.

The payoff is shared: by 7.6 everyone has certificates issued automatically and renewed without a human, and both browser warnings are gone. Tier 2 then continues into templates, autoenrollment, and revocation.

Here are the two chains this module builds, side by side:

Tier 1: one root, short chainno extra virtual machinesT1step-ca rootcontainer on UBNT01signsgit.lab.internalissued by ACME, auto-renewedTrust: install the root by handLinux trust store, Windows machine store,Firefox separately (lesson 7.5).One link to verify, one root to install.Everything a browser needs is two files.Tier 2: offline root, delegated downwardthe shape real organizations runT2ROOTCA01offline root · POWERED OFFsigns once,then goes darkSUBCA01 · Lab Issuing CAonline, domain-joinedstep-ca intermediatespeaks ACMEgit.lab.internalLinux services, auto-renewedWindows machinesautoenrolled, nobody askstemplates decide who mayrequest what (lesson 7.7)Trust: Group Policy pushes the root to every domain machineOne root to install, including on machines that do not exist yet.

How to read that picture​

Every arrow means "signed by." The thing at the top of an arrow vouched for the thing at the bottom. That's the only relationship in either panel, repeated.

Validation runs the other way. When a browser is handed a certificate, it walks up the arrows asking "who signed this, and do I trust them?", and keeps climbing until it either reaches something in its own trust store or runs out of chain. Reaching the top means a padlock. Running out means the warning you've seen twice. That's why the green boxes at the bottom of each panel matter as much as the chains above them: installing the root is what puts the top of the chain inside the machine's trust store, and without it the climb fails no matter how correct everything else is.

The left panel is two boxes and one arrow. A step-ca root, running in a container, signs your server certificates directly. It's the smallest thing that can honestly be called a PKI, and it works.

The right panel is the same idea with the responsibilities split up. ROOTCA01 is drawn dashed and faded because it's powered off; it signed the issuing CA once and then went dark, which is the whole reason the extra layer exists. SUBCA01 does the daily work, and two different kinds of certificate come off it: Linux services get theirs through the step-ca intermediate using ACME, and Windows machines get theirs by autoenrolling from Active Directory. Two very different mechanisms, one chain of trust underneath.

The difference that matters is at the bottom of each panel. On the left you install the root on each machine by hand. On the right, Group Policy does it for every domain member, including machines that don't exist yet. That's the same distinction as everywhere else in this course: doing a thing, versus building the thing that does it for you.

Budget an evening either side of 7.4. Nothing here is difficult; there's just a lot of it, and the concepts in 7.1 carry the rest.