Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Wednesday March 14 2018, @02:16PM   Printer-friendly
from the simple-cypers dept.

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by Thexalon on Wednesday March 14 2018, @06:13PM (4 children)

    by Thexalon (636) on Wednesday March 14 2018, @06:13PM (#652533)

    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.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 0) by Anonymous Coward on Wednesday March 14 2018, @08:13PM (3 children)

    by Anonymous Coward on Wednesday March 14 2018, @08:13PM (#652573)

    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)

      by bryan (29) <bryan@pipedot.org> on Wednesday March 14 2018, @10:11PM (#652634) Homepage Journal

      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.

      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: 0) by Anonymous Coward on Thursday March 15 2018, @09:27AM

      by Anonymous Coward on Thursday March 15 2018, @09:27AM (#652857)

      Really the only time you should be using wildcards would be for dynamically generated cached proxies

      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?