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 logs

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.

Abstract

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.

abstract

Following on from the Hashicorp Vault “how-to” series. Lets dial things up a notch, and setup a PKI in vault that can issue “real” certificates for your devices.

This has a couple of real tangible benefits.

1. No more verify=false and/or urllib hacks to connect to TLS secured endpoints
2. No need to fight openssl to wrangle self signed (or for the really brave, a manual CA)
3. Full automation support to enable estate wide renewal in minutes, not half a lifetime.

Much of this content was abstracted from the Original Hashi docs, which are brilliant, and can be found here.