Arstechnica reports
In July of 2017, the nonprofit certificate authority Let's Encrypt promised to deliver something that would put secure websites and Web applications within reach of any Internet user: free "wildcard" certificates to enable secure HTTP connections for entire domains. Today, Let's Encrypt took that promised service live, in addition to a new version of the Automated Certificate Management Environment (ACME) protocol, an interface that can be used by a variety of client software packages to automate verification of certificate requests.
[....]Many hosting providers already support the registration of Let's Encrypt certificates to varying degrees. But Let's Encrypt's free certificate offering hasn't been snapped up by some larger hosting providers—such as GoDaddy—who also sell SSL certificates to their customers.
(Score: 2) by Thexalon on Wednesday March 14 2018, @06:13PM (4 children)
It's a significant convenience.
For instance, imagine this scenario: You run example.com, and you want the canonical URL of your website to be "https://example.com/", but you know that there are also links out there to www.example.com, info.example.com, web.example.com, etc. In the event that somebody goes to those domains, you want a 301 redirect to the canonical version. Now, when you're setting up the webserver, in the non-wildcarded world you have to have a separate configuration for each of those domains when accessed on port 443, whereas in with a wildcard you can just say the equivalent of "Didn't match the canonical name, redirect."
As far as safety goes, basic wildcard certs verify exactly what non-wildcard certs verify, namely that you can make modifications to your DNS or to a server that is referenced by DNS. If a Bad Guy can monkey with your DNS, you're already screwed.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Wednesday March 14 2018, @08:13PM (3 children)
example.com != *.example.com
Most browsers and applications that perform certificate verification will not trust example.com if it is using the *.example.com certificate, meaning you need at least two certs, one for the second level domain, and one for the wildcarded subdomains.
Really the only time you should be using wildcards would be for dynamically generated cached proxies where you need to give the pool a temporary certificate while not actually trusting any of them with the 'primary' certificate for the website in case of compromise. But practically speaking nobody ever does that. Nor using smartcards or a secured high speed encryption processor with the keychain write/erase only with the hash as the only user facing way to interact with it (Essentially what TPM was supposed to allow, but controlled by the end user instead of the corporations and possible government agents.)
The current solutions are weak at best.
(Score: 2) by bryan on Wednesday March 14 2018, @10:11PM (1 child)
Not true. For example, I have a wildcard cert for "*.pipedot.org" and if I type "https://pipedot.org/" into my browser I most certainly will see a valid cert regardless of if I use the base domain or a second level like "https://bryan.pipedot.org/"
You are correct, however, on further subdomains beyond the first level. For example, I would need another wildcard cert for "*.dev.pipedot.org" if I wanted to match "https://bryan.dev.pipedot.org/"
(Score: 3, Informative) by bryan on Wednesday March 14 2018, @10:24PM
TLDR: Set the Subject Alternative Name Field [wikipedia.org] to "*.example.com, example.com" so you can do both in the same cert.
(Score: 0) by Anonymous Coward on Thursday March 15 2018, @09:27AM
So, since you don't think a wildcard certificate is the correct solution, how would *you* set it up such that *.example.com redirects to example.com?