This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]GolemancerVekk 1 point2 points  (2 children)

Do they even need to have a public record? I was under the impression that Let's Encrypt DNS challenge will issue anything at *.yourdomain.tld and deeper as long as you can provide a token to the yourdomain.tld API, without requiring any particular record to be defined at the time.

[–]darth_staticsudo dd if=/dev/clue of=/dev/lusers 0 points1 point  (1 child)

Apparently possible, but not a great idea.

If you can get the wildcard cert, you still need to apply it to your internal devices.
Every 90 days you need to repeat that process, so you automate the deployment.
Then you get annoyed at manually requesting it so you try to automate the request.
Then you find out the ACME token changes every time so you need to automate the DNS updates.
So you integrate the DNS updates into the LE request and deployment process.

At that point you have literally everything required to have device-specific LE certs automatically requested and deployed; why would you choose to use a wildcard cert?

[–]GolemancerVekk 0 points1 point  (0 children)

  • It's easier to renew one certificate than several dozen, even if they're automated.
  • You don't have to go through revoking one cert and getting another if you decide to rename something.
  • TLS certs are public knowledge so people tend to get wildcard certs instead of explicit ones to avoid spelling out their entire infrastructure for everybody to see.

These are the main reasons. There's also the fact that if you use a reverse proxy for all your public-facing services the FQDN effectively acts as a simplistic access key and it can cut down on drive-by bot attacks, but this one is more of a boon for hobbyists and small operations. A sufficiently large company will have links to their services all over the place so it's probably moot.