Post Syndicated from Let's Encrypt original https://letsencrypt.org/2016/04/01/legal-transparency-report.html

The trust of our users is ISRG’s most critical asset. Transparency regarding legal requests is an important part of making sure our users can trust us, and to that end we will be publishing reports twice annually. Reports will be published three months after the period covered in order to allow us time to research all requests and orders received during the period.

Download Legal Transparency Report, July 2015 – December 2015

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2016/03/09/le-client-new-home.html

Update: Added clarification that only the Let’s Encrypt client software is changing its name and host. The Let’s Encrypt certificate authority and associated services are not changing names or relocating.

Over the next few months the Let’s Encrypt client software will transition to a new name, soon to be announced, and a new home at the Electronic Frontier Foundation (EFF).

This change does not affect the Let’s Encrypt certificate authority (CA) or associated services, which will retain the Let’s Encrypt name and continue to be hosted by the Internet Security Research Group.

The goal of Let’s Encrypt is to make turning on HTTPS as easy as possible. To accomplish that, it’s not enough to fully automate certificate issuance on the certificate authority (CA) side – we have to fully automate on the client side as well. The Let’s Encrypt client is now being used by hundreds of thousands of websites and we expect it to continue to be a popular choice for sites that are run from a single server or VPS.

That said, the web server ecosystem is complex, and it would be impossible for any particular client to serve everyone well. As a result, the Let’s Encrypt community has created dozens of clients to meet many diverse needs. Moving forward, we feel it would be best for Let’s Encrypt to focus on promoting a generally healthy client and protocol ecosystem and for our client to move to the EFF. This will also allow us to focus our engineering efforts on running a reliable and rapidly growing CA server infrastructure.

The Let’s Encrypt client goes further than most other clients in terms of end-to-end automation and extensibility, both getting certificates and in many cases installing them. This is an important strategy since major servers don’t yet have built-in support, and we want to make sure it’s given a proper chance to thrive. The EFF has led development of the Let’s Encrypt client from the beginning, and they are well-qualified to continue pursuing this strategy.

The rename is happening for reasons that go beyond the move to the EFF. One additional reason for the rename is that we want the client to be distributable and customisable without having to create a complex process for deciding whether customized variants are appropriate for use with Let’s Encrypt trademarks. Another reason is that we want it to be clear that the client can work with any ACME-enabled CA in the future, not just Let’s Encrypt.

We expect the client to do well at the EFF and continue to be used by many people to get certificates from Let’s Encrypt.

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2016/03/08/our-millionth-cert.html

Let’s Encrypt has issued its millionth certificate. Our first million certificates are helping to secure approximately 2.4 million domains. This milestone means a lot to a team that started building a CA from scratch 16 months ago with an aim to have a real impact on the security of the Web as soon as possible.

We want to see HTTPS become the default on the Web, and today’s occasion gives us confidence that we’re going to get there – much faster than even we predicted. We’re growing at a current rate of more than 100,000 certificates per week and don’t see this slowing down anytime soon. This is dramatic and very rapid change for the Web.

Our rapid growth is due to strong demand for an easy-to-use, low-cost, widely trusted, and truly global solution for certificate issuance and management. We also received a considerable boost from industry endorsement, with major hosting companies like OVH, WordPress.com, Gandi, Dreamhost, and Digital Ocean helping many sites move to HTTPS with Let’s Encrypt.

HTTPS has been around for a long time but according to Firefox telemetry only ~40% of websites and ~65% of transactions used HTTPS at the end of 2015. Those numbers should both be 100% if the Web is to provide the level of privacy and security that people expect, and Let’s Encrypt is going to lead the way.

Let’s Encrypt depends on support from a wide variety of individuals and organizations. Please consider getting involved, and if your company or organization would like to sponsor Let’s Encrypt please email us at [email protected].

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/12/21/ovh-sponsorship.html

We’re pleased to announce that OVH has become a Platinum sponsor of Let’s Encrypt.

According to OVH CTO and Founder Octave Klaba, “OVH is delighted to become a Platinum sponsor. With Let’s Encrypt, OVH will be able to set a new standard for security by offering end-to-end encrypted communications by default to all its communities.”

The Web is an increasingly integral part of our daily lives, and encryption by default is critical in order to provide the degree of security and privacy that people expect. Let’s Encrypt’s mission is to encrypt the Web and our sponsors make pursuing that mission possible.

OVH’s sponsorship will help us to pay for staff and other operation costs in 2016.

If your company or organization would like to sponsor Let’s Encrypt, please email us at [email protected].

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/12/03/facebook-sponsorship.html

We’re happy to share today that Facebook is the newest Gold sponsor of Let’s Encrypt. Facebook has taken multiple important steps to support and advance encryption this year, and we are glad to see Let’s Encrypt as the latest example.

According to Alex Stamos, Chief Security Officer at Facebook, “Making it easier for websites to deploy HTTPS encryption is an important step in improving the security of the whole internet, and Facebook is proud to support this effort.”

Facebook’s sponsorship will help us produce a greater impact as we open up our public beta today and usher in more participants over the coming months.

If your company or organization would like to sponsor Let’s Encrypt, please email us at [email protected].

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/12/03/entering-public-beta.html

We’re happy to announce that Let’s Encrypt has entered Public Beta. Invitations are no longer needed in order to get free certificates from Let’s Encrypt.

It’s time for the Web to take a big step forward in terms of security and privacy. We want to see HTTPS become the default. Let’s Encrypt was built to enable that by making it as easy as possible to get and manage certificates.

We’d like to thank everyone who participated in the Limited Beta. Let’s Encrypt issued over 26,000 certificates during the Limited Beta period. This allowed us to gain valuable insight into how our systems perform, and to be confident about moving to Public Beta.

We’d also like to thank all of our sponsors for their support. We’re happy to have announced earlier today that Facebook is our newest Gold sponsor.

We have more work to do before we’re comfortable dropping the beta label entirely, particularly on the client experience. Automation is a cornerstone of our strategy, and we need to make sure that the client works smoothly and reliably on a wide range of platforms. We’ll be monitoring feedback from users closely, and making improvements as quickly as possible.

Instructions for getting a certificate with the Let’s Encrypt client can be found here.

Update: Feb. 10 2016, instructions for getting a certificate with Certbot (Let’s Encrypt recommended client) can be found here.

Let’s Encrypt Community Support is an invaluable resource for our community, we strongly recommend making use of the site if you have any questions about Let’s Encrypt.

Let’s Encrypt depends on support from a wide variety of individuals and organizations. Please consider getting involved, and if your company or organization would like to sponsor Let’s Encrypt please email us at [email protected].

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/11/12/public-beta-timing.html

Let’s Encrypt will enter Public Beta on December 3, 2015. Once we’ve entered Public Beta our systems will be open to anyone who would like to request a certificate. There will no longer be a requirement to sign up and wait for an invitation.

Our Limited Beta started on September 12, 2015. We’ve issued over 11,000 certificates since then, and this operational experience has given us confidence that our systems are ready for an open Public Beta.

It’s time for the Web to take a big step forward in terms of security and privacy. We want to see HTTPS become the default. Let’s Encrypt was built to enable that by making it as easy as possible to get and manage certificates.

We have more work to do before we’re comfortable dropping the beta label entirely, particularly on the client experience. Automation is a cornerstone of our strategy, and we need to make sure that the client works smoothly and reliably on a wide range of platforms. We’ll be monitoring feedback from users closely, and making improvements as quickly as possible.

Let’s Encrypt depends on support from a wide variety of individuals and organizations. Please consider getting involved, and if your company or organization would like to sponsor Let’s Encrypt please email us at [email protected].

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/11/09/why-90-days.html

We’re sometimes asked why we only offer certificates with ninety-day lifetimes. People who ask this are usually concerned that ninety days is too short and wish we would offer certificates lasting a year or more, like some other CAs do.

Ninety days is nothing new on the Web. According to Firefox Telemetry, 29% of TLS transactions use ninety-day certificates. That’s more than any other lifetime. From our perspective, there are two primary advantages to such short certificate lifetimes:

1. They limit damage from key compromise and mis-issuance. Stolen keys and mis-issued certificates are valid for a shorter period of time.
2. They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t continue to expect system administrators to manually handle renewals. Once issuance and renewal are automated, shorter lifetimes won’t be any less convenient than longer ones.

For these reasons, we do not offer certificates with lifetimes longer than ninety days. We realize that our service is young, and that automation is new to many subscribers, so we chose a lifetime that allows plenty of time for manual renewal if necessary. We recommend that subscribers renew every sixty days. Once automated renewal tools are widely deployed and working well, we may consider even shorter lifetimes.

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/10/29/phishing-and-malware.html

Since we announced Let’s Encrypt we’ve often been asked how we’ll ensure that we don’t issue certificates for phishing and malware sites. The concern most commonly expressed is that having valid HTTPS certificates helps these sites look more legitimate, making people more likely to trust them.

Deciding what to do here has been tough. On the one hand, we don’t like these sites any more than anyone else does, and our mission is to help build a safer and more secure Web. On the other hand, we’re not sure that certificate issuance (at least for Domain Validation) is the right level on which to be policing phishing and malware sites in 2015. This post explains our thinking in order to encourage a conversation about the CA ecosystem’s role in fighting these malicious sites.

CAs Make Poor Content Watchdogs

Let’s Encrypt is going to be issuing Domain Validation (DV) certificates. On a technical level, a DV certificate asserts that a public key belongs to a domain – it says nothing else about a site’s content or who runs it. DV certificates do not include any information about a website’s reputation, real-world identity, or safety. However, many people believe the mere presence of a DV certificate ought to connote at least some of these things.

Treating a DV certificate as a kind of “seal of approval” for a site’s content is problematic for several reasons.

First, CAs are not well positioned to operate anti­-phishing and anti-malware operations – or to police content more generally. They simply do not have sufficient ongoing visibility into sites’ content. The best CAs can do is check with organizations that have much greater content awareness, such as Microsoft and Google. Google and Microsoft consume vast quantities of data about the Web from massive crawling and reporting infrastructures. This data allows them to use complex machine learning algorithms (developed and operated by dozens of staff) to identify malicious sites and content.

Even if a CA checks for phishing and malware status with a good API, the CA’s ability to accurately express information regarding phishing and malware is extremely limited. Site content can change much faster than certificate issuance and revocation cycles, phishing and malware status can be page-specific, and certificates and their related browser UIs contain little, if any, information about phishing or malware status. When a CA doesn’t issue a certificate for a site with phishing or malware content, users simply don’t see a lock icon. Users are much better informed and protected when browsers include anti-phishing and anti-malware features, which typically do not suffer from any of these limitations.

Another issue with treating DV certificates as a “seal of approval” for site content is that there is no standard for CA anti­-phishing and anti-malware measures beyond a simple blacklist of high-­value domains, so enforcement is inconsistent across the thousands of CAs trusted by major browsers. Even if one CA takes extraordinary measures to weed out bad sites, attackers can simply shop around to different CAs. The bad guys will almost always be able to get a certificate and hold onto it long enough to exploit people. It doesn’t matter how sophisticated the best CA anti­-phishing and anti-malware programs are, it only matters how good the worst are. It’s a “find the weakest link” scenario, and weak links aren’t hard to find.

Browser makers have realized all of this. That’s why they are pushing phishing and malware protection features, and evolving their UIs to more accurately reflect the assertions that certificates actually make.

TLS No Longer Optional

When they were first developed in the 1990s, HTTPS and SSL/TLS were considered “special” protections that were only necessary or useful for particular kinds of websites, like online banks and shopping sites accepting credit cards. We’ve since come to realize that HTTPS is important for almost all websites. It’s important for any website that allows people to log in with a password, any website that tracks its users in any way, any website that doesn’t want its content altered, and for any site that offers content people might not want others to know they are consuming. We’ve also learned that any site not secured by HTTPS can be used to attack other sites.

TLS is no longer the exception, nor should it be. That’s why we built Let’s Encrypt. We want TLS to be the default method for communication on the Web. It should just be a fundamental part of the fabric, like TCP or HTTP. When this happens, having a certificate will become an existential issue, rather than a value add, and content policing mistakes will be particularly costly. On a technical level, mistakes will lead to significant down time due to a slow issuance and revocation cycle, and features like HSTS. On a philosophical and moral level, mistakes (innocent or otherwise) will mean censorship, since CAs would be gatekeepers for online speech and presence. This is probably not a good role for CAs.

Our Plan

At least for the time being, Let’s Encrypt is going to check with the Google Safe Browsing API before issuing certificates, and refuse to issue to sites that are flagged as phishing or malware sites. Google’s API is the best source of phishing and malware status information that we have access to, and attempting to do more than query this API before issuance would almost certainly be wasteful and ineffective. (Update: As of January 10, 2019, we no longer check domains against the Safe Browsing API.)

We’re going to implement this phishing and malware status check because many people are not comfortable with CAs entirely abandoning anti-phishing and anti-malware efforts just yet, even for DV certificates. We’d like to continue the conversation for a bit longer before we abandon what many people perceive to be an important CA behavior, even though we disagree.

Conclusion

The fight against phishing and malware content is an important one, but it does not make sense for CAs to be on the front lines, at least when it comes to DV certificates. That said, we’re going to implement checks against the Google Safe Browsing API while we continue the conversation.

We look forward to hearing what you think. Please let us know.

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/10/19/lets-encrypt-is-trusted.html

We’re pleased to announce that we’ve received cross-signatures from IdenTrust, which means that our certificates are now trusted by all major browsers. This is a significant milestone since it means that visitors to websites using Let’s Encrypt certificates can enjoy a secure browsing experience with no special configuration required.

Both Let’s Encrypt intermediate certificates, Let’s Encrypt Authority X1 and Let’s Encrypt Authority X2, received cross-signatures. Web servers will need to be configured to serve the appropriate cross-signature certificate as part of the trust chain. The Let’s Encrypt client will handle this automatically.

You can see an example of a server using a Let’s Encrypt certificate under
a new cross-signed intermediate here.

Vital personal and business information is flowing over the Internet more frequently than ever, and it’s time to encrypt all of it. That’s why we created Let’s Encrypt, and we’re excited to be one big step closer to bringing secure connections to every corner of the Web.

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/10/08/isoc-sponsors-lets-encrypt.html

We’re pleased to announce that Internet Society (ISOC) has become a Gold sponsor of Let’s Encrypt.

According to Olaf Kolkman, “The Internet Society sees encryption as a new norm to enhance the security of, and thereby trust in, the Internet.” We couldn’t agree more.

Internet Society’s sponsorship comes at a key time, and will help us to pay for staff and other operation costs as we move from our beta program into general availability.

If your company or organization would like to sponsor Let’s Encrypt, please email us at [email protected].

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/09/14/our-first-cert.html

Let’s Encrypt passed another major milestone by issuing our first certificate. You can see it in action here.

Our cross signature is not yet in place, however this certificate is fully functional for clients with the ISRG root in their trust store. When we are cross signed, approximately a month from now, our certificates will work just about anywhere while our root propagates. We submitted initial applications to the root programs for Mozilla, Google, Microsoft, and Apple today.

We’re thrilled to finally be a live CA. We’ll be working towards general availability over the next couple of months by issuing certificates to domains participating in our beta program. You can request that your domain be included in our beta program by clicking here.

If you want to get involved with Let’s Encrypt, please visit this page.

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/08/13/lets-encrypt-community-support.html

Let’s Encrypt’s success depends on a strong community. Nowhere is this more true than when it comes to subscriber support. Today we’re happy to announce Let’s Encrypt Community Support, a place for our community to both give and receive support.

We’re a small organization hoping to help a large portion of the Web move to HTTPS. Many people are going to have questions during the transition, and we need to be able to provide answers. Hiring an army of support staff is out of the question for us, but we’re not convinced that would be the way to go anyway, even if we could afford it.

Clay Shirky once said that you’ll make more accurate predictions about the quality and longevity of services in a Web-driven world “if you ask yourself not what’s the business model, but rather do the people who like it take care of each other?”

No amount of staffing could provide the level of support that a strong community of fellow users is capable of providing. We sincerely hope that our users will join us in taking care of each other.

We’d like to thank Discourse for providing the Let’s Encrypt Community Support platform and hosting.

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/08/07/updated-lets-encrypt-launch-schedule.html

We can’t wait to see websites turn on TLS with Let’s Encrypt. Trust is our most important asset, however, and we need to take the necessary time to make sure our systems are secure and stable.

We’ve decided to push our launch schedule back a bit to give us time to further improve our systems. Our new schedule is:

• First certificate: Week of September 7, 2015
• General availability: Week of November 16, 2015

In the ten weeks between these two dates we’ll gradually issue more and more certificates. We’ll start by issuing a small number of certs to whitelisted domains and expand our issuance as we gain confidence in our systems (stay tuned for instructions on getting your domains added to our early-access whitelist). When it’s time for general availability we will open up our systems to all requests.

A cross-signature will be in place before general availability. This will allow certificates from Let’s Encrypt to validate automatically for the vast majority of consumers. Prior to cross-signing, browsers will not accept our certificates as valid unless a user has installed our root as trusted.

I want to thank our staff, partners, sponsors, and contributors. We’re making great progress, despite this delay, and it’s all possible due to their hard work.

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/07/01/legal-transparency-report.html

The trust of our users is ISRG’s most critical asset. Transparency regarding legal requests is an important part of making sure our users can trust us, and to that end we will be publishing reports twice annually. With the exception of this first report, reports will be published three months after the period covered in order to allow us time to research all requests and orders received during the period.

Download Legal Transparency Report, January 2015 – June 2015

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/06/16/lets-encrypt-launch-schedule.html

Let’s Encrypt has reached a point where we’re ready to announce our launch schedule.

• First certificate: Week of July 27, 2015
• General availability: Week of September 14, 2015

We will issue the first end entity certificates under our root under tightly controlled circumstances. No cross-signature will be in place yet, so the certificates will not validate unless our root is installed in client software. As we approach general availability we will issue more and more certificates, but only for a pre-approved set of domains. This limited issuance period will give us time to further ensure that our systems are secure, compliant, and scalable.

When it’s time for general availability, we will open up our systems to certificate requests for any domain. A cross-signature from IdenTrust will be in place for general availability, so that our certificates will validate automatically for the vast majority of consumers.

Engineering and policy development for Let’s Encrypt began in earnest in mid-October of 2014. If we stay true to the schedule outlined above we will have built an innovative CA, capable of operating at Internet scale and without cutting corners, in just eleven months. That’s quite a feat, given all that’s involved, and a testament to the skill and dedication of our staff, partners, sponsors, and contributors.

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/06/04/isrg-ca-certs.html

The keys and certificates that will underlie Let’s Encrypt have been generated. This was done during a key ceremony at a secure facility today. The following objects were created:

• Key pair and self-signed cert for the ISRG root
• Key pair and certificate for the ISRG root’s OCSP
• Key pairs and certificates for two Let’s Encrypt intermediate CAs
• CRL under the ISRG root showing that the Let’s Encrypt intermediates have not been revoked

The certificates over the public keys, of course, can be made public:

• ISRG Root X1 Certificate
• Let’s Encrypt Intermediate X1 CA Certificate
• Let’s Encrypt Intermediate X2 CA Certificate

Let’s Encrypt will issue certificates to subscribers from its intermediate CAs, allowing us to keep our root CA safely offline. IdenTrust will cross-sign our intermediates. This will allow our end certificates to be accepted by all major browsers while we propagate our own root.

Under normal circumstances, certificates issued by Let’s Encrypt will come from “Let’s Encrypt Intermediate X1”. The other intermediate, “Let’s Encrypt Intermediate X2”, is associated with our disaster recovery site and will only be used should we lose the ability to issue with “Let’s Encrypt Intermediate X1”.

The private keys for the ISRG root CA and the Let’s Encrypt intermediate CAs are stored on hardware security modules (HSMs), which provide a high degree of protection against the keys being stolen.

All ISRG keys are currently RSA keys. We are planning to generate ECDSA keys later this year.

The generation of these keys and certificates is an important step in getting Let’s Encrypt ready to issue certificates. In the next few weeks, we’ll be saying some more about our plans for going live. In the mean time, we would love for you to get involved.

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/05/21/draft-le-sa.html

Update 2015-10-12: These documents are now out of date. Please visit our Policy and Legal Repository for
up-to-date documents.

Today we’re publishing the first public draft of the Let’s Encrypt Subscriber Agreement. We’ve attempted to create terms that are sensible for both our organization and our subscribers, and we want to give people a chance to review them before we start issuing certificates. Please let us know if you have any questions or comments.

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/04/23/draft-isrg-cp-cps.html

Update 2015-10-12: These documents are now out of date. Please visit our Policy and Legal Repository for
up-to-date documents.

Today we’re publishing an updated draft of our Certificate Policy (CP) and the first public draft of our Certification Practice Statement (CPS). These are important documents for any Certificate Authority (CA), and we want to give people a chance to review ours before we start issuing certificates. Please let us know if you have any questions or comments.

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2015/04/14/ncc-group-audit.html

ISRG has engaged the NCC Group Crypto Services team to perform a security review of Let’s Encrypt’s certificate authority software, boulder, and the ACME protocol. NCC Group’s team was selected due to their strong reputation for cryptography expertise, which brought together Matasano Security, iSEC Partners, and Intrepidus Group.

The NCC Group audit will take place prior to the general availability of Let’s Encrypt’s service, and is intended to provide additional assurance that our systems are secure. The NCC Group audit does not replace the WebTrust audit, which will happen after general availability.

“I’m very much looking forward to the general availability of Let’s Encrypt – lowering the bar both technically and financially for people to deploy TLS will result in a more encrypted Internet that helps increase security and preserve people’s privacy,” said Tom Ritter, Practice Director, NCC Group.

Let’s Encrypt’s certificate authority software is called boulder. It’s largely written in the go language and makes use of CloudFlare’s CFSSL tools, which are also written in go. Our boulder software contains modules including a web front-end and registration, validation, certificate, and storage authorities.

ACME, short for Automated Certificate Management Environment, is the protocol that Let’s Encrypt will use for automatic certificate issuance and management. We hope to standardize ACME in the IETF, starting with the formation of a working group later this year.