Secure homelab Kubernetes with wildcard TLS and no open ports

Self-hosters running Kubernetes clusters often face a dilemma between security and convenience when configuring HTTPS. A new technical guide demonstrates how to use k3s, Traefik, and cert-manager to issue trusted wildcard certificates via DNS-01 challenges, eliminating the need to open inbound ports from the public internet.

What happened

The article outlines a method for securing internal web applications in a homelab environment without relying on self-signed certificates or exposing the network to external scanners. By leveraging the DNS-01 challenge protocol, administrators can prove domain ownership to certificate authorities like Let's Encrypt through API calls to their DNS provider. This approach allows every application routed through the cluster to receive valid, browser-trusted HTTPS certificates automatically.

The process begins with verifying the default Traefik ingress controller installed by k3s. Instead of editing generated manifests directly, the guide recommends using a HelmChartConfig resource to modify Traefik settings, such as enforcing HTTP to HTTPS redirections. It also notes that older tutorials suggesting the installation of ingress-nginx should be avoided, as that project was retired in November 2025, with maintenance ending in March 2026. k3s users are advised to migrate any existing configurations to the native Traefik class.

Next, the guide details the installation of cert-manager, a tool that automates the management and issuance of TLS certificates. Once installed, administrators configure a ClusterIssuer that interacts with their DNS provider, such as Cloudflare, using scoped API tokens rather than global keys. The final step involves requesting a single wildcard certificate for the internal domain, which Traefik then serves as the default for all unmatched TLS connections, simplifying configuration for individual applications.

Key details

• No open ports required: The DNS-01 challenge validates domain ownership via DNS records, so no inbound traffic from the internet is needed for certificate issuance.
• Wildcard efficiency: A single certificate for *.home.example.com covers all internal apps, reducing management overhead and limiting exposure in public Certificate Transparency logs.
• Traefik configuration: Settings must be applied via HelmChartConfig in the kube-system namespace, using service.spec.type instead of the deprecated service.type key.
• Security best practices: Use scoped API tokens for DNS providers and store secrets in the cert-manager namespace, not the application namespaces.
• Staging first: Always test the issuer configuration with Let's Encrypt staging servers to avoid hitting rate limits before switching to production.
• Internal resolution: Internal hostnames resolve only via LAN DNS overrides, ensuring services remain unreachable from outside the local network even if the domain is public.

Background

Traditional HTTPS setup for home labs often involves two problematic paths. One is using self-signed certificates, which trigger browser warnings and break password managers, conditioning users to ignore security alerts. The other is opening port 80 to allow HTTP-01 challenges, which exposes the internal network to potential attacks. The DNS-01 challenge solves this by allowing the certificate authority to verify control of a domain by checking for a specific TXT record in the DNS zone, a process that happens entirely out-of-band from the web server.

In Kubernetes, an ingress controller acts as the entry point for external traffic, routing requests to appropriate services. Traefik, bundled with k3s, handles this routing and TLS termination. By setting a default TLS store in Traefik, administrators can ensure that any request matching the internal domain receives the correct wildcard certificate without needing to specify secret references in every individual Ingress resource. This decouples certificate management from application deployment.

Why it matters

For teams and individuals managing self-hosted infrastructure, maintaining trust in internal tools is critical. Browser warnings erode user confidence and create security blind spots where phishing attacks might succeed because users are accustomed to bypassing certificate errors. Automating valid certificate issuance ensures that internal dashboards, development environments, and administrative tools behave exactly like production systems, fostering better security hygiene.

Furthermore, reducing the attack surface is a primary concern for any IT lead. By avoiding port forwards for certificate validation, the homelab remains invisible to internet-wide scanners. This setup aligns with zero-trust principles where access is granted via VPNs rather than open firewall rules. It also simplifies operations; adding a new service requires only a standard Ingress definition, with TLS handled globally by the wildcard certificate.

The retirement of ingress-nginx also highlights the importance of staying current with ecosystem changes. Relying on supported, native components like Traefik in k3s reduces technical debt and ensures continued security updates. This approach provides a robust, maintainable foundation for internal services that scales as more applications are added to the cluster.

What you can do

• Verify your k3s Traefik version and update configuration using HelmChartConfig to enforce HTTPS redirections.
• Install cert-manager with CRDs enabled and configure a ClusterIssuer for your DNS provider using scoped API tokens.
• Request a wildcard certificate for your internal domain using the staging issuer first to validate the DNS challenge process.
• Configure a Traefik TLSStore to set the wildcard certificate as the default for all incoming TLS connections.
• Ensure internal DNS resolves your private domain to the Traefik LoadBalancer IP, keeping services inaccessible from the public internet.
• Replace any remaining ingress-nginx configurations with Traefik-compatible Ingress resources, removing deprecated annotations.