4 ms·

I've been wanting to experiment with something like this for my own dev environments for a while, and have been eagerly awaiting wildcard cert support from Let'

I've been wanting to experiment with something like this for my own dev environments for a while, and have been eagerly awaiting wildcard cert support from Let's Encrypt. One thing I'm not quite sure about is if this means we need to be using the same wildcard cert for both dev and prod? I don't suppose the cert can be considered valid by the browser if otherwise? If that's the case, I'm wondering if there are any best practices around securely distributing valid production certificates to dev machines across a team and keeping them up-to-date with Let's Encrypt's auto renewing mechanism? Ideally in a way that's transparent to each individual developer? I'm guessing committing them directly into a repo is probably a bad idea, especially for open source projects.

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!

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!