Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 15 submissions in the queue.
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: 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?