Let’s Encrypt Overview


What is Let’s Encrypt?

Basically, it’s a way to get a quick x509 certificate for your server without knowing much about what is a x509 certificate:

You have a website. You want people to be able to log in on it from starbucks without the guy sitting at a near table reading the passwords in clear from the packets you’re sending everyone around you. So you google a few random keywords like “secure website https” and you end up with a bunch of links and services (which may not be free) and you suddenly have to understand what are certificates, PKI, x509, public-key cryptography, RSA, FQDN, haaa…. Well, worry no more, Let’s Encrypt was thought so that you wouldn’t have to go through all that trouble and destroy your server on the way.

Oh and yeah. It’s for free. But is hasn’t been released yet.

How does it work?

You can learn more reading their technical overview, or some of their videos… or read my tl;dr:

  1. You download their program on your server that has the address www.example.com:
sudo apt-get install lets-encrypt
  1. You run it as sudo telling it you want to get a certificate for your domain
lets-encrypt example.com

And voila.

Behing the curtains this is what happens:


  1. lets-encrypt will generate a pair of RSA private key/public key and contact the CA with your public key.

  2. The CA will register your public key

  3. The program will then ask the CA to verify your domain.

  4. The CA will answer with a set of challenges. These are some tasks you can complete to prove to the CA you own that domain. One of the common one is to upload a certain file at a certain address of that domain.

  5. The program you installed will then do that for you and poll the CA for a confirmation

  6. The CA will tell you “OK man, all is good”.

  7. The program will then generate another long term pair of private key/public key, generate a CSR (Certificate Signing Request) with the new public key and send that CSR to the CA.

  8. The CA will extract the information, create a beautiful x509 certificate, sign it and send it back to you.

  9. lets-encrypt will install the certificate on your server and set certain options (or not) to force https

By the way, the certificate you will get will be a DV certificate, meaning that they only verified that you owned the domain, nothing more. If you want an EV certificate this is what you will have to go through (according to wikipedia):

  • Establish the legal identity as well as the operational and physical presence of website owner;
  • Establish that the applicant is the domain name owner or has exclusive control over the domain name; and
  • Confirm the identity and authority of the individuals acting for the website owner, and that documents pertaining to legal obligations are signed by an authorised officer.

But how does it really work?

So! The lets-encrypt program you run on your server is open sourced here: https://github.com/letsencrypt/lets-encrypt-preview. It is called lets-encrypt-preview I guess because it isn’t done yet. It’s written in Python and has to be run in sudo so that it can do most of the work for you. Note that it will install install the certificates on your server only if you are using Apache or Nginx. Also, the address of the CA is hardcoded in the program so be sure to use the official lets-encrypt.

The program installed on the CA is also open sourced! So that anyone can publicly review and audit the code. It’s called Boulder and it’s here: https://github.com/letsencrypt/boulder and written in Go.

Lets-encrypt and Boulder both use the protocol ACME for Automated Certificate Management Environment specified here as a draft: https://letsencrypt.github.io/acme-spec/


ACME spec

ACME is written like a RFC. It actually wants to become an RFC eventually! So if you’ve read RFCs before you should feel like home.

The whole protocol is happening over TLS. As a result the exchanges are encrypted, you know that you are talking to the CA you want to talk to (eventhough you might not use DNSSEC) and replay attacks should be avoided.

The whole thing is actually a RESTful API. The client, you, can do GET or POST queries to certains URI on the CA webserver.


The first thing you want to do is register. Registration is actually done by generating a new pair of RSA keys and sending them the public key (along with your info).

ACME specifies that you should use JWS for the transport of data. Json Web Signature. It’s basically Json with authentication (so that you can sign your messages). It actually uses a variant of JWS called Jose that doesn’t use a normal base64 encoding but that’s all you should know for now. If you really want to know more there is an RFC for it.

So here what a request should look like with JWS (your information are sent unencrypted in the payload field (but don’t worry, everything is encrypted anyway because the exchange happens over TLS)):

POST /acme/new-registration HTTP/1.1
Host: example.com


Boulder will check the signature with the public key you passed, verify the information you gave and eventually add you to its database.

Once you are registered, you can perform several actions:

  • Update your infos
  • Get one domain authorized (well actually as many as you’d like)

The server will authenticate you because you will now send your public key along AND you will sign your requests. This all runs on top of TLS by the way. I know I already said that.

Boulder’s guts


Boulder is separated in multiple components, this makes the code clearer and ensure that every piece of code does what it is supposed to do and nothing more.

One of the components is called the Web-Front-End (WFE) and is the only one accepting queries from the Client. It parses them, verifies them and passes them to the Registration Authority (RA) that combines the other authorities together to produce a response. The response is then passed back to the WFE and to the client over the ACME protocol. Are you following?

TWe’ll see what other authorities the RA has access to in the next queries the client can do. But just to talk about the previous query, the new registration query, the RA talks to the Storage Authority that deals with the database (Which is currently SQLlite) to register your new account.

All the components can be run from a single machine (for the exception of the CA that runs on another library), but they can also be run seperately from different machines that will communicate on the same network via AMQP.

New Authorization

Now that you are registered, you have to validate a domain before you can request a certificate.

You make a request to a certain URI.

Well to be exact you make a POST request to /new-authz, and the response will be 201 if it works. It will also give you some information about where you can go next to do stuff (/authz)

Here’s the current list of API calls you can do and the relevant answers.

API calls

The server will pass the info to the Policy Authority (PA) and ask it if it is willing to accept such a domain. If so, it will then answer with a list of challenges you can complete to prove you own the domain, along with combinations of accepted challenges to complete. For now they only have two challenges and you can complete either one:

If you choose SimpleHTTPS the lets-encrypt client will generate a random value and upload something at the address formed by a random value the CA sent you and the random value you generated.

If you choose DVSNI, the client will create a TLS certificate containing some of the info of the challenge and with the public key associated to his account.

The client then needs to query the CA again and the CA’s Validation Authority (VA) will either check that the file has been uploaded or will perform a handshake with the client’s server and verify that specific fields of the certificates have been correctly filled. If everything works out the VA will tell the RA that will tell the WFE that will tell you…

After that you are all good, you can now make a Certificate Signing Request 🙂

New Certificate

The agent will now generate a new pair of private key/public key. And create a CSR with it. So that your long term key used in your certificate is not the same as your let’s encrypt account.


a CSR example, containing the identifier and the public key

After reception of it, the Web-Front-End of Boulder will pass it to the Registration Authority (RA) which will pass it to the Certificate Authority (CA) that will do all the work and will eventually sign it and send it back to the chain.

1: Client ---new-cert--> WFE
2:                       WFE ---NewCertificate--> RA
3:                                                RA ---IssueCertificate--> CA
4:                                                                          CA --> CFSSL
5:                                                                          CA <-- CFSSL
6:                                                RA <------return--------- CA
7:                       WFE <------return------- RA
8: Client <------------- WFE

Oh and also. the CA is talking to a CFSSL server which is CloudFlare’s PKI Toolkit, a nice go library that you can use for many things and that is used here to act as the CA. CFSSL has recently pushed code to be compatible with the use of HSM which is a hardware device that you HAVE to use to sign keys when you are a CA.

After reception the lets-encrypt client will install the fresh certificate along with the chain to the root on your server and voila!

You can now revoke a certificate in the same way, but interestingly you won’t need to sign the request with your account key, but with the private key associated to your certificate’s public key. So that even if you lose your agent’s key you can still revoke the certificate.

Other stuff

There are a bunch of stuff that you will be able to do with the lets-encrypt client but that haven’t been implemented yet:

  • Renew a certificate
  • Read the Terms of Service
  • Query OCSP requests (see if a certificate has been revoked)


This post is a simplification of the protocol. If you want to know more and don’t want to dig in the ACME specs right now you can also take a look at Boulder’s flow diagrams.

key ceremony

If you’ve followed the news you should have seen that Let’s Encrypt just generated its root certificate along with several other certificates: https://letsencrypt.org/2015/06/04/isrg-ca-certs.html

This is because when you are a CA you are suppose to keep the root certificate offline. So you sign a (few) certificate(s) with that root, you lock that root and you use the signed certificate(s) to sign other certificates. This is all very serious because if something goes wrong with the root certificate, you can’t revoke anything and well… the internet goes wrong as a result (until vendors start removing these from their list of trusted roots).
So the keys for the certificate have to be generated during a “ceremony” where everything is filmed and everyone must authenticate oneself at least with two different documents, etc… Check Wikipedia’s page on Key Ceremony it’s “interesting”.

Also, I received a note from Seth David Schoen and I thought that was an interesting anecdote to share 🙂

the name “Boulder” is a joke from the American children’s
cartoon Looney Tunes:
This is because the protocol that Boulder implements is called ACME,
which was also the name of the company that made the products
unsuccessfully used by the coyote to attempt to catch the roadrunner.
Two of those products were anvils (the original name of the CA software)
and boulders.

Well done! You’ve reached the end of my post. Now you can leave me a comment 🙂

Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/c3Kyywnreqk/

Original article

A Brief History Of Deep Linking

linksweb Deep linking has become one of the hottest topics in mobile over the past year as dozens of startups have launched around using, improving and discovering deep links. All of the big platform companies also have projects to own “the deep linking standard” or the search index for mobile. So, what are deep links and where did they come from? Read More

Original URL: http://feedproxy.google.com/~r/Techcrunch/~3/6f9FvyHzyhE/

Original article

EdX marks the spot: the evolution of Harvard’s online courses

Hybrid course models mix remote learning with campus interaction

Rather than substituting online learning for in-person learning as some courses do, HarvardX Faculty Director Robert Lue said a new hybrid model combining online and in-person learning far from Harvard’s campus seeks instead to combine the strengths of each method.

Credit: File photo by Rose Lincoln/Harvard Staff Photographer Rather than substituting online learning for in-person learning as some courses do, HarvardX Faculty Director Robert Lue said a new hybrid model combining online and in-person learning far from Harvard’s campus seeks instead to combine the strengths of each method.

In 2013, Jennifer Chung was working as a software engineer in Seattle when she decided to take CopyrightX, an online legal course offered through Harvard’s edX collaboration with other universities.

Now she’s a second-year student at Harvard Law School.

Chung’s interest in copyright law stemmed from her hobbies. She wrote fiction and played music in her free time, and so understood the disruptive effect that information technology has had on the intellectual property rights of artists of all kinds.

“It’s basically a body of law that was really relevant to me, based on my hobbies and my profession,” Chung said. “I really enjoyed the course. It was applicable to my interests.”

CopyrightX is part of a culture of experimentation in online learning that has marked HarvardX — the University’s portion of edX — from the beginning. The course pioneered a parallel teaching model for online and on-campus students and, more recently, an additional hybrid model that combines online and in-person learning far from Harvard’s campus.

Rather than substituting online learning for in-person learning as some courses do, HarvardX Faculty Director Robert Lue said the hybrid model seeks instead to combine the strengths of each method, allowing students to view various types of online content, which frees teaching time for more personal interactions.

“For what kinds of learning does online work particularly well? By using it in that manner, can you free up time and persons to focus on the modes of learning — hands-on learning, experiential learning — that are best handled in person?” Lue said. “The idea is to have them complement each other in a very profound way.”

CopyrightX is offered to different student populations in different ways. For instance, the in-person version of the course is offered in a traditional classroom to HLS students. The online version, which is taught in parallel with the campus course, has been offered since edX began in 2012.

The third, hybrid version of the course began almost by accident, according to William Fisher, the WilmerHale Professor of Intellectual Property Law, the course’s main instructor. That first year, he said, a former student asked if she could use the CopyrightX material to teach a parallel course to her students in Jamaica. Fisher agreed. During the course’s second year, instructors at 10 institutions around the world offered it, combining their own in-class instruction with CopyrightX’s online lectures and reading materials. This year, the number of affiliated courses grew to 18, at institutions from Australia to Africa to the Middle East to Europe to the Caribbean to South America.

“The original vision had two dimensions, the Harvard Law School course and the 500 online students. So far as I know, the full integration of a residential course and the online course was itself unprecedented: not just teaching them in parallel, which is unusual, but using the same materials,” Fisher said. “I did not initially contemplate the third layer.”

CS50x, the edX version of Harvard’s popular introductory computer science course, has proven hugely successful — it has over 450,000 registrants as of this spring — and anticipates its own hybrid version this fall at Yale University.

David J. Malan, Gordon McKay Professor of the Practice of Computer Science, said the Yale course is designed to mirror the Harvard on-campus experience as much as possible. It will have the same recorded lectures that online and Harvard students view. It will be overseen by a Yale computer science professor, aided by teaching fellows, as it is on the Harvard campus.

“It’s ultimately motivated by our interest in and my own personal interest in the openness of educational content,” Malan said. “This is surely a good thing for the whole world if we can stand on each other’s shoulders so that we don’t need to reinvent so many wheels.”

The hybrid model is just part of the culture of innovation at HarvardX, Lue said. Instructors are still trying new techniques and learning how best to teach far-flung students. What works for one instructor may not work for another. What works for one subject may not work for another. But along the way, innovation continues.

Andrew Gordon, the Lee and Juliet Folger Fund Professor of History and an expert on Japan, worked with John Dower and Shigeru Miyagawa at Massachusetts Institute of Technology to design last fall’s “Visualizing Japan,” a unique course on Japanese history that flipped the usual priority of text and illustrative materials, making art, photographs, and other visual media the central focus.

The six-week course had higher-than-average student retention, Gordon said, and prompted a follow-on course about postwar Tokyo taught by a professor at the University of Tokyo. The course created a trove of visual materials that can be used as a resource by faculty members in the future and, Gordon said, the process of co-teaching and co-producing gave him new insights into both history and pedagogy.

“It was like making a documentary movie,” Gordon said. “I was a learner as well as a teacher.”

Original URL: http://today.law.harvard.edu/edx-marks-the-spot-the-evolution-of-harvards-online-courses/

Original article

It’s alive! Microsoft to let Live Writer live on as open source

Microsoft will breathe life into Windows Live Writer by open sourcing the eight-year-old blog-publishing tool, a company manager said earlier this week.

“We are going to open-source Live Writer, so don’t worry,” tweeted Scott Hanselman, a principal program and community manager for Microsoft. Hanselman, who has long advocated taking Live Writer open-source, was responding to a question about the future of Live Writer in Windows 10.

The application debuted in 2007 alongside Windows Vista, and was part of Windows Live Essentials, a bundle that included several now-defunct programs, such as Mail, Messenger, Movie Maker, Photo Gallery and SkyDrive. Live Writer was last updated in 2012, shortly after Microsoft retired the Live brand.

To read this article in full or to leave a comment, please click here

Original URL: http://www.computerworld.com/article/2934449/windows-apps/its-alive-microsoft-to-let-live-writer-live-on-as-open-source.html#tk.rss_all

Original article

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑

%d bloggers like this: