26 ms·
To go further on this though, wildcards usually only allow one "level" of wildcarding. so if you had a wildcard cert for *.internal.domain.com no one could use
by ryanbrunner 9y ago
To go further on this though, wildcards usually only allow one "level" of wildcarding. so if you had a wildcard cert for *.internal.domain.com no one could use it to impersonate www.domain.com (which is good, you should consider a cert that every developer has on their machine not trustworthy)
- lewisl9029 9y agoThanks for the clarifications. This is all starting to make a lot more sense now. Though I'm still curious how people usually distribute a cert like that internally and update it to keep it in sync with Let's Encrypt automatic renewal mechanism? As far as I understand, Let's Encrypt requires a public facing web server on the matching domain to renew certificates, so we'd have to actually set up a server solely for the purpose of certificate renewal on a 2-levels deep subdomain, expose it to the public internet, and then propagate the updated certs from that server into every dev machine every time a renewal is triggered? It sounds like there's little security risk with this approach as long as we use a wildcard cert at least 2-levels deep as you've described, as we don't have to trust this cert for real production traffic at the root domain. But I'm still wondering if there's some tooling I could adopt to streamline this process a bit? Or should I just bite the bullet and script it all myself?
- UnrealIncident 9y agoYou can issue/renew via DNS. I have a bunch of valid certs for domains that only resolve internally using this method. I believe the plan for wildcard certs is to only support DNS-01 challenges.
- lewisl9029 9y agoAwesome. Renewing via DNS sounds like exactly what I need. Thanks!