Let’s Encrypt – Making the Internet That Little Bit Securer Every Day
a free, automated, open source certificate authority
Launched in 2014 by the Electronic Frontier Foundation, the University of Michigan, and Mozilla, the Let’s Encrypt project recently issued its 100 millionth automated, free certificate and is thus truly living up to its slogan of “Encrypt the entire web”.
In the aftermath of the Snowdon revelations of 2013, Let’s Encrypt declared its goal of making SSL/TLS certificates available for everyone on the Internet and promoting free encryption on the web. Since then, the project has won over a wide range of notable companies and acquired sponsors such as Akamai and Cisco as well as most recently Netflix.
The project aims to keep the administrative efforts required of the user as low as possible. With minimal configuration, it should be possible to put an HTTPS server in a position to request certificates autonomously.
The new Let’s Encrypt App for UCS is also based on this maxim and is covered in more detail later in this article.
How Let’s Encrypt Works – Automated and Transparent
One decisive aspect of the design of Let’s Encrypt’s infrastructure is a completely automated process for the creation and verification of a requested certificate and complete transparency with regard to these transactions. This makes it possible to view who requested a certificate for which domain at any time so as to avoid abuse.
The technology behind it – ACME-based keys and challenges for the clients
From a technological perspective, Let’s Encrypt is based on the ACME protocol. ACME stands for Automated Certificate Management Environment and was designed for Let’s Encrypt by the Internet Security Research Group (ISRG). It is based on JSON and HTTPS and has already been implemented in clients of various forms.
Image Source: www.letsencrypt.org
The ACME client generates an authorized pair of keys for the respective domain in cooperation with the Let’s Encrypt project’s servers. This pair of keys is then entitled to request or revoke a certificate for the domain. If the pair of keys is registered with Let’s Encrypt, the client generates a certificate signing request (CSR), signs it with its key, and sends it to Let’s Encrypt. The Let’s Encrypt servers then select a challenge that the client has to complete. For example, this might be: Save file “x” on your web server with the content “y”. As soon as the client reports that it has completed the challenge, Let’s Encrypt checks whether it has done so successfully (in this case, whether file “x” can be found on the requested domain with the content “y”.
Wide Range of Validation Options for Added Flexibility
If the validation is successful, the client receives its certificate and can be included in the web server Apache or IMAP server Dovecot.
Although validation via a specific file on the web server of the requesting host is by far the most used and implemented, there is also the option of validation via DNS among others. However, this is not possible with all clients and requires the manual creation of a TXT record in the DNS of the domain for which a certificate is requested. One client which supports this form of validation is Let’s Encrypt’s official “certbot”, for example.
Internally, Let’s Encrypt works with a root certificate, which signs both intermediate certificates. One of these two intermediate certificates then signs all the automatically issued certificates.
Once a certificate has been initially issued, the majority of clients work with mechanisms such as Cron to retrieve a new certificate automatically following a schedule. This is because the certificates issued by Let’s Encrypt are generally only valid for 90 days so as to render (long-term) misuse of keys and certificates more difficult and promote automation of the process among users.
Integration of a Let’s Encrypt Client in UCS for the Creation of Secure Certificates
In the scope of the Cool Solutions, Univention offers a largely automated integration of a Let’s Encrypt client, which has recently been made available in the App Center. Following the installation of the “Let’s Encrypt” app in UCS 4.2, the app settings in the App Center can be used to enter the desired domains and configure the use of the certificate in Apache, Dovecot, and Postfix. Clicking on “Save Changes” starts a script which retrieves the certificate and configures it in the respective services. And that’s it – setup is complete! A Cron job set up during the installation ensures that a new certificate is retrieved every 30 days so that there is always a valid certificate available in the system. The app uses the client implementation “acme-tiny” and validates the domain with the help of the classic method of a special file which is provided to the Let’s Encrypt servers via the Apache web service.
Outlook: A Little Bit More Security for the Web Every Day
Although Let’s Encrypt has already contributed significantly to the “fully encrypted web” with 100 million certificates, the project is by no means drawing to a standstill. For example, support for wildcard certificates was announced just recently and should be available from January 2018. This and further developments such as the IPv6 support incorporated in mid-2016 will make free certificates available for more and more people and render the web a little bit more secure day by day. In February of this year, the EFF reported that half of the traffic on the world wide web is now encrypted. In view of the continuously growing number of domains encrypted with Let’s Encrypt, a healthy optimism with regard to this development is therefore thoroughly justified. In particular in the course of the consistent expansion of Internet monitoring by internationally operating secret services and the monopolization of services used by the masses by corporations such as Facebook, Open Source-based, democratizing projects such as Let’s Encrypt are essential for the continued existence of a free and fair Internet.
Der Beitrag Let’s Encrypt – Making the Internet That Little Bit Securer Every Day erschien zuerst auf Univention.
22 September, 2017 10:40AM by Irina Feller
Except where otherwise noted, content in this issue is licensed under a Creative Commons Attribution 3.0 License BY SA 
Orinda, CA/San Francisco, September 19, 2017 – The 
$218, Benedikt R.
$200 (5th donation), Radomír Č.
$200 (2nd donation), B
$109 (2nd donation), DvW informatiemanagement en advies
$109, 
$109, Sandro P.
$109, Norbert J.
$109, Martin L.
$100, Friedrich A. C.
$54 (2nd donation), J. F. .
$54, 
$54, Miguel V.
$54, Angel M. A.
$50 (3rd donation), TehGhodTrole
$50 (2nd donation), Jesper D.
$50, Thomas P.
$50, Sebastian aka “Seb”
$38 (2nd donation), Bjarte O.
$35 (3rd donation), Borisov G. aka “
$33 (90th donation), Olli K.
$33 (2nd donation), Sachindra Prosad Saha aka “Love you grand dad”
$33, Anestis P.
$30 (4th donation), Anonymous User
$30, יוסף כהן
$25 (5th donation), Charles W.
$22 (2nd donation), Nicolaas V. D. R.
$22, Bernhard J.
$22, Borut K.
$22, Ovidiu F.
$22, Tony M.
$20, RRKMAT
$20, Robert T.
$20, Franco C. M.
$20, 
$15, Hans G. H.
$11 (4th donation), Manuel C. aka “Manel”
$11 (2nd donation), Andrew R.
$10 (4th donation), Agenor Marrero
$10 (3rd donation), Don Bhrayan
$10 (2nd donation), Felipe L. L. aka “Neubius”
$10 (2nd donation), Horacio R.
$10, Josme A. D. S.
$5 (4th donation), NAGY Attila aka “GuBo”
$5 (4th donation), J. S. .
$5, Edwin S.
$5, Wiryanto Y.
Like 
Berlin/San Francisco, September 14, 2017 — 
![[RSS 1.0 Feed]](common/rss10.png){kind=small}
![[RSS 2.0 Feed]](common/rss20.png){kind=small}
![[Atom Feed]](common/atom.png){kind=small}
![[FOAF Subscriptions]](common/foaf.png){kind=small}
![[OPML Subscriptions]](common/opml.png){kind=small}
![[Hacker]](common/hacker.png){kind=small}
![[Planet]](common/planet.png){kind=small}
_edit.jpg){kind=link}
