[GH-ISSUE #5910] wildcard subdomains in reverse proxy services #11894

Open
opened 2026-08-05 01:31:31 -04:00 by saavagebueno · 6 comments
Owner

Originally created by @Bajahaw on GitHub (Apr 16, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5910

Is your feature request related to a problem? Please describe.
Yes, I am wondering if wildcard subdomains are allowed in reverse proxy services, cuz for the moment the UI is preventing me from putting a * as a subdomain. if not possible, I would love to see that implemented, as in cloudflare tunnels.

Describe the solution you'd like

Image

Describe alternatives you've considered

--

Additional context
this is useful in case someone already have a local reverse proxy like Nginx or even Dokploy, so it does not make since to configure domains twice in Netbird and locally.

Thanks,

Originally created by @Bajahaw on GitHub (Apr 16, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5910 **Is your feature request related to a problem? Please describe.** Yes, I am wondering if wildcard subdomains are allowed in reverse proxy services, cuz for the moment the UI is preventing me from putting a * as a subdomain. if not possible, I would love to see that implemented, as in cloudflare tunnels. **Describe the solution you'd like** <img width="510" height="508" alt="Image" src="https://github.com/user-attachments/assets/7338dae5-7c9b-4cfa-88c1-cccc02452faa" /> **Describe alternatives you've considered** -- **Additional context** this is useful in case someone already have a local reverse proxy like Nginx or even Dokploy, so it does not make since to configure domains twice in Netbird and locally. Thanks,
saavagebueno added the feature-request label 2026-08-05 01:31:31 -04:00
Author
Owner

@J-eremy commented on GitHub (Apr 17, 2026):

I have the same exact setup with a proxy that handles all my certs upstream. In order to do wildcard requests LetsEncrypt REQUIRES it to be a dns challenge rather than a simple request, I also run on different ports because my ISP blocks incoming 80 and 443 so I have to do the dns challenge anyway.

The dns challenge requires access to the DNS zone, so it might not be as simple as just adding an asterisk.

<!-- gh-comment-id:4268023829 --> @J-eremy commented on GitHub (Apr 17, 2026): I have the same exact setup with a proxy that handles all my certs upstream. In order to do wildcard requests LetsEncrypt REQUIRES it to be a dns challenge rather than a simple request, I also run on different ports because my ISP blocks incoming 80 and 443 so I have to do the dns challenge anyway. The dns challenge requires access to the DNS zone, so it might not be as simple as just adding an asterisk.
Author
Owner

@crntnvdl commented on GitHub (May 21, 2026):

The HTTP/S proxy could in theory emit a certificate for new domains it doesn't know about like Caddy "On-Demand TLS" but there should be an abuse prevention system to prevent spamming cert generation and triggering the rate limiter.
Maybe instead of a wildcard you could provide a list of domains ?
It becomes relevant with the TLS Passthrough proxy: match the SNI with the wildcard and forward. That way you could have a "classic" Caddy project managing its own certificates either with ALPN or DNS.
I don't know if this would require some precautions about ECH ?

<!-- gh-comment-id:4508881174 --> @crntnvdl commented on GitHub (May 21, 2026): The HTTP/S proxy could in theory emit a certificate for new domains it doesn't know about like Caddy "On-Demand TLS" but there should be an abuse prevention system to prevent spamming cert generation and triggering the rate limiter. Maybe instead of a wildcard you could provide a list of domains ? It becomes relevant with the TLS Passthrough proxy: match the SNI with the wildcard and forward. That way you could have a "classic" Caddy project managing its own certificates either with ALPN or DNS. I don't know if this would require some precautions about ECH ?
Author
Owner

@lucek8123 commented on GitHub (May 21, 2026):

There is wildcard certificates support in Netbird, it's just it can't make them. If you get your certs though for ex. traefik and then export them in format that is known to netbird proxy (cert and key file) then it just works. For example if you have certificates for example.com and *.example.com (pretty common with DNS challange) it will use it when you add test.example.com, immich.example.com, example.com as domain. You have to set at least NB_PROXY_WILDCARD_CERT_DIR and NB_PROXY_CERTIFICATE_DIRECTORY environment variables for this to work. The problem is that we want proxy to be able to catch all domains that match *.example.com and proxy it target to not have to set all sites one by one.

Right now I host my own netbird proxy on VPS and I want it to proxy all of request to my netbird client docker that is connected by network mode with traefik (this with netbird server runs on my home server). Then traefik acts as reverse proxy for all of services I have and matches which one should it host by host header. It should be possible to not type every service one by one - it is irritating and I think unnecessary when netbird works just fine with wildcard certificates.

EDIT: so as conclusion, we don't need to make "On-Demand-TLS" for this to work. We just need to enable wildcard subdomains to work with proxy.

<!-- gh-comment-id:4510277789 --> @lucek8123 commented on GitHub (May 21, 2026): There is wildcard certificates support in Netbird, it's just it can't make them. If you get your certs though for ex. traefik and then export them in format that is known to netbird proxy (cert and key file) then it just works. For example if you have certificates for example.com and *.example.com (pretty common with DNS challange) it will use it when you add test.example.com, immich.example.com, example.com as domain. You have to set at least `NB_PROXY_WILDCARD_CERT_DIR` and `NB_PROXY_CERTIFICATE_DIRECTORY` environment variables for this to work. The problem is that we want proxy to be able to catch all domains that match *.example.com and proxy it target to not have to set all sites one by one. Right now I host my own netbird proxy on VPS and I want it to proxy all of request to my netbird client docker that is connected by network mode with traefik (this with netbird server runs on my home server). Then traefik acts as reverse proxy for all of services I have and matches which one should it host by host header. It should be possible to not type every service one by one - it is irritating and I think unnecessary when netbird works just fine with wildcard certificates. EDIT: so as conclusion, we don't need to make "On-Demand-TLS" for this to work. We just need to enable wildcard subdomains to work with proxy.
Author
Owner

@J-eremy commented on GitHub (May 21, 2026):

Currently I wrote a bash script that runs on a schedule that extracts all the certs my local traefik proxy on my lan gets from the dns challenge from letsencrypt and outputs them in PEM format into a folder that I could just sync up to the vps that hosts the netbird server and reverse proxy.

I have a local traefik proxy running because I have my dns rewritten for all the addresses I host on my lan for all computers that are local so the traffic doesnt need to leave the house if it doesnt have to.

In theory the reverse proxy for netbird can just completely ignore serving the cert and let the traefik proxy that runs in front of the server itself terminate all the ssl as it scans and loads all certs in the acme folder anyway by default and applies them to the correct route.. But that would require people to use traefik and it would remove choice from the initial setup.

<!-- gh-comment-id:4510529432 --> @J-eremy commented on GitHub (May 21, 2026): Currently I wrote a bash script that runs on a schedule that extracts all the certs my local traefik proxy on my lan gets from the dns challenge from letsencrypt and outputs them in PEM format into a folder that I could just sync up to the vps that hosts the netbird server and reverse proxy. I have a local traefik proxy running because I have my dns rewritten for all the addresses I host on my lan for all computers that are local so the traffic doesnt need to leave the house if it doesnt have to. In theory the reverse proxy for netbird can just completely ignore serving the cert and let the traefik proxy that runs in front of the server itself terminate all the ssl as it scans and loads all certs in the acme folder anyway by default and applies them to the correct route.. But that would require people to use traefik and it would remove choice from the initial setup.
Author
Owner

@lucek8123 commented on GitHub (May 21, 2026):

In theory the reverse proxy for netbird can just completely ignore serving the cert and let the traefik proxy that runs in front of the server itself terminate all the ssl as it scans and loads all certs in the acme folder anyway by default and applies them to the correct route.. But that would require people to use traefik and it would remove choice from the initial setup.

It could, but it would require rewrite of netbird proxy. And is unnecessary, because we almost have solution for that. (This is how netbird proxy works. It terminates tls not reverse proxy that sits behind it. Thats why for reverse proxy service we use traefik. I got confused bc for me "netbird proxy" != "netbird server". Sorry) The only thing that is needed is to notify users that wildcard is only supported when using wildcard certificates. Then wildcard certificates are not issued by netbird (but they could if feature request from issue https://github.com/netbirdio/netbird/issues/5450 is resolved). Traefik is always required when configuring reverse proxy service (not necessary for other netbird services). Because it supports ACME DNS by LEGO it can be used to get acme.json with certificate. You can use anything else to get it (ex. container goacme/lego), but traefik is already used by reverse proxy service, because of tls passthough.

Then we have to pull it out from acme.json to cert/key with traefik-certs-dumper. And traefik-certs-dumper will put our certicates to NB_PROXY_WILDCARD_CERT_DIR directory. And both netbird and traefik-certs-dumper support certs dir watching so it will automaticly update when traefik will request new one. Also note that NB_PROXY_WILDCARD_CERT_DIR is env variable for netbird-proxy not netbird-server.

In my own setup I have working certs pulling from traefik to netbird and it is netbird that terminates TLS. I only need netbird to pass *.mydomain.com to my client that "has" revese proxy for matching Host SNI (docker netbird client is connected via network_mode: container:traefik to traefik; reverse proxy does not need to be traefik here). It allows me to access my services though netbird proxy and in my home local network without proxy. As bonus I have docker container network isolation and auto network creation and connecting to them by setting labels with obeoneorg/traefik_network_connector.

TLDR: Netbirds needs to notify users that this is only possible with wildcard certificates. It should be possible to make it that it's only possible when netbird has wildcard certificate for site. We do not need to change anything else.

Edit: some spelling and clarification.

<!-- gh-comment-id:4511041804 --> @lucek8123 commented on GitHub (May 21, 2026): > In theory the reverse proxy for netbird can just completely ignore serving the cert and let the traefik proxy that runs in front of the server itself terminate all the ssl as it scans and loads all certs in the acme folder anyway by default and applies them to the correct route.. But that would require people to use traefik and it would remove choice from the initial setup. ~~It could, but it would require rewrite of netbird proxy. And is unnecessary, because we almost have solution for that.~~ (This is how netbird proxy works. It terminates tls not reverse proxy that sits behind it. Thats why for reverse proxy service we use traefik. I got confused bc for me "netbird proxy" != "netbird server". Sorry) The only thing that is needed is to notify users that wildcard is only supported when using wildcard certificates. Then wildcard certificates are not issued by netbird (but they could if feature request from issue https://github.com/netbirdio/netbird/issues/5450 is resolved). Traefik is [always required](https://docs.netbird.io/selfhosted/migration/enable-reverse-proxy#why-traefik-is-required) when configuring reverse proxy service (not necessary for other netbird services). Because it supports ACME DNS by LEGO it can be used to get acme.json with certificate. You can use anything else to get it (ex. container goacme/lego), but traefik is already used by reverse proxy service, because of tls passthough. Then we have to pull it out from acme.json to cert/key with traefik-certs-dumper. And traefik-certs-dumper will put our certicates to `NB_PROXY_WILDCARD_CERT_DIR` directory. And both netbird and traefik-certs-dumper support certs dir watching so it will automaticly update when traefik will request new one. Also note that `NB_PROXY_WILDCARD_CERT_DIR` is env variable for netbird-proxy not netbird-server. In my own setup I have working certs pulling from traefik to netbird and it is netbird that terminates TLS. I only need netbird to pass *.mydomain.com to my client that "has" revese proxy for matching Host SNI (docker netbird _client_ is connected via `network_mode: container:traefik` to traefik; reverse proxy does not need to be traefik here). It allows me to access my services though netbird proxy and in my home local network without proxy. As bonus I have docker container network isolation and auto network creation and connecting to them by setting labels with `obeoneorg/traefik_network_connector`. TLDR: Netbirds needs to notify users that this is only possible with wildcard certificates. It should be possible to make it that it's only possible when netbird has wildcard certificate for site. We do not need to change anything else. Edit: some spelling and clarification.
Author
Owner

@azerioxal commented on GitHub (Jun 12, 2026):

I would also love to see this. It'd be quite useful for S3 and similar services.
bucket.s3.domain.com would be much easier as *.s3.domain.com

<!-- gh-comment-id:4690023421 --> @azerioxal commented on GitHub (Jun 12, 2026): I would also love to see this. It'd be quite useful for S3 and similar services. `bucket.s3.domain.com` would be much easier as `*.s3.domain.com`
Sign in to join this conversation.
No Label feature-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11894