TLS in lnav is not decoration. It is the lock, the walls, and the gate. Without it, debug streams and production traces are exposed to the network like open tabs on a public browser. Configuring TLS in lnav takes minutes, but gets you miles farther in security.
Why TLS in lnav matters
When lnav connects over a network socket, the raw stream can be intercepted. By enabling TLS, every byte is encrypted before it leaves your machine. This means packet sniffers see nothing but noise. Credentials, API keys, and stack traces stay private.
Core steps to configure TLS in lnav
- Generate or obtain a certificate
Use an internal CA, or generate a self-signed cert for testing. Production needs trusted certificates to avoid warnings and failures. - Place the cert and key in a secure path
Protect file permissions. Only the process owner should read them. Avoid embedding certs directly into config files. - Edit your lnav configuration
In your lnavrc or equivalent setup file, specify the TLS certificate, key, and optionally the CA bundle for chain validation. - Set verify parameters
Disable verification only in controlled development environments. In production, full verification defends against spoofed endpoints. - Restart and test
Verify withopenssl s_clientor similar tooling. Make sure the negotiated cipher is strong and meets your compliance policies.
Common pitfalls to avoid
- Incorrect key/cert permissions block lnav from reading them.
- Mixed content: sending logs to both TLS and non-TLS endpoints leaks data.
- Not rotating certificates regularly increases risk.
Going beyond basic TLS
Modern security policies look for TLS 1.3 and perfect forward secrecy. Choose ciphers accordingly. Offload TLS if your log server handles heavy traffic, but keep in mind that offloading means trusting that intermediate. Integrate with system-level trust stores for easier certificate management.