Today the Let’s Encrypt initiative has announced that only 3 months after opening to the public, 1 million certificates for encrypting web traffic have been issued. 90% of the sites for which certificates have been requested did not encrypt their traffic before. In other words Let’s Encrypt’s mission to foster adoption of HTTPS by making it simple to get a certificate is working very well indeed!
This, by the way, also applies to this web site as I also use a Let’s Encrypt SSL certificate! I’ve previously hosted this blog at Typepad and one of the many reasons to leave was to get my site’s data traffic properly encrypted during transport. One nice side effect of this is that I no longer need to establish a VPN tunnel to write posts during my daily commute as everything is encrypted now.
Congratulations to Let’s Encrypt!
Thanks.
Site authentication and security/site cert have been among aspects of the Internet that have made it overly complex, difficult to maintain and expensive.
Besides, the complexity of issuing and maintaining encryption certificates is the lack of early standards focus on the ease of use issue.
Letsencrypt looks straightforward for web domain certs. However, the support for the various environments including documentation is shallow. I installed it on a Centos 6 VPS running NGINX. Then generated a cert for multiple domains on the server. I got an error message for a couple of domains, (won’t go into details here), yet it looks like the cert was created.
The documentation is unclear if NGINX is supported or is just planned.
Reading comments and blogs including on the letsencrypt site, there is a lot of confusion out there: some people confuse domain cert with business certification. Domain that is used for e-commerce, for example, can be used on a domain/sub-domains but that only certifies that the issuer has verified the party executing the request has root authority/rights for that domain(s). It does not certify the entity/business using the domain. Users to e-commerce or other sites that hope to have their information kept secure can’t rely on that level of cert.
The solution is a validation of individual and corporate entities which carries a higher level of process complexity than can be generated by installing an ap on a web server. The corporate or personal identity must be verified, usually involving the exchange of documents proving the identity of the requesting party.
Although its blowing in the wind: what if domain certs were based on other factors such as longevity of ownership? That type of domain-tied information would not be proof of trust of a merchant.. but then more than a few eCommerce sites with ‘valid’ companies behind them have gone out of business, leaving unpaid bills or unsent products. A relatively simple data-connect to site certification would be how long the domain is owned and, going one step further, that the party who owns the domain rights is the same as that providing the software, products, service, etc. offered on the domain.
Engineers combined with middle-level and higher management can take what should be simple, logical approaches and turn them into overly complex, badly documented sore spots… that enrich some fellow idiots unduly while making a life for the multitudes of users a big hassle.
The cert process is among the best examples that we are only remotely removed from being cave dwellers hitting each other over our heads with clubs.