The same humans who incorrectly add "www." when not told to are also unlikely to add "https://". So have the www. version redirect to the correct URL with HTTPS.
For that matter, since certificates with Let's Encrypt support arbitrarily many SubjectAltName (SAN) values, you can include the www variant in the certificate, so that your redirect can use HTTPS and HSTS.
This happens with the https:// vary rarely. The http:// case happens more often. This is one of the complications in adding HSTS headers with includeSubDomains. Right now, the http:// version works as expected, but if we added HSTS with includeSubDomains for "wordpress.com" those URLs would stop working and generate a SSL error.
Somewhat related - if you have a mapped/custom domain on WordPress.com, even though we are strongly no-www[0] the "www" will work over HTTPS, assuming that DNS for the sub domain points to our servers[1]
I never understood why you can't get a wildcard cert for * . * .example.com. Then again, the whole concept of wildcart certs being priced differently is pure price segmentation, so that's to be expected.
I've always figured it was just unwillingness on people to implement the work required for that to happen. Inertia.
The "wildcard" certs' relevant RFCs are worded such that * . * .example.com isn't valid; one of the relevant RFCs restricts you to only 1 star in the leftmost component, so two stars is invalid.
There's a thing that you can put into a cert called "name constraints" that does have a syntax that allows you to say ".example.com", which allows things such as "foo.bar.example.com". It's valid on CA certs (it's oddly only valid on CA certs), which means that you could get a cert that was a CA cert for just your domain, and all subdomains. It'd be incredibly useful.
But no CA that I know of will issue them. Of the major browsers, only Firefox supports them. The whole Lets Encrypt thing makes it mostly a moot point though, since with Lets Encrypt you'd just obtain a non-CA cert for each specific domain.
(It'd still be useful, I think, to see it implemented, if only for restricting CAs to certain public suffixes, when/if that's appropriate.)
It's not price segmentation. You can encrypt X hosts with a wildcard cert, and X can be any number. So you basically buy encryption at a flat price, which can save you a LOT of money.
Fair enough; maybe the term isn't correct. My point is that a wildcart cert is technically no different than a 'regular' cert, and the CA incurs in no extra cost, unlike with EV certs. The price difference is purely based on the fact that buyers who need wildcart certs tend to have larger budgets.
can you get a second certificate? i'm not sure how the technology works, but since let's encrypt is free i think it could also be automated to solve this problem
Certificate authorities charge extra for it, of course they do. DigiCert brands this as "Multi-Domain (SAN) Certificate" and charges nearly $300/yr, while my choice provider, sslmate.com offers the same for $25/yr.
And now $0 certificates with Let's Encrypt, I'm sad to see sslmate.com's business hurt, as they are the first to provide no-bullshit sysadmin-focused CLI tools to get the job done. I'm very wishful to see DigiCert.com and others like it go bankrupt, however.
https://bestcrabrestaurantsinportland.wordpress.com/ works fine
https://www.bestcrabrestaurantsinportland.wordpress.com/ displays a certificate warning
Unfortunately I don't think there's a good solution for this. Humans are gonna www- things.