 provide both confidentiality, integrity and authenticity. So this means that nobody can see what you're looking at, nobody can change what you're looking at, and you know that the person who is sending you this is a specific person. They use signed digital certificates. Each one of these certificates must be signed by another certificate. And if you want to be trusted, they have to chain up to a certificate issued by a publicly trusted certificate authority who decide who gets the certificate and who doesn't. So why do we have to launch another one? Well, the internet is a bad place. It's extremely easy to modify or to observe HTTP communication. There have been a number of attacks that have demonstrated this over the years, including cookie session reuse and others. Based on telemetry from the Firefox browser, we know that only 40% of initial HTTP requests go over HTTPS. This is probably because both getting and installing a certificate, as well as setting up all the correct TLS parameters, is extremely confusing. And in part, this is because every CA decides how it will issue a certificate on its own. So our solution is to create another certificate authority. I mean, what can go wrong? So because we are EFF and Mozilla, we've decided that it should be completely free. Cryptography shouldn't be something that you have to pay for on the internet. And unfortunately, right now, there are only two certificate authorities that are willing to issue free certificates except for let's encrypt. And unfortunately, both of them make it a quite complicated process and will exclude you from getting a certificate if you fall into certain groups. So we decided to make it free, and we also decided to make it open source. We did this because it's extremely hard to tell what certificate authorities are actually doing and how they decide whether or not to issue a certificate. So we decided it would be best to come up with a standardized protocol, which we've called ACME, so that we can get everybody's input on what is the most secure way that we can do this. So let's encrypt has already launched, and you can right now go and get a publicly trusted free certificate from us. Unfortunately, this isn't a cheap thing to do. So we've been sponsored by a large number of industry people, including a bunch of hosting providers, Mozilla, Cisco, ACME, who's a content distribution network, and the EFF, among others. So the CA and TLS ecosystem is a pretty strange place. Before we got there, this is a map of every single trusted certificate authority that currently exists. Every single one of these nodes can issue a certificate that your browser will completely trust. And this is ridiculous, the fact that there are over 1,600 certificate authorities is very silly. You can actually see let's encrypt is one of the small magenta nodes in the bottom left-hand corner. Unfortunately, we haven't surpassed some of the other certificate authorities yet, but that's soon to happen. So there's a group called the CA Browser Forum, and these are the people who decide how the CA and TLS ecosystem works. Because CA's have a slightly vested interest in making money over protecting users, there's often a rift between them and the browsers and how rules should be made that affect publicly trusted certificates and certificate authorities. Because of this, they decided to come together and self-govern themselves in order to bring order about. The browsers generally yield slightly more power than the certificate authorities. They require a larger majority in order to pass a rule. And this is because, like I said previously, certificate authorities are generally guided by making money, whereas the browsers are generally guided by trying to keep users safe. Unfortunately, let's encrypt is not yet a member of this group, because they have very stringent requirements for membership, which include a number of audits we haven't yet completed, although we are very close to doing so. Like I said, the CAB Forum creates rules called the baseline requirements, which every certificate authority must comply with if they wish to be trusted by browsers. This includes basically documenting every process that is involved with issuance of a certificate and takes a very long time. So the CAB also chooses the different security levels of a certificate. These are called validation levels. There are currently three. And it should be noted that cryptographically, there is no difference between each of these levels of validation. What they mean is how thoroughly a CA has validated the person who is requesting a certificate. Domain validation is what we're interested in. And it basically just means that, as a CA, we can verify that you control a certain DNS name. Now, there are a few extra steps for organizational validation. This means that a CA would have to validate that you are an owner of a certain business in a certain country. And extended validation goes even further and checks other governmental records. Both OV and EV certificates don't provide any more security. All they provide is UI hints in the browser. So with an EV certificate, you will see a green box in your URL bar that says the name of a company. But the cryptographically, these certificates are exactly the same. So what does let's encrypt fit into this? Like I said, we're doing everything completely for free. This includes issuance, renewal, and revocation. And any other action you would do with us is entirely free. We're not charging anyone anything. We're also only going to be issuing domain validated certificates. This is because we don't intend on hiring a bunch of people to deal with issuance. Our system is entirely automated. The only people that we hire are operations, maintenance people. We're also only issuing certificates that are valid for a maximum of 90 days. This is a we originally decided on doing this because in the previous world where certificates were valid for anywhere from one to up to three years, it made it really hard to figure out how to automate renewal of a certificate. Every once a year, you would go to your certificate authority and ask for a new certificate, and then spend the next few hours trying to figure out what you had to tell them and how you'd install it in your server. By limiting the validity period to 90 days, we're ensuring that people are forced to renew often. This also comes with a good side effect that if a certificate becomes compromised, it is only compromised for a maximum of 90 days, which makes it slightly safer. So we're also issuing multiple domain certificates instead of wildcard certificates. These use subject alternative names, which are multiple DNS names inside of a certificate, meaning that a single certificate can be used to validate up to 100 domains. In order to make our certificates actually publicly trusted, we've applied to the Mozilla, Apple, Google, and Microsoft root programs, but we've also had one of our intermediate certificates cross-signed by IDENTRUST, which is another certificate authority, and this means that every certificate we issue is already trusted, so we don't have to worry about old devices not trusting our certificates. So we started our closed beta in about early September, and this went from all the way up to December 3rd, and during that period, we only issued about 20,000 certificates. You can see the first period in September was just staff issuing certificates to themselves, and I think we only issued around 100 or 200 certificates. And then we opened a closed beta, and we issued around 20,000 more. And then on December 3rd, we opened up to everyone. You didn't have to apply to join, and we would issue a certificate as long as you could prove that you controlled the domain. In the first day, we doubled the number of certificates we issued, and in the week, I think we could droop all that. I mean, in the first 12 hours, we were issuing a certificate almost every two seconds. And since then, we've issued over 200,000 certificates across 440,000 domain names. We are still in beta, though, that should be noted. We don't expect to do a Google-style beta. It will probably take a while. So using certificate transparency logs, which are a collection that Google has created of almost all currently valid certificates, we can see that Let's Encrypt is already the fifth largest certificate authority, and we have already lodged them both WOSign and Stardust to sell the two currently free public certificate authorities. So our goal is to raise... It isn't to be the largest certificate authority, but it is to raise the total percentage of connections on the Internet that go over HTTPS. So this is a very hard thing to measure. Unless you're sitting on a backbone, it's almost impossible to tell what percentage is going over HTTP and what percentage is going over HTTPS. Luckily, Firefox can provide us with certain TLS telemetry about what certificate authorities issue certificates that they are seeing, and we can also use certificate transparency to try and figure out how people are actually using our certificates. So we have a bunch of stats. There are currently over 120,000 individual registrations. So we count... A single registration can issue multiple certificates, and we see that currently only there are about two certificates per registration with two DNS names per certificate. Now, this is most likely because people are just testing the service, so they will go out and try and find a certificate for their blog or personal website, and not very many people are using very large certificates with multiple subject alternate names yet. We see that around 33% of the names that we issued for have multiple certificates with that name in them. Now, this is actually a very common thing we were expecting to see because we issue a very large number of certificates to content distribution networks, and these networks will have tons of endpoints that will work for a whole bunch of different websites. So they will maybe have 15 certificates that will have a set of 50 domain names spread out across them. We also see that 20% of certificates have the exact same duplicate namesets. This is probably more to do with people trying to get used to our official client and us having to fix a few bugs in it that meant that people would reissue the same certificate over and over without noticing that they already had a valid one. But we're seeing that slowly decrease. We've also seen that 80% of the domain names that we've issued for have never had a certificate before according to the certificate transparency logs. So we're actually providing people who usually wouldn't have got a TLS certificate with certificates. And we've had about 1% of our total issuance have been revoked so far, which is a good sign that our revocation system is actually working. So in order to see how people are actually deploying our certificates, we've written a very small TLS scanner that will go through the DNS names and certificates we've issued and try to see if they actually use them. And we see that about 75% of the people that we've issued a certificate for have actually deployed it on the domain name that we issued it for. And only 8% of those names have a broken TLS configuration. This means if you tried to connect to them, your browser would reject the certificate. And this is because they're using a self-signed certificate or because they aren't presenting the correct chain of certificates among other things. And 3% of the names we've issued for don't serve HTTPS at all. Now, this actually is probably quite smaller. Because we only scan for HTTPS, people could be using these certificates for mail servers or IRC servers or XMPP servers, we wouldn't know. And we can see that 45% of the certificates are used by every single DNS name that they contain, which is actually quite good number. So, looking at the Firefox telemetry, we see that only 0.1% currently of successful TLS handshakes use a let's encrypt certificate. Now, this sounds very low, but it actually makes a lot of sense. We don't plan... Our goal is not to make the largest websites on the internet use our certificates. If that happened, the percentage of successful TLS handshakes that we were involved in would be much higher. But our goal is to make... issue certificates to the long tail of people. People who may not have hundreds of thousands of visitors to their website, but should still be able to use cryptographic protocols. So, we have an official client, which is called let's encrypt. Which currently is used by about 65% of our users. This is a very complicated client, and it will do a lot of things for you. It will manage renewal. It will manage installing the certificate into either Apache or Engine server, among other things. But there have also been, since we entered public beta, around 30 unique third-party clients that have popped up. For pretty much any scenario, you might want to use a certificate for. So, including a web server called Caddy that has a built-in ACME client, which means that as soon as you can turn on your web server, if you don't have an Excel certificate, it will automatically go out and fetch one for you. Another one is a web-based client, so that you can go in your browser and generate a certificate without installing anything on your system at all. So, our main goal is actually to get hosting providers and content distribution networks to use our certificates. While most people here might want to just go out and install a certificate on the server they run themselves, the majority of people who are running smaller websites are using a hosting provider who will run all of this for them. And generally, these people will charge for certificates. And our goal is to try and get them to A, make it free, and B make it painless for the users. So, so far, we have ACME, QCDN, Dreamhost, Scion, Prestige2. These are both hosting providers and content distribution networks who have already integrated with Let's Encrypt and will allow you to get a certificate completely for free. And we assume that in the long term this will make up the majority of our usage. Most likely, people issuing hundreds of thousands of certificates won't be individuals, they will be hosting providers. So, we still have a lot of work to do on our certificate authority. Currently, you can only do validation based on either HTTP or HTTPS. This has made it quite complicated for some people who have very complex setups, either using load balances or other systems to validate their websites. One of our solutions to this is the DNS challenge, which will allow anyone to just add a DNS record and automatically validate the domain name they want. We also want to implement a proof-of-possession challenge. This means that if you ask for a certificate for a domain name that we know is already using a SSL certificate, we will ask you to prove that you control the private key of that certificate. And this is an extra way to verify that a single person won't control or can't mis-issue a certificate for a domain they can't control. We also want to add multi-path validation. Currently, we validate from a single point. This means that we are susceptible to network local attacks. But this will change very soon. All right, thank you. The first two questions are for the Internet. Okay, the first question from the Internet is that given the critics on the official client, wouldn't it have been better to split the server and service and the client? I think the client is a very hard thing to implement. And because we are the people who created the protocol, I think it makes sense for us to also work on trying to create a client for it. If we had just waited for somebody else to do it, I don't think we would have been able to get as far as we have so far. The second question is that, well, a lot of people are apparently interested in your T-shirt and want to know first what's on it, and second, where can they get one? Unfortunately, these aren't for sale yet, but they should be very soon. And you may notice that this is supposed to be the contents of a certificate. You can try and decode it, but I don't think you'll get very far. Okay. Okay, next question from Mark for number one. I have tried your service and it works very well. I was wondering what keeps you from going into public. I mean, you are now choosing a beta type. What is beta in your service currently? Well, our service hasn't been completely tested. We wouldn't suggest that a website like Facebook that gets millions of requests a day would deploy one of our certificates just yet. Yeah. It is currently we have a hard limit on how many certificates we are able to issue due to our hardware security modules. And because of that, we're kind of trying to take it slowly for now. Yeah. As far as we know. Okay, next question from Mark for number two. Hi. What are you using for revocation? Are you using the standard defined relocation list or do you have your own solution? We're using OCSP. Our plan is to promote OCSP stapling. Yeah. I think the CRL model is too broken. And we're kind of trying to push both Apache and Engines to get the act together with OCSP stapling so that it will actually be a useful revocation method. Okay, next question is for the internet and after that microphone number one again. Okay, the question is why is there a limit on certificate issues per domain because that is especially annoying for like dynamic DNS users? Yes, we agree. Currently, we use the public suffix list to decide how many certificates a domain should get. So if you have, say, Roland.com, you'll only be able to get five certificates for that domain. Currently, this is because we have a hard limit on how many certificates we're able to issue so we don't want a single user to be able to go out and take up a significant percentage of that. We're trying to figure out a better rate limiting solution. You should notice in the future that you will be able to issue a lot more certificates, but we're just not there yet. Hi, first thanks for the talk and for the great aim, I think we all support. I have a question regarding the audit that has to be done by Let's Encrypt because for new kids on the block usually there's this kind of certain audit where the Mozilla Foundation also was part of creating this and as I know there's a three month grace period of like handing in all the papers and whatever afterwards and if you started in September, that means now we are in December, so what's the status of this whole audit thing? And as I know maybe you can comment on this as well, the cross validation does not count for this, so I'd be very interested. So we are not yet in the root programs of any of the major browsers. We've, I think, just finished our audits. Unfortunately a cross signature doesn't require any audits. If you can pay a certificate authority enough money, they will cross sign one of your certificates and allow you to issue. It's a very silly system. So we, yeah, we, it means that we can currently issue completely valid trusted certificates, but we are not a member of the organization that decides, you know, how that works. It's strange. Next question for microphone number five. Hi, first of all, I would like to thank everyone working on this project. You guys are awesome. So I've got a question regarding engine eggs. Do you know when you might have it completely supported? I'm not 100% sure. We are working on, this is kind of our main focus in the client right now is increasing the, how well the Apache and engines plugins work. Engine has kind of got the shot under the stick currently because the majority of people we are working with are using Apache. The next few months though, that should improve significantly. Okay, thank you. Next question is for microphone number four and then we go back to the internet. So I have two. So one is let's say that tomorrow, shot two suddenly there's a big new attack. Everyone should move to shot three. But unfortunately, as we all know, many clients will lag. How would you plan to solve this situation? Will you push everyone to migrate instantly to shot three? Will you cater to those of your users that would like to remain as compatible as possible? And kind of related to that, can you give us, I'm sure you've been asked this question a lot, but why 90 days? Why not a lot less and maybe even get rid of the entire revocation system why not more? Can you give us a little glimpse of how you want to handle these decisions? So the first question, that decision isn't 100% up to us. It would be more up to the CAB forum and how they choose to sunset the algorithm. Most likely we would continue issuing until the deadline so that people can switch over as seamlessly as possible. But again, that's kind of a policy question for the governing body. And then the 90 days, we have been considering allowing less than 90 days. So if you would like to issue a one-day certificate or a two-day certificate, that should be possible. We decided that there should be a hard limit, though, on how long a certificate we're willing to issue. And 90 days is in part due to how long we would think a certificate that was compromised is safe to be around. And that should be as small as possible. Unfortunately, renewal is still a hard problem, so we can't just say a week or two weeks. And 90 days was kind of what we came down to as the safest. Okay, last questions for the internet. Okay, then the last question will be what is the stack that you use to generate the certificates? Do you have any special optimization like code or hardware to keep up with the increased demand? So we sign our certificates using hardware security modules and a library produced by Cloudflare, which they use for their universal SSL program, which is called CFSSL. But there's no special process involved. It's just a typical X509 generation. Thank you very much.