True, but not for wildcards. Which is what they require.
1 Like
I'm still at a loss WHY they require a wildcard...
For like two names [FQDNs] only (or less)?
How many FQDNs point to their fastly system(s)?
3 Likes
Several domains of ours point to their systems and are served through the same VIP on the same load balancer. If they use a wildcard cert it's much easier. I would (was trying) to do the same. Unfortunately they got there first.
1 Like
That doesn't require a wildcard.
That requires a single cert with multiple names on it.
3 Likes
Again, you control the DNS zone.
How many entries are there in your zone that resolve (any which way) to a fastly IP?
I count one:
www.la-z-boy.com
3 Likes
Either way, theirs is already setup and I don't have the clout to have it changed. They got it first, now I have to find another way.
1 Like
Then you need to get some.
They have overextended their reach - it should be noted as such on any audit.
They have access to create wildcard certs for your domain!!!
[and they don't even really need it]
3 Likes
There's more than just one. There are other domains as well. Last I knew it was at least 5 or 6 going through the same VIP. That's a good point about the audit though, I will bring that up. Either way the fact remains that I have to find another way.
1 Like
For now...
Then they are all probably done just as wrongly.
[done fastly but not correctly]
3 Likes
IMHO they should not need a wildcard and should be able to either
- generate a cert with the specific enrolled domains, or
- use autocert functionality for multiple single-domain certs.
That being said, is there any reason why you can't explore one of those options? I thought that cert-manager can autocert with cloud storage for multiple nodes. I know caddy can, and I believe there are several gateways that can as well.
I don't really think so. It might be hard/impossible to coordinate with cert-manager, but I've done stuff like that for years with Certbot's pre/post hooks. IIRC, there are a handful of DNS libraries and APIs that essentially did that approach to avoid issues with competing TXT records.
5 Likes
I have already started the wheels turning on having them pushed down to just the specific certs they need. That will take time though. It really should be done for security so that's how I'm approaching it.
3 Likes
Absolutely.
4 Likes
Security is no longer a duty within just some jobs, it is a requirement within all jobs.
3 Likes
For a complex situation like this you can dynamically control the CNAME in cloudflare using their API via a post and pre request script, to repoint and restore the CNAME the other service needs.
To make matters more complex if you have have Universal SSL enabled on Cloudflare (I think it's on by default), it will (currently) also jump in and sneakily claim the _acme-challenge record (it's not shown in the list of DNS records, it's done dynamically), which in turn causes conflicts if you do actually need a CNAME. This is a relatively new thing they do for "backup" certs.
[Edit: as an extreme solution, you could run your own limited DNS service (e.g. in node etc) that pulls the current values from all the possible sources, Fastly etc and aggregates them as a set of _acme-challenge TXT records. LE will find the one it was expecting in the set. This only makes sense if you really require something so super custom).
6 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.