--- title: '010. Centralized Wildcard Certificate on Debian with Let’s Encrypt + deSEC' url: 'https://prozak.org/010-centralized-wildcard-certificate-on-debian-with-lets-encrypt-desec' markdown: 'https://prozak.org/010-centralized-wildcard-certificate-on-debian-with-lets-encrypt-desec.md' date: '2026-03-01' description: 'In this guide, we centralize wildcard certificate issuance on a Debian VM using Let’s Encrypt and deSEC, fully automated and renewal-safe. The result is a single source of truth for TLS that future nodes can securely consume without manual intervention.' taxonomy: category: - self-hosting tag: - self-hosting - cloud - linux - python archives_month: - mar_2026 archives_year: - '2026' --- # 010. Centralized Wildcard Certificate on Debian with Let’s Encrypt + deSEC [ Blog Posts ](https://prozak.org/) 010. Centralized Wildcard Certificate on Debian with Let’s Encrypt + deSEC 01 *Mar* #### [010. Centralized Wildcard Certificate on Debian with Let’s Encrypt + deSEC](https://prozak.org/010-centralized-wildcard-certificate-on-debian-with-lets-encrypt-desec) [self-hosting](https://prozak.org/tag:self-hosting) [cloud](https://prozak.org/tag:cloud) [linux](https://prozak.org/tag:linux) [python](https://prozak.org/tag:python) ![](https://prozak.org/images/b/7/3/b/d/b73bd39701dd3d28af8aef1a77f682b1ffd3cf6f-image-2.png) **Motivation** When running multiple services in a #homelab, private certificates become a nuance, also, when sharing these services with other people it can become a "support nightmare" the security risks notifications in browsers for non tech-users. By enabling one [Debian](https://debian.org) VM/LXC container as the locally centralized point of automated request, update and have them ready to consume by other services/infrastructure you will be enabling a secure environment for most of your web based services. **The Stack: What You’ll Use** Debian VM/LXC - our preferred OS [deSEC.io ](https://desec.io)- DNS provider Certbot packages and Hooks systemd services and timers **Why deSEC and not Cloudflare** You COULD use Cloudflare for these services, and your CDN, reverse tunnels, etc. etc. and also be part of the more than frequent [outages](https://duckduckgo.com/?q=cloudflare%2Boutage&ia=news&iar=news) for their services or their constant [changes in ToS](https://en.wikipedia.org/wiki/Cloudflare), in a nutshell, Cloudflare became one of the centralization points in the internet, I strongly recommend using more friendly alternatives like deSEC, who in the other hand is: - Non-profit - API-first - No proxy layer - DNS only - EU Based - No CDN layer. No traffic inspection. No “free tier upsell later”. For a #homelab, simpler is better. **deSEC does DNS. Nothing else.** **Architecture Overview** This little project does not need "infra architecture" it's all about services architecture. ``` [DebianVM] → Certbot-deSEC LE Request → deSEC API Challenge → SSL Generation → SSL Storage → SSL Cert Files Storage in distribution Folder ``` **Step-by-Step Guide** Install Debian Packages ```apt apt install certbot python3-certbot-dns-desec ``` Create deSEC API Token Log in to your deSEC account - ([Create one](https://desec.io/signup)) Go to Token Management Section Create a new Token, with Edit Rights. ![image-2](https://prozak.org/images/c/7/e/6/3/c7e634eaaac27a022d16544670fe30c92a18e629-image-2.png "image-2") **Store the API credentials in your VM/LXC** ``` mkdir -p /root/.secrets nano /root/.secrets/desec.ini dns_desec_token = ``` Finally, lets make the file secure. ``` chmod 600 /root/.secrets/desec.ini ``` Request LE Wildcard Certificate ``` certbot certonly \ --dns-desec \ --dns-desec-credentials /root/.secrets/desec.ini \ -d '*.yourdomain.com' ``` Once DNS propagation and Challenges are passed, you will have the generated .key and .pem files in: /etc/letsencrypt/live/yourdomain.com/ Containing: fullchain.pem privkey.pem These are now your LIVE certificate files. Renewal Automation Certbot ([Donate](https://supporters.eff.org/donate/support-work-on-certbot) to EFF!) configures a renewal systemd task, you should Verify: ``` systemctl list-timers | grep certbot ``` and Test it: ``` certbot renew --dry-run ``` Export Certificate to a Shared Directory Now the important part. Other nodes/service should not read /etc/letsencrypt. That directory is root-restricted and not designed for sharing. We will automate the copy and "export" of the .pem and .key files in the VM/LXC filesystem to enable a pull distribution in future. Create a dedicated export path: ``` mkdir -p /srv/certs ``` Create a "deploy" hook: ``` nano /etc/letsencrypt/renewal-hooks/deploy/export.sh ``` And add: ``` #!/bin/bash SOURCE="/etc/letsencrypt/live/yourdomain.com" TARGET="/srv/certs" cp $SOURCE/fullchain.pem $TARGET/yourdomain-fullchain.pem cp $SOURCE/privkey.pem $TARGET/yourdomain-privkey.pem chmod 640 $TARGET/* chown root:ssl-cert $TARGET/* ``` Make it executable: ``` sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/export.sh ``` Now every successful renewal automatically updates /srv/certs. This becomes your controlled distribution point for a locally available wildcard certificate. **Future Work** In Future we will be doing the following: Other Nodes authenticate to this VM Pull cert via: SSH rsync or Tailscale-restricted endpoint Services reload automatically Centralized issuance. Distributed usage. Clean. **Discussion** Why Not an Ingest Node? You might think: > “Why not make this a general ingest node using caddy/traefik/nginx/whatever for logs, metrics, reverse proxy, and cert authority?” Because this is a #homelab. Not a cloud region. Simplicity is KING, we ought to avoid un-needed technical complexities. One VM/LXC doing: DNS challenges Certificate management Controlled export is manageable. One VM doing previous plus: Reverse proxy Log ingestion Metrics processing Public exposure is architecturally complex. In a one-man show/low support capacity, complexity is technical debt you personally repay at 2AM. Separation of concerns keeps failure domains small. **Keep this VM boring. Boring infrastructure survives. Boring is good.** **Conclusion** This method enables secure, low-friction valid FQDN/Domain SSL certificate acquiring for your #homelab services without exposing your LAN, relying only on tools that do one thing and do it well. One certificate. One place of truth. No manual renewals. [ Next Post](https://prozak.org/011-deploying-centralized-tls-certificates-node-docker-application) [Previous Post ](https://prozak.org/009-caddy-server-auth-crunch-plugin) #### Related Posts - 100 [012. Dynamic DNS Python Script -> deSEC.io DNS Service](https://prozak.org/012-dynamic-dns-python-script-greater-than-desec-io-dns-service "012. Dynamic DNS Python Script -> deSEC.io DNS Service") - 100 [005. Oracle Cloud Always Free Instance Ubuntu -> Debian Conversion](https://prozak.org/005-oracle-cloud-always-free-instance-ubuntu-greater-than-debian-conversion "005. Oracle Cloud Always Free Instance Ubuntu -> Debian Conversion") - 80 [006. Why #SelfHosting should be preferred](https://prozak.org/006-why-selfhosting-should-be-preferred "006. Why #SelfHosting should be preferred") - 75 [011. Deploying Centralized TLS Certificates Node + Docker Application](https://prozak.org/011-deploying-centralized-tls-certificates-node-docker-application "011. Deploying Centralized TLS Certificates Node + Docker Application") - 75 [001. Self-Hosting?](https://prozak.org/001-self-hosting "001. Self-Hosting?") #### Links - [< ](https://webring.obeythesystem.com/page?=previous)[OBEY THE SYSTEM Webring](https://webring.obeythesystem.com/)[ >](https://webring.obeythesystem.com/page?=next) - [rc64k@Github](https://github.com/rc64k) - [Prozak's Mastodon](https://mastodon.social/@prozak) #### Popular Tags [self-hosting](https://prozak.org/tag:self-hosting) [linux](https://prozak.org/tag:linux) [python](https://prozak.org/tag:python) [caddy](https://prozak.org/tag:caddy) [cloud](https://prozak.org/tag:cloud) [privacy](https://prozak.org/tag:privacy) [Philosophy](https://prozak.org/tag:Philosophy) [Quote](https://prozak.org/tag:Quote) [emby](https://prozak.org/tag:emby) [tailscale](https://prozak.org/tag:tailscale) [influxdb](https://prozak.org/tag:influxdb) [network](https://prozak.org/tag:network) [unifi](https://prozak.org/tag:unifi) [artificial intelligence](https://prozak.org/tag:artificial%20intelligence) #### Archives - [ 1 October 2026 ](https://prozak.org/blog/archives_month:oct_2026) - [ 2 July 2026 ](https://prozak.org/blog/archives_month:jul_2026) - [ 3 March 2026 ](https://prozak.org/blog/archives_month:mar_2026) - [ 3 July 2025 ](https://prozak.org/blog/archives_month:jul_2025) - [ 1 May 2025 ](https://prozak.org/blog/archives_month:may_2025) - [ 1 March 2025 ](https://prozak.org/blog/archives_month:mar_2025) - [ 1 September 2024 ](https://prozak.org/blog/archives_month:sep_2024) - [ 1 February 2024 ](https://prozak.org/blog/archives_month:feb_2024) - [ 1 August 2023 ](https://prozak.org/blog/archives_month:aug_2023) - [ 1 March 2021 ](https://prozak.org/blog/archives_month:mar_2021) - [ 2 February 2021 ](https://prozak.org/blog/archives_month:feb_2021) #### RSS & Atom Feeds [ Atom 1.0](https://prozak.org/blog.atom) [ RSS](https://prozak.org/blog.rss) --- ## Navigation - Parent: [Blog Posts](https://prozak.org/index.md) - Previous: [011. Deploying Centralized TLS Certificates Node + Docker Application](https://prozak.org/011-deploying-centralized-tls-certificates-node-docker-application.md) - Next: [009. Caddy Server Auth Crunch Plugin](https://prozak.org/009-caddy-server-auth-crunch-plugin.md)