Cert for Subdomain that also has wildcard domain

Not sure this is entirely a Let'sEncrypt question.

I have hosted domain lets call it domain.com that uses a tool called AutoSSL to issue/renew certs for a number of first level domains via a wildcard (*.domain.com covers mail.domain.com, etc.) and several second level domains (www.mail.domain.com). All certs renew automatically except as described below.

I also have a subdomain with a CNAME record pointing to an A record provided through another DNS provide. I control the server the A record points to and have certbot running for that certificate (external.domain.com) which renews automatically.

I have a third subdomain hosted as aws.domain.com via route 53 where I have NS records where my domain is hosted that offloads name resolution for this subdomain to the route53 name servers at amazon. I have not created a certificate for this yet.

I think I want to have aws issue a new cert for the aws.domain.com subdomain that sits on their name servers vs copying the wildcard certificate so that I can have it auto renew.

My question is will this break anything because the wildcard domain also covers the subdomain as users navigate between the two. I'm guessing not since each will get it's own handshake and validation but thought I'd check since the different NS scenario is new to me.

2 Likes

That sounds fine to me.

Overlapping certificate coverage between different servers isn't going to cause you issues.

2 Likes

As long as global DNS can resolve a name to an IP, LE will check that IP for HTTP validations.
So, I don't see any problem with this either.

1 Like

As others have said, there's no technical reason to avoid having both a *.example.com on one server and a specific-host.example.com certificate on another; they'll both "work" fine.

But depending on what exactly you're doing, and who has access to what systems, it's important to keep in mind that this allows any server with the *.example.com private key to be able to spoof the specific-host.example.com server. If it's the same team administrating them, with the same level of security needed on both, then it's probably not a big deal. But you're in a case where, say, the specific-host is doing all the credit card processing or whatever that needs more security and it's much more hardened and few people have access, while the server with * is more open (maybe just serving static content and more people can log into it or whatever), or something like that, then this kind of setup means that if the *-server gets compromised (hacked, malicious employee, whatever) then it could present a certificate valid for the specific-host even though it's not "supposed to".

This really is an issue with using wildcard-certificates in general (since well, they mean that the server is authorized for any host; that's what the wildcard means after all). I guess I'm just trying to say that you have different servers with different requirements it may be worth double-checking whether a wildcard cert is really the best option for what you're doing. Maybe it makes more sense to instead only wildcard another subdomain-level down, like *.otherstuff.example.com so that it won't be able to serve really-secure-server.example.com itself. Or if it's only a few subdomains that it really should be used for, then maybe it makes sense to just get a cert for those specific subdomains. Or maybe the wildcard really does make the most sense. There's a lot of possible "right" ways depending on what you're actually trying to accomplish.

2 Likes

Yes, to remove the potential of overlap, you could for instance:
Move the secure credit card system into a subdomain that won't be covered by the root wildcard:
ccprocessing.securezone.domain.com
*.domain.com

Or, if you're anything like me and are really paranoid, split them both into their own subdomains:
*.commonzone.domain.com
*.securezone.domain.com

2 Likes

Thank you for the guidance. I've tagged the response about moving one level down to prevent overlap as the accepted solution.

Both allowing the overlap and moving to a 2nd level subdomain functionally worked however the latter is where I landed.

2 Likes