Cloudflare Access - Wildcards to the right of sub-domains are not effective + need wildcards on the left of the application domain

I have this on my Cloudflare for Teams (Access) policy for a specific application:

It seems that no requests are getting an authentication request to login via GitHub (my only authentication method) and everything is just being let through, for example - to https://staging-go.tallyfy.com

Note that the domains staging-* (a few sub-domains) already exist, and are proxied through Cloudflare.

Why is this?

So it’s worth reviewing the application pathing documentation here:

https://developers.cloudflare.com/cloudflare-one/policies/zero-trust/app-paths#protect-multi-level-paths

The box at the bottom marked Important explains what you are encountering:

Important

You cannot use wildcards to partially match subdomain and path names. Using asterisks in any way other than the ones outlined above will cause the wildcard to be invalidated . This means your application won’t be effective, and neither will be any rules you may try to enforce on it at a later time.

Entry Does NOT cover
example.com/cat-* example.com/cat , example.com/cat-food
*ing.example.com ing.example.com , engineering.example.com

So you’d need to define an application for each subdomain you want to protect - or use *.example.com which would cover any/all subdomains

1 Like

So - this is inconvenient and doesn’t really work in real-life.

I don’t see why a simple wildcard has to have all these restrictions, as most naming conventions use some part of the domain as a top-level indicator e.g.

dev-*.domain.com

Given the fact that sub-sub-level domains have problems e.g. a.b.domain.com - the above seems to be the only way out. I cannot possibly sub-domain everything as *.domain.com in a single rule.

Please look into expanding/fixing this.

1 Like

Thanks for the feedback - would you mind raising a suggestion in Product Requests - Cloudflare Community - others can vote on this and I’ll share it with the product team.

Also can you explain a bit more about the multi-level subdomain issues? What issues are you having using those?

2 Likes

The core problem is that wildcards are highly restricted, and they need to be usable anywhere in a string that expressed either a path or any level of sub-domain. We can’t auto-provision new developers with their own dev environment if we have to manually make new rules for each sub-domain inside Access/Teams, while also reconnecting other parts of our system which are sub-domain-sensitive to the new client URL’s. Our app isn’t just a single URL, it’s various components that rely on endpoints with a predictable schema, ideally under a single sub-domain. As an example - we can’t just restrict *.tallyfy.com without exceptions because these are public URL’s that must be left open:

support.tallyfy.com > our support manual
go.tallyfy.com > our production client UI

I also don’t see any way of declaring exceptions to an overall rule.

There should be no technical reason from the Cloudflare side that you cannot do *.developers.example.com unless I’m missing something - but I understand it might not be ideal depending on your organisation and your own code / infrastructure.

Your feedback makes perfect sense - please do raise something that expresses this in the Product Requests category: Product Requests - Cloudflare Community others can then vote on it and it will help Product decide what to build next.

On your note about exceptions - there is also request in flight already on something similar that you might want to upvote and comment on: Access: Bypass rule by URL

2 Likes

sure - just posted here:

1 Like

Perfect - thankyou - I will be sure to flag these up internally to the Teams… ahem… Team :slight_smile:

1 Like

@simon to illustrate this - see this example. If we have 20 developers - we are not going to add 20 separate applications, if we can just do this (which doesn’t work):

Assuming there is a certificate on Cloudflare’s edge to cover the *.dev.subdomain.example.com this should work just fine.

1 Like

Unfortunately, on the specific rule, for the specific application above, I always get a Cloudflare Access “Forbidden” error when accessing something like this:

https://person.dev.subdomain.tallyfy.com

(person and subdomain are not real as I don’t want to make them public - but illustrate the point)

I also purchased the extra SSL certs for the wildcard under this subdomain, and added those under the section “Edge Certificates”

Have a similar issue.

we have a completely flattened url structure which helps with wildcard SSL certs etc but essentially we replaced periods in the subdomains with hypens, so where we might have had:

dev.developername.domain.com

we now have

dev-developername.domain.com

because the enterprise ecom platform we use has multiple tooling / authoring subdomains we then have hundreds of individual access policies to cover all these variations of

environment-subsubsystem-subssystem-variant.domain.com

being able to create an Access Policy with a single wildcard in the subdomain would massively simplify not only Access policy management but also the other ingress rules we have that also control access to the non public systems we have managed through Cloudflare

2 Likes

Hi @simon,

Thanks for your input.

the *.dev.examples.com encounters errors ERR_SSL_VERSION_OR_CIPHER_MISMATCH, explained here:
Cloudflare Access/Teams multi-level subdomain protection doesn’t work · Issue #2667 · cloudflare/cloudflare-docs (github.com)

Would be good for cloudflare to support multi-level subdomains really!

Thanks,

That’s due to this:

2 Likes

Thanks,

Will consider the Advanced Certificate Manager, not sure about $120/yr for certificates though, it used to be the case in the past.

Any special features other than just multi-level subdomain certs?

You can easily select between Let’s Encrypt and Digicert, though you can do the same on the free certs with the API (a bit of a hoop to jump through). You can also set DigiCert for different expiration periods.

1 Like