4 ms·

You can have more than one certificate for the same names but both would need to be valid. If the testing one leaks, someone can impersonate your production ser

by blfr 9y ago

You can have more than one certificate for the same names but both would need to be valid. If the testing one leaks, someone can impersonate your production service.

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 ago
  Thanks 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 ago
    You 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 ago
      Awesome. Renewing via DNS sounds like exactly what I need. Thanks!

4 ms·

You can have more than one certificate for the same names but both would need to be valid. If the testing one leaks, someone can impersonate your production ser

by blfr 9y ago

You can have more than one certificate for the same names but both would need to be valid. If the testing one leaks, someone can impersonate your production service.

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 ago
  Thanks 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 ago
    You 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 ago
      Awesome. Renewing via DNS sounds like exactly what I need. Thanks!