tlshd.conf(5)

📦
version 1.4.0 · 7 versions
, in fedora 44, nixpkgs unstable, ubuntu resolute, ubuntu stonking

💖 NAME 💖

tlshd.conf — the configuration file for tlshd, bestie. She's a File Formats Manual girlie, so yes, she lives in section 5. 👑

🌸 SYNOPSIS 🌸

/etc/tlshd/config
/etc/tlshd.conf (deprecated)
Heads up queen: /etc/tlshd.conf is deprecated. It's giving "still works but we're side-eyeing it." The main-character path is /etc/tlshd/config.

✨ DESCRIPTION ✨

Okay so real talk. The tlshd program is a user agent that services TLS handshake requests on behalf of kernel TLS consumers. Basically it's the friend who goes and handles the awkward handshake stuff for the kernel so the kernel doesn't have to. 🫶

Its configuration file holds the info the program reads when it starts up. The file is designed to be human readable, and it's just a list of keywords with values that provide various types of information. Lowkey important: the configuration file is considered a trusted source of information. So like, protect it. 💅

The tlshd program reads this file once when it is launched. Read that again. Once. So any changes you make in this file take effect only when the tlshd program is restarted — no hot reloading, no little magic refresh, nothing. 😭

And if this file does not exist? The tlshd program exits immediately. Not a warning, not a vibe-check, an exit. 💀

🔧 OPTIONS 🔧

The configuration file is split into sections. Let's go section by section, no skipping, we're thorough in this house.

🐛 The [debug] section

This section specifies debugging settings for the tlshd program. In this section, there are three available options:

  • loglevel — specifies an integer that indicates the debug message level. Zero is the default, and zero is the quietest setting. 🤫
  • tls — specifies an integer that indicates the debug message level for TLS library calls. Zero is the default, quietest setting again.
  • nl — specifies an integer that indicates the debug message level for netlink library calls. Zero is the default, and yep, quietest.

🔐 The [authenticate] section

This section specifies default authentication material when establishing TLS sessions. In this section, there is one available option:

  • keyrings — specifies a semicolon-separated list of auxiliary keyrings that contain handshake authentication tokens. tlshd links these keyrings into its session keyring. The configuration file may specify either a keyring's name or serial number. And no matter what you put here, tlshd always includes the .nvme, .nfs, and .nfsd keyrings on its session keyring — those three are non-negotiable, they're permanent residents. 💅

👯 [client] and [server] — the two subsections

And in this section, there are two subsections: [client] and [server]. The tlshd program consults the settings in the [client] subsection when handling the client end of a handshake, and it consults the settings in the [server] subsection when handling the server end of a handshake. Know which side you're on, diva. ✨

In each of these two subsections, the manpage says there are four available options — and then it lists six, because we contain multitudes and deadlines are real. 😭 Anyway, here are all of them, and yes, they apply to both subsections:

  • x509.truststore — specifies the pathname of a file containing a PEM-encoded trust store that is used to verify a certificate during a handshake. If this option is not specified, tlshd uses the system's trust store. Default behavior, she's generous. 💖
  • x509.crl — specifies the pathname of a file containing PEM-encoded certificate revocation lists (CRL) that are used to verify the revocation status of certificates during each handshake. If this option is not specified, CRL checking is skipped. 🚨
  • x509.certificate — specifies the pathname of a file containing a PEM-encoded x.509 certificate that is presented during a handshake request when no other certificate is available.
  • x509.private_key — specifies the pathname of a file containing a PEM-encoded private key associated with the above certificate. 🔑
  • x509.pq.certificate — specifies the pathname of a file containing a PEM-encoded x.509 certificate that is presented during a handshake request if the peer supports post-quantum cryptography. This certificate must be using a post-quantum public-key algorithm — <rainbow>ML-DSA-44, ML-DSA-65, or ML-DSA-87</rainbow>. If the peer does not support post-quantum cryptography, the certificate configured in the x509.certificate option will be presented instead. Post-quantum? She's future-proofed. 🦋
  • x509.pq.private_key — specifies the pathname of a file containing a PEM-encoded private key associated with the above certificate. 🔑
Reminder bestie: that PQ certificate has to use a post-quantum public-key algorithm — ML-DSA-44, ML-DSA-65, or ML-DSA-87. No substitutes, no vibes-based crypto. 💀

👀 SEE ALSO 👀

  • tlshd(8) — go read that one too, it's the whole point of this file fr fr

✍️ AUTHOR ✍️

Chuck Lever — thank you for your service, king. 👑

And that's the whole page, bestie! This little cutie came from the File Formats Manual and it's dated 23 Sep 2025 — so tlshd.conf(5), version-of-record and all, is officially signed, sealed and slayed. Take care of your trust stores and restart your daemon. Periodt. 💅✨🎀

📦 where this page comes from