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