The problem is that Let's Encrypt doesn't support wildcard certs, so having a single cert for the origin and allowing connections on "www." is not possible. This is a problem because a request on "https://www." will be rejected completely rather than redirected to the origin (or vice versa). In other words, I have to choose one, and the other one won't work at all and can't be redirected (for https, but I'm auto-redirecting from http to https as well, so for everything). Obviously, the marketing gains from not having a "www" outweigh any other considerations at this point, so no "www".
As I understand it, anyway. I could be wrong. I hope I'm wrong, and have just misunderstood how this all hangs together.
They do, and it's fabulous, but *.example.com certs from LE do not cover the root domain (example.com) so if you do a wildcard cert, you then must also do www.example.com.
I didn't find docs specific to wildcard + non-wildcard, but LE certs can use multiple subject alternate names. So whatever tool you use, use SAN to request both *.example.com and example.com into one cert.
I imagine you have to setup your stuff to respond to the DNS + web based challenge/response.
The problem is that Let's Encrypt doesn't support wildcard certs, so having a single cert for the origin and allowing connections on "www." is not possible. This is a problem because a request on "https://www." will be rejected completely rather than redirected to the origin (or vice versa). In other words, I have to choose one, and the other one won't work at all and can't be redirected (for https, but I'm auto-redirecting from http to https as well, so for everything). Obviously, the marketing gains from not having a "www" outweigh any other considerations at this point, so no "www".
As I understand it, anyway. I could be wrong. I hope I'm wrong, and have just misunderstood how this all hangs together.