Listen Now

Segment 1 (Deep Dive)

RFC 2136 Certificate Management
Topics
RFC 2136 defines the Domain Name System (DNS) Dynamic Update protocol, which allows authorized clients to remotely update DNS records on a managed server. This protocol is a standardized method for Dynamic DNS (DDNS), enabling things like automatic updates when a client’s IP address changes. Many applications, such as BIND and Windows Server DNS, support RFC 2136, and it is frequently used for integrations with systems like DHCP or to automate services like TLS certificate validation with DNS challenges.
DNS
Configuring dynamic updates
Creating an update key with tsig-keygen
Including the key in named configuration
Allowing key-based zone updates
Certbot
Packages for rfc2136 support
certbot, python3-certbot, python3-certbot-dns-rfc2136
Automation (My Solution)
git (clone letsencrypt store)
Use SSH URI with ssh key authentication
Scripts (cron or systemd timer)
Replicate certificate store via git on servers that require it
Link certificates to store location
Restart services periodically (once weekly in my case)
Special Cases
VMware ESXi
Install keys in /etc/ssh/keys-${user}/authorized_keys
Script to push certs in ~${user} which pushes to /etc/vmware/ssl/rui.crt and /etc/vmware/ssl/rui.key and runs “/etc/init.d/hostd restart”
Proxmox VE
Put dns update key from DNS step above on Proxmox VE server in /usr/local/share/nsupdate.key
Configure Datacenter->ACME for use with ACME service.
Configure ${hostname}->Certificates to use ACME service with nsupdate plugin
Proxmox VE will automatically update and restart UI
Resources
https://lhs.fyi/KE (Gitlab Repo)

Segment 2 (Announcements & Feedback)

Comment on Episode #597 from Mike, KG4VDK
Hey crew! Congrats on your 600th episode! I am very thankful you took the time to try out arcOS, and talk about it in depth in episode #597! While listening to the episode, I won’t lie, I was trying to telepathically (and retroactively) send an “RTFM” hint to help get over some of the hurdles that seemed to pop up. 🙂 Since Bill mentioned it a few times in #597, and again in #598, I’d like to address the topic of icons: arcOS is designed to be a tool used by different types of operators. Some of those operators may be brand new to amateur radio, Linux, or both. The simplified icon set for amateur radio software serves two purposes. First, the icons present a more coherent visual experience. Even within a family of applications (like FL-digi/amp/msg or the VARA modems), many of the factory icons are less than helpful in identifying the represented application. Beyond that issue, some of the included applications just don’t have icons (ARDOP, Paracon, Pat). When trying to decide how to handle these two scenarios, I chose simplicity and legibility. If a user finds the supplied icons offensive, they can easily change them to something that suits their taste us[ing] a user module. I’ll attach a few screenshots that show the differences, as well as a user module that sets the icons to “factory” (README included in the archive). Feel free to reach out with any other feedback you may have, especially if you stick with it for a while. 73 de KG4VDK, Mike.
Please Help Support the Show
Patreon
Paypal
Merchandise
YouTube

Segment 3 (New Subscribers, New Supporters & Live Participants)

Free Patreons
T
Discord
N3VMM
neif
RavenHollow
Wrench
Phil n2edx
Doug - KC5VKG
Bob - KA9MDP
John KB1EJQ
Mastodon
@WC3B
@ricodehond
@z3ro_burn
@jeromyokc

LHS Episode #601: Automated Certificates Deep Dive