Let’s Encrypt - A free certificate authority from the EFF, Mozilla, Akamai and Cisco

[Arthur]

I hope more hardware manufacturers follow Synology's lead...

 

Synology is testing the first hardware integration of Let’s Encrypt’s free SSL certificates

 

Now, just a few weeks after it became generally available, Synology is about to become the first hardware manufacturer to integrate it into its platform.

 

As part of the company’s DSM 6.0 beta, it’s added the ability to secure your NAS device with a Let’s Encrypt free security certificate rather than Synology’s own self-signed one.

[Arthur]

WordPress.com turns on HTTPS encryption for all websites

 

Today we are excited to announce free HTTPS for all custom domains hosted on WordPress.com. This brings the security and performance of modern encryption to every blog and website we host.

 

Best of all, the changes are automatic — you won’t need to do a thing.

 

As the EFF points out as part of their Encrypt the Web initiative, strong encryption protects our users in various ways, including defending against surveillance of content and communications, cookie theft, account hijacking, and other web security flaws.

 

The Let’s Encrypt project gave us an efficient and automated way to provide SSL certificates for a large number of domains. We launched the first batch of certificates in January 2016 and immediately started working with Let’s Encrypt to make the process smoother for our massive and growing list of domains.

 

For you, the users, that means you’ll see secure encryption automatically deployed on every new site within minutes. We are closing the door to unencrypted web traffic (HTTP) at every opportunity.

Edited April 9, 2016 by Arthur

[Arthur]

Announcing Certbot: EFF's Client for Let's Encrypt

 

EFF is proud to introduce Certbot, a powerful tool to help websites encrypt their traffic. Certbot is the next iteration of the Let's Encrypt Client; it obtains TLS/SSL certificates and can automatically configure HTTPS encryption on your server. It's still in beta for now, but we plan to release Certbot 1.0 later this year.

 

Certbot communicates with the Let’s Encrypt CA through a protocol called ACME. While there are many ACME clients available to choose from, Certbot continues to be the most popular choice for organizations and developers that run their own webservers.

 

[Meldrew]

With our wildcard certificate expiring early September I've just implemented this here. I've used the LetsEncrypt-win-simple. Once you get your head around it, it works a treat. The only problems I had were firewall related. A couple of our sites had 443 only allowed through, so had to add 80 in order for the checks to be made. No more messing around every year updating the certificate on all the servers, now it should just happen automatically, once every 60 days. I have however added a reminder for our calendar to check in 2 months that it's worked properly!

 

Can definitely recommend.

 

Meldrew

[DMcCoy]

For anyone using this for mail. Just FYI that lets encrypt is *not* trusted by the cloud servers that do the bits in the middle for the Outlook android app. No way around it either, had to switch back to a real cert after several hours of getting it working and automated.

[Arthur]

https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html

 

Let’s Encrypt will begin issuing wildcard certificates in January of 2018. Wildcard certificates are a commonly requested feature and we understand that there are some use cases where they make HTTPS deployment easier. Our hope is that offering wildcards will help to accelerate the Web’s progress towards 100% HTTPS.

 

Let’s Encrypt is currently securing 47 million domains via our fully automated DV certificate issuance and management API. This has contributed heavily to the Web going from 40% to 58% encrypted page loads since Let’s Encrypt’s service became available in December 2015. If you’re excited about wildcard availability and our mission to get to a 100% encrypted Web, we ask that you contribute to oursummer fundraising campaign.

 

A wildcard certificate can secure any number of subdomains of a base domain (e.g. *.example.com). This allows administrators to use a single certificate and key pair for a domain and all of its subdomains, which can make HTTPS deployment significantly easier.

 

Wildcard certificates will be offered free of charge via ourupcoming ACME v2 API endpoint. We will initially only support base domain validation via DNS for wildcard certificates, but may explore additional validation options over time. We encourage people to ask any questions they might have about wildcard certificate support on ourcommunity forums.

 

We decided to announce this exciting development during our summer fundraising campaign because we are a nonprofit that exists thanks to the generous support of the community that uses our services. If you’d like to support a more secure and privacy-respecting Web,donate today!

[tommej]

Stuck the thread as this is too important to get buried.

 

Ben

 

Yet edugeek is not secure

[MrKJLS]

Yet edugeek is not secure

 

Shots fired.

 

Take a look here http://www.edugeek.net/forums/comments-suggestions/155878-edugeek-v2-2.html

[Arthur]

ACME Support in Apache HTTP Server Project (mod_md for Windows)

 

We’re excited that support for getting and managing TLS certificates via the ACME protocol is coming to the Apache HTTP Server Project (httpd). ACME is the protocol used by Let’s Encrypt, and hopefully other Certificate Authorities in the future. We anticipate this feature will significantly aid the adoption of HTTPS for new and existing websites.

 

We created Let’s Encrypt in order to make getting and managing TLS certificates as simple as possible. For Let’s Encrypt subscribers, this usually means obtaining an ACME client and executing some simple commands. Ultimately though, we’d like for most Let’s Encrypt subscribers to have ACME clients built in to their server software so that obtaining an additional piece of software is not necessary. The less work people have to do to deploy HTTPS the better!

 

ACME support being built in to one of the world’s most popular Web servers, Apache httpd, is great because it means that deploying HTTPS will be even easier for millions of websites. It’s a huge step towards delivering the ideal certificate issuance and management experience to as many people as possible.

 

The Apache httpd ACME module is called mod_md. It’s currently in the development version of httpd and a plan is being formulated to backport it to an httpd 2.4.x stable release. The mod_md code is also available on GitHub.

 

It’s also worth mentioning that the development version of Apache httpd now includes support for an SSLPolicy directive. Properly configuring TLS has traditionally involved making a large number of complex choices. With the SSLPolicy directive, admins simply select a modern, intermediate, or old TLS configuration, and sensible choices will be made for them.

 

Development of mod_md and the SSLPolicy directive has been funded by Mozilla and carried out primarily by Stefan Eissing of greenbytes. Thank you Mozilla and Stefan!

[Arthur]

ACMEv2 and Wildcard Launch Delay

 

We previously communicated that we would launch ACMEv2 and wildcard certificate support on 27th February. ACMEv2 and wildcard support is nearly ready but we will be delaying the full launch in order to give our teams more time to complete testing and quality assurance activities. While we work hard to hit deadlines, we are inclined to prioritize a quality release over hitting a deadline.

 

The biggest reason for this delay is the recent TLS-SNI deprecation. This unexpectedly pulled most engineering resources away from ACMEv2 and wildcard support for approximately two weeks.

 

We introduced a public test API endpoint for the ACME v2 protocol and wildcard support on 4 January 2018. Thank you to everyone who has provided feedback on the staging endpoint.

 

We will provide updates here weekly and encourage client developers to continue to utilize the staging endpoint to prepare for ACMEv2 and wildcard issuance.

[Arthur]

Wildcard certificates are finally available...

 

https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579

 

We’re pleased to announce that ACMEv2 and wildcard certificate support is live! With today’s new features we’re continuing to break down barriers for HTTPS adoption across the Web by making it even easier for every website to get and manage certificates.

 

ACMEv23 is an updated version of our ACME protocol which has gone through the IETF standards process, taking into account feedback from industry experts and other organizations that might want to use the ACME protocol for certificate issuance and management some day.

 

Wildcard certificates allow you to secure all subdomains of a domain with a single certificate. Wildcard certificates can make certificate management easier in some cases, and we want to address those cases in order to help get the Web to 100% HTTPS. We still recommend non-wildcard certificates for most use cases.

 

Wildcard certificates are only available via ACMEv2. In order to use ACMEv2 for wildcard or non-wildcard certificates you’ll need a client that has been updated to support ACMEv2. It is our intent to transition all clients and subscribers to ACMEv2, though we have not set an end-of-life date for our ACMEv1 API yet.

 

Additionally, wildcard domains must be validated using the DNS-01 challenge type. This means that you’ll need to modify DNS TXT records in order to demonstrate control over a domain for the purpose of obtaining a wildcard certificate.

 

For more technical information about ACMEv2 and wildcard certificates, see this post.

 

We’re excited about the prospect of a 100% HTTPS Web and we’re working hard to get there. As a non-profit organization, we need strong support from our community so please consider getting involved, making a donation, or sponsoring Let’s Encrypt.

Edited March 13, 2018 by Arthur

[Arthur]

Custom domains on GitHub Pages gain support for HTTPS

 

GitHub Pages is the best way to quickly publish beautiful websites for you and your projects. Just edit, push, and your changes are live. GitHub Pages has supported custom domains since 2009, and sites on the *.github.io domain have supported HTTPS since 2016. Today, custom domains on GitHub Pages are gaining support for HTTPS as well, meaning over a million GitHub Pages sites will be served over HTTPS.

 

We have partnered with the certificate authority Let’s Encrypt on this project. As supporters of Let’s Encrypt’s mission to make the web more secure for everyone, we’ve officially become Silver-level sponsors of the initiative.

[Arthur]

Let's Encrypt Root Trusted By All Major Root Programs

 

As of the end of July 2018, the Let’s Encrypt root, ISRG Root X1, is directly trusted by Microsoft products. Our root is now trusted by all major root programs, including Microsoft, Google, Apple, Mozilla, Oracle, and Blackberry.

 

Today’s announcement that we’re trusted by all major root programs represents a major milestone for us, but it’s not the conclusion of our journey towards being directly trusted everywhere.

 

Certificates from Let’s Encrypt have been widely trusted since our first issuance because of a cross-signature from another CA called IdenTrust. Browsers and operating systems have not, by default, directly trusted Let’s Encrypt certificates, but they trust IdenTrust, and IdenTrust trusts us, so we are trusted indirectly. IdenTrust is a critical partner in our effort to secure the Web, as they have allowed us to provide widely trusted certificates from day one.

 

While Let’s Encrypt is now directly trusted by almost all newer versions of operating systems, browsers, and devices, there are still many older versions in the world that do not directly trust Let’s Encrypt. Some of those older systems will eventually be updated to trust Let’s Encrypt directly. Some will not, and we’ll need to wait for the vast majority of those to cycle out of the Web ecosystem. We expect this will take at least five more years, so we plan to use a cross signature until then.

[Arthur]

Transitioning to ISRG's Root

 

On 8 July 2019, we will change the default intermediate certificate we provide via ACME. Most subscribers don’t need to do anything. Subscribers who support very old TLS/SSL clients may want to manually configure the older intermediate to increase backwards compatibility.

 

Since Let’s Encrypt launched, our certificates have been trusted by browsers via a cross-signature from another Certificate Authority (CA) named IdenTrust. A cross-signature from IdenTrust was necessary because our own root was not yet widely trusted. It takes time for a new CA to demonstrate that it is trustworthy, then it takes more time for trusted status to propagate via software updates.

 

Now that our own root, ISRG Root X1, is widely trusted by browsers we’d like to transition our subscribers to using our root directly, without a cross-sign.

 

On 8 July 2019, Let’s Encrypt will start serving a certificate chain via the ACME protocol which leads directly to our root, with no cross-signature. Most subscribers don’t need to take any action because their ACME client will handle everything automatically. Subscribers who need to support very old TLS/SSL clients may wish to manually configure their servers to continue using the cross-signature from IdenTrust. You can test whether a given client will work with the newer intermediate by accessing our test site.

 

Our current cross-signature from IdenTrust expires on 17 March 2021. The IdenTrust root that we are cross-signed from expires on 30 September 2021. Within the next year we will obtain a new cross-signature that is valid until 29 September 2021. This means that our subscribers will have the option to manually configure a certificate chain that uses IdenTrust until 29 September 2021.

 

We’d like to thank IdenTrust for providing a cross-signature while we worked to get our own root trusted. They have been wonderful partners. IdenTrust believed in our mission to encrypt the entire Web when it seemed like a long-term dream. Together, in less than five years, we have helped to raise the percentage of encrypted page loads on the Web from 39% to 78%.

[3s-gtech]

LE has now replaced all of our commercial certificates. The financial saving is small - we only had three publicly accessible IPs - but it has hugely reduced hassle because renewing is either automatic or simply running a script manually. It’s fantastic.

[mavhc]

LE has now replaced all of our commercial certificates. The financial saving is small - we only had three publicly accessible IPs - but it has hugely reduced hassle because renewing is either automatic or simply running a script manually. It’s fantastic.

 

Now if they could just extend it to s/mime certs for email, then people could actually start doing secure email, put all those stupid "secure" email companies out of business

[MS2011]

Has anyone used let’s encrypt for moodle running on windows server ?

[mavhc]

Has anyone used let’s encrypt for moodle running on windows server ?

 

Using which http server?

[MS2011]

Web server, running on IIS

[MS2011]

I did looked on moodle.org and it does support https

[3s-gtech]

Our Moodle uses LE on IIS. Works fine.

[mavhc]

https://github.com/PKISharp/win-acme

[bknaggs]

Has anyone successfully automated installing a certificate into Remote Desktop? I tried running win-acme yesterday and now have a new certificate in IIS and a scheduled task to renew but nothing changed in Remote Desktop.

[3s-gtech]

You’ll almost certainly have to script in Powershell to install the cert into RDS, then schedule that task. That’s how it works for Exchange.

[MS2011]

You’ll almost certainly have to script in Powershell to install the cert into RDS, then schedule that task. That’s how it works for Exchange.

 

How did you done for it for exchange ?