mirror of
https://github.com/fosrl/docs-v2.git
synced 2026-09-25 07:19:08 +02:00
36 lines
2.7 KiB
Plaintext
36 lines
2.7 KiB
Plaintext
---
|
||
title: "Wildcard Resources"
|
||
description: "Pangolin Cloud and Enterprise: route every hostname at a subdomain level through one public resource"
|
||
---
|
||
|
||
|
||
|
||
<Note>
|
||
Only available in [Pangolin Cloud](https://app.pangolin.net/auth/signup) and [Enterprise Edition](/self-host/enterprise-edition).
|
||
</Note>
|
||
|
||
With a wildcard public resource, one resource owns an entire subdomain level: every hostname under that level is proxied through the same Pangolin resource and tunnel so downstream systems can route further (for example another reverse proxy or Kubernetes ingress).
|
||
|
||
Access rules and authentication you set on that resource apply to all hostnames matched by the wildcard. If you enable a PIN code, every hostname under the wildcard requires that PIN. You can also attach a [resource policy](/manage/resources/public/resource-policies) so the same shared settings apply to the wildcard and any other linked public resources.
|
||
|
||
## Creating a Wildcard Resource
|
||
|
||
In the resource’s domain settings, set the subdomain field to `*` to match any label at that level. You can combine this with a parent subdomain, such as `*.apps`, so only hostnames under `apps` are covered, as long as TLS and DNS cover that same scope.
|
||
|
||
The downstream target still receives the original `Host` header, so virtual hosts and path rules on your side keep working.
|
||
|
||
## Requirements for Wildcard Resources
|
||
|
||
Wildcard hostnames need TLS certificates that cover `*.your-level`, not just a single FQDN, and DNS must send all of those names to Pangolin. How you satisfy that depends on how you host Pangolin.
|
||
|
||
### Self-hosted Pangolin
|
||
|
||
You must issue a wildcard certificate using DNS validation (DNS-01). HTTP-01 challenges prove one exact hostname at a time; they cannot obtain a certificate for `*.example.com`. DNS-01 proves control of the DNS zone, which is what certificate authorities require for wildcard coverage, otherwise Pangolin could not terminate HTTPS for arbitrary subdomains at that label.
|
||
|
||
Configure Traefik / Let’s Encrypt for DNS-01 and wildcard certs as described in [Wildcard domains](/self-host/advanced/wild-card-domains).
|
||
|
||
You also need DNS records so every name at that level resolves to your Pangolin server, for example an A record for `*.subdomain`. See [Domains](/manage/domains#for-wildcard-domains) for typical wildcard DNS patterns.
|
||
|
||
### Pangolin Cloud
|
||
|
||
Use a [domain delegation](/manage/domains#domain-delegation-ns-records) (NS record) domain so Pangolin controls DNS at the delegated zone. That delegation lets Pangolin issue and renew wildcard certificates for that level and ensures queries for `*.your-delegated-zone` route to Pangolin. Pangolin Cloud manages the certificates for you once delegation is in place. |