Five stacked failure modes between a fresh Omarchy install and a working fingerprint reader on a Dell XPS 9370.
This post has a weird genesis. If I think back to the first time I heard of Transit Encryption I originally thought it was something else, and when I finally understood what the docs were telling me, I thought it was the dumbest idea ever.
Turns out I was way wrong. Over the next half an hour I hope to explain why.
The point of transit encryption is to provide a mechanism for requesting vault encrypt some content for you as a service, so that you can send that encrypted blob over untrustworthy, or observable channels. The recipient can then go back to vault, and request that content be decrypted for use.
I thought i was done with this series, but there are a few loose ends that I think we can clear up pretty quickly. The most important of which is Audit Logging, because what is the point of a secure secrets tool if you don’t track who does what (or most importantly, fails to do what) with it. Lets jump in!
Enabling audit logging requires you to tell the vault server that it should use one of the audit “device types” that it offers with the required parameters. The system will then send audit events to all defined devices, and will consider the audit entry a success when at least one confirms the write.
Now that we have a Vault, with a TLS Issuing CA, and some idea of how to get certs out of it, lets look at how we can use this in a “real” world scenario to put a valid TLS profile onto a Network Appliance (fancy word for a switch I guess).
Why did I say appliance, and not Router or Switch? Weeeeeell, think about it. You manage a lot of network stuff over HTTPS protocols these days, even when its not actually a web interface you are using to do it. We can also manage load balancers, Wireless Controllers, NAS devices etc etc etc. Lets not get bogged down in terminology and accept that network kit comes in all shapes and sizes these days. Trusted TLS is the goal here.