Let's Encrypt - Free SSL/TLS Certificates http://www.syntaxclothes.com/ Let's Encrypt is a free, automated, and open certificate authority brought to you by the nonprofit <a href="https://www.abetterinternet.org/">Internet Security Research Group (ISRG)</a>. en-US Thu, 01 Oct 2020 00:00:00 +0000 Hugo v0.67.1 Let's Encrypt's New Root and Intermediate Certificates http://www.syntaxclothes.com/2020/09/17/new-root-and-intermediates.html Thu, 17 Sep 2020 00:00:00 +0000 On Thursday, September 3rd, 2020, Let鈥檚 Encrypt issued six new certificates: one root, four intermediates, and one cross-sign. These new certificates are part of our larger plan to improve privacy on the web, by making ECDSA end-entity certificates widely available, and by making certificates smaller.

Given that we issue 1.5 million certificates every day, what makes these ones special? Why did we issue them? How did we issue them? Let鈥檚 answer these questions, and in the process take a tour of how Certificate Authorities think and work.

The Backstory

Every publicly-trusted Certificate Authority (such as Let鈥檚 Encrypt) has at least one root certificate which is incorporated into various browser and OS vendors鈥?(e.g. Mozilla, Google) trusted root stores. This is what allows users who receive a certificate from a website to confirm that the certificate was issued by an organization that their browser trusts. But root certificates, by virtue of their widespread trust and long lives, must have their corresponding private key carefully protected and stored offline, and therefore can鈥檛 be used to sign things all the time. So every Certificate Authority (CA) also has some number of 鈥渋ntermediates鈥? certificates which are able to issue additional certificates but are not roots, which they use for day-to-day issuance.

For the last five years, Let鈥檚 Encrypt has had one root: the ISRG Root X1, which has a 4096-bit RSA key and is valid until 2035.

Over that same time, we鈥檝e had four intermediates: the Let鈥檚 Encrypt Authorities X1, X2, X3, and X4. The first two were issued when Let鈥檚 Encrypt first began operations in 2015, and were valid for 5 years. The latter two were issued about a year later, in 2016, and are also valid for 5 years, expiring about this time next year. All of these intermediates use 2048-bit RSA keys. In addition, all of these intermediates are cross-signed by IdenTrust鈥檚 DST Root CA X3, another root certificate controlled by a different certificate authority which is trusted by most root stores.

Finally, we also have the ISRG Root OCSP X1 certificate. This one is a little different – it doesn鈥檛 issue any certificates. Instead, it signs Online Certificate Status Protocol (OCSP) responses that indicate the intermediate certificates have not been revoked. This is important because the only other thing capable of signing such statements is our root itself, and as mentioned above, the root needs to stay offline and safely secured.

Let’s Encrypt’s hierarchy as of August 2020

The New Certificates

For starters, we鈥檝e issued two new 2048-bit RSA intermediates which we鈥檙e calling R3 and R4. These are both issued by ISRG Root X1, and have 5-year lifetimes. They will also be cross-signed by IdenTrust. They鈥檙e basically direct replacements for our current X3 and X4, which are expiring in a year. We expect to switch our primary issuance pipeline to use R3 later this year, which won鈥檛 have any real effect on issuance or renewal.

The other new certificates are more interesting. First up, we have the new ISRG Root X2, which has an ECDSA P-384 key instead of RSA, and is valid until 2040. Issued from that, we have two new intermediates, E1 and E2, which are both also ECDSA and are valid for 5 years.

Notably, these ECDSA intermediates are not cross-signed by IdenTrust鈥檚 DST Root CA X3. Instead, the ISRG Root X2 itself is cross-signed by our existing ISRG Root X1. An astute observer might also notice that we have not issued an OCSP Signing Certificate from ISRG Root X2.

Let’s Encrypt’s hierarchy as of September 2020

Now that we have the technical details out of the way, let鈥檚 dive in to why the new hierarchy looks the way it does.

Why We Issued an ECDSA Root and Intermediates

There are lots of other articles you can read about the benefits of ECDSA (smaller key sizes for the same level of security; correspondingly faster encryption, decryption, signing, and verification operations; and more). But for us, the big benefit comes from their smaller certificate sizes.

Every connection to a remote domain over https:// requires a TLS handshake. Every TLS handshake requires that the server provide its certificate. Validating that certificate requires a certificate chain (the list of all intermediates up to but not including a trusted root), which is also usually provided by the server. This means that every connection – and a page covered in ads and tracking pixels might have dozens or hundreds – ends up transmitting a large amount of certificate data. And every certificate contains both its own public key and a signature provided by its issuer.

While a 2048-bit RSA public key is about 256 bytes long, an ECDSA P-384 public key is only about 48 bytes. Similarly, the RSA signature will be another 256 bytes, while the ECDSA signature will only be 96 bytes. Factoring in some additional overhead, that鈥檚 a savings of nearly 400 bytes per certificate. Multiply that by how many certificates are in your chain, and how many connections you get in a day, and the bandwidth savings add up fast.

These savings are a public benefit both for our subscribers 鈥?who can be sites for which bandwidth can be a meaningful cost every month 鈥?and for end-users, who may have limited or metered connections. Bringing privacy to the whole Web doesn鈥檛 just mean making certificates available, it means making them efficient, too.

As an aside: since we鈥檙e concerned about certificate sizes, we鈥檝e also taken a few other measures to save bytes in our new certificates. We鈥檝e shortened their Subject Common Names from 鈥淟et鈥檚 Encrypt Authority X3鈥?to just 鈥淩3鈥? relying on the previously-redundant Organization Name field to supply the words 鈥淟et鈥檚 Encrypt鈥? We鈥檝e shortened their Authority Information Access Issuer and CRL Distribution Point URLs, and we鈥檝e dropped their CPS and OCSP urls entirely. All of this adds up to another approximately 120 bytes of savings without making any substantive change to the useful information in the certificate.

Why We Cross-Signed the ECDSA Root

Cross-signing is an important step, bridging the gap between when a new root certificate is issued and when that root is incorporated into various trust stores. We know that it is going to take 5 years or so for our new ISRG Root X2 to be widely trusted itself, so in order for certificates issued by the E1 intermediate to be trusted, there needs to be a cross-sign somewhere in the chain.

We had basically two options: we could cross-sign the new ISRG Root X2 from our existing ISRG Root X1, or we could cross-sign the new E1 and E2 intermediates from ISRG Root X1. Let鈥檚 examine the pros and cons of each.

Cross-signing the new ISRG Root X2 certificate means that, if a user has ISRG Root X2 in their trust store, then their full certificate chain will be 100% ECDSA, giving them fast validation, as discussed above. And over the next few years, as ISRG Root X2 is incorporated into more and more trust stores, validation of ECDSA end-entity certificates will get faster without users or websites having to change anything. The tradeoff though is that, as long as X2 isn鈥檛 in trust stores, user agents will have to validate a chain with two intermediates: both E1 and X2 chaining up to the X1 root. This takes more time during certificate validation.

Cross-signing the intermediates directly has the opposite tradeoff. On the one hand, all of our chains will be the same length, with just one intermediate between the subscriber certificate and the widely-trusted ISRG Root X1. But on the other hand, when the ISRG Root X2 does become widely trusted, we鈥檇 have to go through another chain switch in order for anyone to gain the benefits of an all-ECDSA chain.

In the end, we decided that providing the option of all-ECDSA chains was more important, and so opted to go with the first option, and cross-sign the ISRG Root X2 itself.

Why We Didn鈥檛 Issue an OCSP Responder

The Online Certificate Status Protocol is a way for user agents to discover, in real time, whether or not a certificate they鈥檙e validating has been revoked. Whenever a browser wants to know if a certificate is still valid, it can simply hit a URL contained within the certificate itself and get a yes or no response, which is signed by another certificate and can be similarly validated. This is great for end-entity certificates, because the responses are small and fast, and any given user might care about (and therefore have to fetch) the validity of wildly different sets of certificates, depending on what sites they visit.

But intermediate certificates are a tiny subset of all certificates in the wild, are generally well-known, and are rarely revoked. Because of this, it can be much more efficient to simply maintain a Certificate Revocation List (CRL) containing validity information for all well-known intermediates. Our intermediate certificates all contain a URL from which a browser can fetch their CRL, and in fact some browsers even aggregate these into their own CRLs which they distribute with each update. This means that checking the revocation status of intermediates doesn鈥檛 require an extra network round trip before you can load a site, resulting in a better experience for everyone.

In fact, a recent change (ballot SC31) to the Baseline Requirements, which govern CAs, has made it so intermediate certificates are no longer required to include an OCSP URL; they can now have their revocation status served solely by CRL. And as noted above, we have removed the OCSP URL from our new intermediates. As a result, we didn鈥檛 need to issue an OCSP responder signed by ISRG Root X2.

Putting It All Together

Now that we鈥檝e shared our new certificates look the way they do, there鈥檚 one last thing we鈥檇 like to mention: how we actually went about issuing them.

The creation of new root and intermediate certificates is a big deal, since their contents are so regulated and their private keys have to be so carefully protected. So much so that the act of issuing new ones is called a 鈥渃eremony鈥? Let鈥檚 Encrypt believes strongly in automation, so we wanted our ceremony to require as little human involvement as possible.

Over the last few months we鈥檝e built a ceremony tool which, given appropriate configuration, can produce all of the desired keys, certificates, and requests for cross-signs. We also built a demo of our ceremony, showing what our configuration files would be, and allowing anyone to run it themselves and examine the resulting output. Our SREs put together a replica network, complete with Hardware Security Modules, and practiced the ceremony multiple times to ensure it would work flawlessly. We shared this demo with our technical advisory board, our community, and various mailing lists, and in the process received valuable feedback that actually influenced some of the decisions we鈥檝e talked about above! Finally, on September 3rd, our Executive Director met with SREs at a secure datacenter to execute the whole ceremony, and record it for future audits.

And now the ceremony is complete. We鈥檝e updated our certificates page to include details about all of our new certificates, and are beginning the process of requesting that our new root be incorporated into various trust stores. We intend to begin issuing with our new intermediates over the coming weeks, and will post further announcements in our community forum when we do.

We hope that this has been an interesting and informative tour around our hierarchy, and we look forward to continuing to improve the internet one certificate at a time. We鈥檇 like to thank IdenTrust for their early and ongoing support of our vision to change security on the Web for the better.

We depend on contributions from our community of users and supporters in order to provide our services. If your company or organization would like to sponsor Let鈥檚 Encrypt please email us at sponsor@www.syntaxclothes.com. We ask that you make an individual contribution if it is within your means.

]]>
http://www.syntaxclothes.com/2020/09/17/new-root-and-intermediates.html
Let's Encrypt Has Issued a Billion Certificates http://www.syntaxclothes.com/2020/02/27/one-billion-certs.html Thu, 27 Feb 2020 00:00:00 +0000 We issued our billionth certificate on February 27, 2020. We鈥檙e going to use this big round number as an opportunity to reflect on what has changed for us, and for the Internet, leading up to this event. In particular, we want to talk about what has happened since the last time we talked about a big round number of certificates - one hundred million.

One thing that鈥檚 different now is that the Web is much more encrypted than it was. In June of 2017 approximately 58% of page loads used HTTPS globally, 64% in the United States. Today 81% of page loads use HTTPS globally, and we鈥檙e at 91% in the United States! This is an incredible achievement. That鈥檚 a lot more privacy and security for everybody.

Another thing that鈥檚 different is that our organization has grown a bit, but not by much! In June of 2017 we were serving approximately 46M websites, and we did so with 11 full time staff and an annual budget of $2.61M. Today we serve nearly 192M websites with 13 full time staff and an annual budget of approximately $3.35M. This means we鈥檙e serving more than 4x the websites with only two additional staff and a 28% increase in budget. The additional staff and budget did more than just improve our ability to scale though - we鈥檝e made improvements across the board to provide even more secure and reliable service.

Nothing drives adoption like ease of use, and the foundation for ease of use in the certificate space is our ACME protocol. ACME allows for extensive automation, which means computers can do most of the work. It was also standardized as RFC 8555 in 2019, which allows the Web community to confidently build an even richer ecosystem of software around it. Today, thanks to our incredible community, there is an ACME client for just about every deployment environment. Certbot is one of our favorites, and they鈥檝e been working hard to make it even easier for people to use.

When you combine ease of use with incentives, that鈥檚 when adoption really takes off. Since 2017 browsers have started requiring HTTPS for more features, and they鈥檝e greatly improved the ways in which they communicate to their users about the risks of not using HTTPS. When websites put their users at risk by not using HTTPS, major browsers now show stronger warnings. Many sites have responded by deploying HTTPS.

Thanks for taking the time to reflect on this milestone with us. As a community we鈥檝e done incredible things to protect people on the Web. Having issued one billion certificates is affirmation of all the progress we鈥檝e made as a community, and we鈥檙e excited to keep working with you to create an even more secure and privacy-respecting Web for everyone.

We depend on contributions from our community of users and supporters in order to provide our services. If your company or organization would like to sponsor Let鈥檚 Encrypt please email us at sponsor@www.syntaxclothes.com. We ask that you make an individual contribution if it is within your means.

]]>
http://www.syntaxclothes.com/2020/02/27/one-billion-certs.html
Multi-Perspective Validation Improves Domain Validation Security http://www.syntaxclothes.com/2020/02/19/multi-perspective-validation.html Wed, 19 Feb 2020 00:00:00 +0000 At Let鈥檚 Encrypt we鈥檙e always looking for ways to improve the security and integrity of the Web PKI. We鈥檙e proud to launch multi-perspective domain validation today because we believe it鈥檚 an important step forward for the domain validation process. To our knowledge we are the first CA to deploy multi-perspective validation at scale.

Domain validation is a process that all CAs use to ensure that a certificate applicant actually controls the domain they want a certificate for. Typically the domain validation process involves asking the applicant to place a particular file or token at a controlled location for the domain, such as a particular path or a DNS entry. Then the CA will check that the applicant was able to do so. Historically it looks something like this:

System Architecture Diagram

A potential issue with this process is that if a network attacker can hijack or redirect network traffic along the validation path (for the challenge request, or associated DNS queries), then the attacker can trick a CA into incorrectly issuing a certificate. This is precisely what a research team from Princeton demonstrated can be done with an attack on BGP. Such attacks are rare today, but we are concerned that these attacks will become more numerous in the future.

The Border Gateway Protocol (BGP) and most deployments of it are not secure. While there are ongoing efforts to secure BGP, such as RPKI and BGPsec, it may be a long time until BGP hijacking is a thing of the past. We don鈥檛 want to wait until we can depend on BGP being secure, so we鈥檝e worked with the research team from Princeton to devise a way to make such attacks more difficult. Instead of validating from one network perspective, we now validate from multiple perspectives as well as from our own data centers:

System Architecture Diagram

Today we are validating from multiple regions within a single cloud provider. We plan to diversify network perspectives to other cloud providers in the future.

This makes the kind of attack described earlier more difficult because an attacker must successfully compromise three different network paths at the same time (the primary path from our data center, and at least two of the three remote paths). It also increases the likelihood that such an attack will be detected by the Internet topology community.

We鈥檇 like to thank the research groups of Prof. Prateek Mittal and Prof. Jennifer Rexford at Princeton University for their partnership in developing this work. We will continue to work with them to refine the effectiveness of our multiple perspective validation design and implementation. We鈥檇 also like to thank Open Technology Fund for supporting this work.

We depend on contributions from our community of users and supporters in order to provide our services. If your company or organization would like to sponsor Let鈥檚 Encrypt please email us at sponsor@www.syntaxclothes.com. We ask that you make an individual contribution if it is within your means.

]]>
http://www.syntaxclothes.com/2020/02/19/multi-perspective-validation.html
How Let's Encrypt Runs CT Logs http://www.syntaxclothes.com/2019/11/20/how-le-runs-ct-logs.html Wed, 20 Nov 2019 00:00:00 +0000 Let鈥檚 Encrypt launched a Certificate Transparency (CT) log this past spring. We鈥檙e excited to share how we built it in hopes that others can learn from what we did. CT has quickly become an important piece of Internet security infrastructure, but unfortunately it鈥檚 not trivial to run a good log. The more the CT community can share about what has been done, the better the ecosystem will be.

Sectigo and Amazon Web Services have generously provided support to cover a significant portion of the cost of running our CT log. 鈥淪ectigo is proud to sponsor the Let鈥檚 Encrypt CT Log. We believe this initiative will provide much-needed reinforcement of the CT ecosystem,鈥?said Ed Giaquinto, Sectigo鈥檚 CIO.

For more background information about CT and how it works, we recommend reading 鈥?a >How Certificate Transparency Works.鈥?/p>

If you have questions about any of what we鈥檝e written here, feel free to ask on our community forums.

Objectives

  1. Scale: Let鈥檚 Encrypt issues over 1 million certificates per day, and that number grows each month. We want our log to consume our certificates as well as those from other CAs, so we need to be able to handle as many as 2 million or more certificates per day. To support this ever-increasing number of certificates, CT software and infrastructure need to be architected for scale.
  2. Stability and Compliance: We target 99% uptime, with no outage lasting longer than 24 hours, in compliance with the Chromium and Apple CT policies.
  3. Sharding: Best practice for a CT log is to break it into several temporal shards. For more information on temporal sharding, check out these blog posts.
  4. Low Maintenance: Staff time is expensive, we want to minimize the amount of time spent maintaining infrastructure.

System Architecture

System Architecture Diagram

Staging and Production Logs

We run two equivalent logs, one for staging and one for production. Any changes we plan to make to the production log are first deployed to the staging log. This is critical for making sure that updates and upgrades don鈥檛 cause problems before being deployed to production. You can find access details for these logs in our documentation.

We keep the staging log continually under production-level load so that any scale-related problems manifest there first. We also use the staging CT log to submit certificates from our staging CA environment, and make it available for use by other CAs鈥?staging environments.

As a point of clarification, we consider a log to be comprised of several temporal shards. While each shard is technically a separate log, it makes sense to conceptualize the shards as belonging to a single log.

Amazon Web Services (AWS)

We decided to run our CT logs on AWS for two reasons.

One consideration for us was cloud provider diversity. Since there are relatively few trusted logs in the ecosystem, we don鈥檛 want multiple logs to go down due to a single cloud provider outage. At the time we made the decision there were logs running on Google and Digital Ocean infrastructure, as well as self-hosted. We were not aware of any on AWS (in hindsight we may have missed the fact that Digicert had started using AWS for logs). If you鈥檙e thinking about setting up a trusted log for CAs to use, please consider cloud provider diversity.

Additionally, AWS provides a solid set of features and our team has experience using it for other purposes. We had little doubt that AWS was up to the task.

Terraform

Let鈥檚 Encrypt uses Hashicorp Terraform for a number of cloud-based projects. We were able to bootstrap our CT log infrastructure by reusing our existing Terraform code. There are roughly 50 components in our CT deployments; including EC2, RDS, EKS, IAM, security groups, and routing. Centrally managing this code allows our small team to reproduce a CT infrastructure in any Amazon region of the globe, prevent configuration drift, and easily test infrastructure changes.

Database

We chose to use MariaDB for our CT log database because we have extensive experience using it to run our certificate authority. MariaDB has scaled well on our journey to becoming the largest publicly trusted certificate authority.

We chose to have our MariaDB instances managed by Amazon RDS because RDS provides synchronous writes to standby cluster members. This allows for automatic database failover and ensures database consistency. Synchronous writes to database replicas are essential for a CT log. One missed write during a database failover can mean a certificate was not included as promised, and could lead to the log being disqualified. Having RDS manage this for us reduces complexity and saves staff time. We are still responsible for managing the database performance, tuning, and monitoring.

It鈥檚 important to calculate the necessary amount of storage for a CT log database carefully. Too little storage can result in needing to undertake time-consuming and potentially risky storage migrations. Too much storage can result in unnecessarily high costs.

A back of the napkin storage estimation is 1TB per 100 million entries. We expect to need to store 1 billion certificates and precertificates per annual temporal shard, for which we would need 10TB. We considered having separate database storage per annual temporal shard, with approximately 10TB allocated to each, but that was cost prohibitive. We decided to create a 12TB storage block per log (10TB plus some breathing room), which is duplicated for redundancy by RDS. Each year we plan to freeze the previous year鈥檚 shard and move it to a less expensive serving infrastructure, reclaiming its storage for our live shards.

We use 2x db.r5.4xlarge instances for RDS for each CT log. Each of these instances contains 8 CPU cores and 128GB of RAM.

Kubernetes

After trying a few different strategies for managing application instances, we decided to use Kubernetes. There is a hefty learning curve for Kubernetes and the decision was not made lightly. This was our first project making use of Kubernetes, and part of the reason we went with it was to gain experience and possibly apply that knowledge to other parts of our infrastructure in the future.

Kubernetes provides abstractions for operators such as deployments, scaling, and service discovery that we would not have to build ourselves. We utilized the example Kubernetes deployment manifests in the Trillian repository to assist with our deployment.

A Kubernetes cluster is comprised of two main components: the control plane which handles the Kubernetes APIs, and worker nodes where containerized applications run. We chose to have Amazon EKS manage our Kubernetes control plane.

We use 4x c5.2xlarge EC2 instances for the worker node pool for each CT log. Each of these instances contains 8 CPU cores and 16GB of RAM.

Application Software

There are three main CT components that we run in a Kubernetes cluster.

The certificate transparency front end, or CTFE, provides RFC 6962 endpoints and translates them to gRPC API requests for the Trillian backend.

Trillian describes itself as a 鈥渢ransparent, highly scalable and cryptographically verifiable data store.鈥?Essentially, Trillian implements a generalized verifiable data store via a Merkle tree that can be used as the back-end for a CT log via the CTFE. Trillian consists of two components; the log signer and log server. The log signer鈥檚 function is to periodically process incoming leaf data (certificates in the case of CT) and incorporate them into a Merkle tree. The log server retrieves objects from a Merkle tree in order to fulfill CT API monitoring requests.

Load Balancing

Traffic enters the CT log through an Amazon ELB which is mapped to a Kubernetes Nginx ingress service. The ingress service balances traffic amongst multiple Nginx pods. The Nginx pods proxy traffic to the CTFE service which balance that traffic to CTFE pods.

We employ IP and user agent based rate limiting at this Nginx layer.

Logging and Monitoring

Trillian and the CTFE expose Prometheus metrics which we transform into monitoring dashboards and alerts. It is essential to set a Service Level Objective for the CT log endpoints above the 99% uptime dictated by CT policy to ensure that your log is trusted. A FluentD pod running in a DaemonSet ships logs to centralized storage for further analysis.

We developed a free and open source tool named ct-woodpecker that is used to monitor various aspects of log stability and correctness. This tool is an important part of how we ensure we鈥檙e meeting our service level objectives. Each ct-woodpecker instance runs externally from Amazon VPCs containing CT logs.

Future Efficiency Improvements

Here are some ways we may be able to improve the efficiency of our system in the future:

  • Trillian stores a copy of each certificate chain, including many duplicate copies of the same intermediate certificates. Being able to de-duplicate these in Trillian would significantly reduce storage costs. We鈥檙e planning to look into whether this is possible and reasonable.
  • See if we can successfully use a cheaper form of storage than IO1 block storage and provisioned IOPs.
  • See if we can reduce the Kubernetes worker EC2 instance size or use fewer EC2 instances.

Support Let鈥檚 Encrypt

We depend on contributions from our community of users and supporters in order to provide our services. If your company or organization is interested in learning more about sponsorship, please email us at sponsor@www.syntaxclothes.com. We ask that you make an individual contribution if it is within your means.

]]>
http://www.syntaxclothes.com/2019/11/20/how-le-runs-ct-logs.html
Onboarding Your Customers with Let's Encrypt and ACME http://www.syntaxclothes.com/2019/10/09/onboarding-your-customers-with-lets-encrypt-and-acme.html Wed, 09 Oct 2019 00:00:00 +0000 If you work at a hosting provider or CDN, ACME鈥檚 DNS-01 validation method can make it a lot easier to onboard new customers who have an existing HTTPS website at another provider. Before your new customer points their domain name at your servers, you need to have a certificate already installed for them. Otherwise visitors to the customer鈥檚 site will see an outage for a few minutes while you issue and install a certificate. To fix this, you and your new customer should use the DNS-01 validation method to issue a certificate before the customer switches over DNS for their site.

How the DNS Validation Method Works

The DNS-01 validation method works like this: to prove that you control www.example.com, you create a TXT record at _acme-challenge.www.example.com with a 鈥渄igest value鈥?as specified by ACME (your ACME client should take care of creating this digest value for you). When the TXT record is ready, your ACME client informs the ACME server (for instance, Let鈥檚 Encrypt) that the domain is ready for validation. The ACME server looks up the TXT record, compares it to the expected digest value, and if the result is correct, considers your account authorized to issue for www.example.com. Your new customer can set up this TXT record (or a CNAME) without interfering with normal website operations.

The Advantages of a CNAME

There鈥檚 an additional trick that I recommend for hosting providers and CDNs: Instead of giving the digest value to your new customer and telling them to make a TXT record with it, tell your customer to configure a CNAME from _acme-challenge.www.example.com to a domain name that you control and that is unique to the domain being validated. For instance, you might use www.example.com.validationserver.example.net. Then, once your software has verified that this CNAME is set up (accounting for propagation delay and anycast), your ACME client should begin the validation process for www.example.com, provisioning a TXT record at www.example.com.validationserver.example.net. Because the ACME server鈥檚 TXT lookup follows CNAMEs (as do all DNS lookups), it will see the value you provisioned, and consider your account authorized.

This approach is preferable to handing your customers a raw digest value for a few reasons. First, it gives your customers all the time they need to set up the CNAME. If you create a pending authorization up front and give your customer a digest value to deploy themselves, it has a fixed lifetime before it expires (for Let鈥檚 Encrypt this lifetime is 7 days). If your customer doesn’t complete the process in that time, you鈥檒l have to create a new pending authorization and give your customer a new digest value. That’s annoying and time consuming for both you and your customer. The CNAME method means even if it takes your new customer a month to make the needed changes to their DNS, you can get things up and running as soon as they do.

Another reason to prefer the CNAME method over having new customers directly provision their TXT records is to support the best practice of periodically rotating your ACME account key. Because the digest value used for DNS-01 validation is computed based on your current ACME account key, it will change whenever you rotate your account key. If you asked customers to provision their TXT record manually , that means notifying potential new customers that the value you asked them to put in DNS isn’t valid anymore, and they need to use a different one. That鈥檚 pretty inconvenient! If you use the CNAME method instead, there鈥檚 only one ACME-related value you鈥檒l ever need to have your new customers put in DNS, and it won鈥檛 change as you change your account key.

Cleaning Up Unused CNAMES

One last note: This is a good way to onboard customers, but you also need to detect when customers offboard themselves. They may simply change their A records to point at a different CDN, without telling you that their plans have changed. You should monitor for this situation and stop attempting to issue certificates. If the customer has left behind a CNAMEd _acme-challenge subdomain that points at you, you should contact that and remind them to delete it. The CNAMEd subdomain represents a delegated authorization to issue certificates, and cleaning up that delegation improves both the customer鈥檚 security posture and your own. Similarly, if a customer sets up the CNAME and you issue a certificate on their behalf, but they never point their A records at your servers, you should not reissue new certificates indefinitely without further intervention from the customer.

]]>
http://www.syntaxclothes.com/2019/10/09/onboarding-your-customers-with-lets-encrypt-and-acme.html
Introducing Oak, a Free and Open Certificate Transparency Log http://www.syntaxclothes.com/2019/05/15/introducing-oak-ct-log.html Wed, 15 May 2019 00:00:00 +0000

Update: Feb. 5 2020

The Let鈥檚 Encrypt CT logs are now included in approved log lists and are usable by all publicly-trusted certificate authorities.

Today we are announcing a new Certificate Transparency log called Oak. The Oak log will be operated by Let鈥檚 Encrypt and all publicly trusted certificate authorities will be welcome to submit certificates.

Sectigo generously provided funding to cover a significant portion of our costs to run our CT log. 鈥淪ectigo is proud to sponsor the Let鈥檚 Encrypt CT Log. We believe this initiative will provide much-needed reinforcement of the CT ecosystem,鈥?said Ed Giaquinto, Sectigo鈥檚 CIO. We thank them for their collaboration to improve Internet security.

Certificate Transparency (CT) is a system for logging and monitoring certificate issuance. It greatly enhances everyone鈥檚 ability to monitor and study certificate issuance, and these capabilities have led to numerous improvements to the CA ecosystem and Web security. As a result, it is rapidly becoming critical Internet infrastructure. Let鈥檚 Encrypt accelerated the adoption of CT by logging every certificate since we started issuing in 2015 - approximately half a billion certificates at this point.

We decided to create and operate a CT log for a few reasons. First, operating a log is consistent with our mission to create a more secure and privacy-respecting Web. We believe transparency increases security and empowers people to make well-informed decisions. Second, operating a log helps us take control of our destiny. Google Chrome requires all new certificates to be submitted to two separate logs, so multiple log options are imperative to our operation. Finally, Let鈥檚 Encrypt often issues more than 1M certificates each day, so we wanted to design a CT log that is optimized for high volume. We鈥檝e designed our log to be able to handle submissions from all other publicly trusted Certificate Authorities so they can use Oak to fulfill their logging requirements as well.

Our log uses Google鈥檚 Trillian software running on AWS infrastructure. We use Kubernetes for container orchestration and job scheduling and AWS RDS for database management.

We are submitting our log for inclusion in the approved log lists for Google Chrome and Apple Safari. Following 90 days of successful monitoring, we anticipate our log will be added to these trusted lists and that change will propagate to people鈥檚 browsers with subsequent browser version releases.

Continuing the forest theme, we are also announcing the launch of our open source CT monitoring tool, CT Woodpecker. We use it to monitor and ensure compliance for our log and we鈥檝e made it open source so others in the CT ecosystem can use it as well.

We鈥檇 like to thank Google, Sectigo, Cloudflare, and DigiCert for also running open logs, and we look forward to contributing to better transparency in Web security!

We depend on contributions from our community of users and supporters in order to provide our services. If your company or organization would like to sponsor Let鈥檚 Encrypt please email us at sponsor@www.syntaxclothes.com. We ask that you make an individual contribution if it is within your means.

]]>
http://www.syntaxclothes.com/2019/05/15/introducing-oak-ct-log.html
Transitioning to ISRG's Root http://www.syntaxclothes.com/2019/04/15/transitioning-to-isrg-root.html Mon, 15 Apr 2019 00:00:00 +0000

Update, September 17 2020

In an effort to provide more time for our community to prepare for this transition, we have moved back the date on which we will start serving a chain to our own root to January 11, 2021.

Update, September 17, 2020

Due to concerns about insufficient ISRG root propagation on Android devices we have decided to move the date on which we will start serving a chain to our own root to January 11, 2021. We had originally delayed this change until September 29, 2020.

On January 11, 2021, we will change the default intermediate certificate we provide via ACME. Most subscribers don鈥檛 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鈥檚 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鈥檇 like to transition our subscribers to using our root directly, without a cross-sign.

On January 11, 2021, Let鈥檚 Encrypt will start serving a certificate chain via the ACME protocol which leads directly to our root, with no cross-signature. Most subscribers don鈥檛 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 March 17, 2021. The IdenTrust root that we are cross-signed from expires on September 30, 2021. Within the next year we will obtain a new cross-signature that is valid until September 29, 2021. This means that our subscribers will have the option to manually configure a certificate chain that uses IdenTrust until September 29, 2021.

We鈥檇 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%.

Let鈥檚 Encrypt is currently providing certificates for more than 160 million websites. We look forward to being able to serve even more websites as efforts like this make deploying HTTPS with Let鈥檚 Encrypt even easier. If you鈥檙e as excited about the potential for a 100% HTTPS Web as we are, please consider getting involved, making a donation, or sponsoring Let鈥檚 Encrypt.

]]>
http://www.syntaxclothes.com/2019/04/15/transitioning-to-isrg-root.html
The ACME Protocol is an IETF Standard http://www.syntaxclothes.com/2019/03/11/acme-protocol-ietf-standard.html Mon, 11 Mar 2019 00:00:00 +0000 It has long been a dream of ours for there to be a standardized protocol for certificate issuance and management. That dream has become a reality now that the IETF has standardized the ACME protocol as RFC 8555. I鈥檇 like to thank everyone involved in that effort, including Let鈥檚 Encrypt staff and other IETF contributors.

Having a standardized protocol for certificate issuance and management is important for two reasons. First, it improves the quality of the software ecosystem because developers can focus on developing great software for a single protocol, instead of having many pieces of less well maintained software for bespoke APIs. Second, a standardized protocol makes switching from one CA to another easier by minimizing technical dependency lock-in.

We consider the standardized version of the ACME protocol to be the second major version of ACME, so we refer to it as ACMEv2. The first version, which we call ACMEv1, is the version of ACME that Let鈥檚 Encrypt has used since our launch in 2015. Now that ACMEv2 is standardized, we are announcing an end-of-life plan for our ACMEv1 support.

Let鈥檚 Encrypt is currently providing certificates for more than 150 million websites. We look forward to being able to serve even more websites as efforts like this make deploying HTTPS with Let鈥檚 Encrypt even easier. If you鈥檙e as excited about the potential for a 100% HTTPS Web as we are, please consider getting involved, making a donation, or sponsoring Let鈥檚 Encrypt.

]]>
http://www.syntaxclothes.com/2019/03/11/acme-protocol-ietf-standard.html
Facebook Expands Support for Let鈥檚 Encrypt http://www.syntaxclothes.com/2019/02/12/facebook-expands-support-for-letsencrypt.html Tue, 12 Feb 2019 00:00:00 +0000

We鈥檙e excited that Facebook is supporting our work through a three-year Platinum sponsorship! We asked them to share their thoughts on HTTPS adoption here. Please join us in thanking Facebook for their support of Let鈥檚 Encrypt and our mission to encrypt the Web! - Josh Aas, Executive Director, ISRG / Let鈥檚 Encrypt

If the web is more secure, everybody wins. A key technology for making this happen is HTTPS, which enables encrypted connections between people and the websites that they visit. Among its many benefits, HTTPS helps to prevent sensitive data from leaking over the network, and from connections being censored or otherwise maliciously manipulated. The more widely it is deployed, the more secure and private the web becomes for everyone.

We have long worked to protect Facebook users from spammy or malicious content when navigating away from our platform, and last year we extended this protection to upgrading outbound HTTP links to HTTPS where possible. In this way we can help improve people’s security and privacy as they leave our platform. While we take these steps to improve the security and safety of Facebook users, ultimately we hope to see more websites allowing HTTPS connections.

Enabling HTTPS was historically a non-trivial task for any site. It required investment in buying and installing a TLS certificate, which verifies control over the website so that HTTPS can work. The technical difficulty and cost used to serve as barriers to expanding the use of HTTPS across the web. However, things have recently started to change, largely thanks to Let鈥檚 Encrypt, a non-profit certificate authority, launched in 2015.

Let鈥檚 Encrypt provides free TLS certificates, which are often installed using a tool maintained by the Electronic Frontier Foundation, to massively simplify enabling HTTPS. With that, Let鈥檚 Encrypt is effectively upgrading the security and privacy of the web, at no cost to over 150 million websites, including those frequented by Facebook users.

We’re excited to see the continuous increase in HTTPS adoption across the internet. More websites are choosing to enable secure connections which provide the security and privacy benefits and enable a better browsing experience. For example, navigating from Facebook to another site can be faster over encrypted connections than HTTP, and an increasing number of browser features will only work when sites use HTTPS.

We have sponsored Let’s Encrypt from the start, and are proud to share that we are increasing that support as a platinum sponsor. We believe that Let’s Encrypt has played a significant and important role in bringing encryption into the mainstream and raising the number of secure sites across the internet.

As we automatically crawl web content on Facebook (for example, to generate link previews), about 38% of HTTPS domains we observe use Let’s Encrypt, making it the top certificate authority. Over 19% of outbound clicks from Facebook to HTTPS-enabled websites go to sites that use certificates from Let’s Encrypt. Overall, more than 72% of outbound clicks from Facebook are now destined for HTTPS-enabled websites, including the links that we upgrade to HTTPS in real time.

We’re proud to continue to collaborate with Let’s Encrypt on helping to improve web security. To any website owners who haven’t yet enabled encryption, we strongly encourage you to use Let’s Encrypt to protect your users and allow HTTPS connections.

]]>
http://www.syntaxclothes.com/2019/02/12/facebook-expands-support-for-letsencrypt.html
Looking Forward to 2019 http://www.syntaxclothes.com/2018/12/31/looking-forward-to-2019.html Mon, 31 Dec 2018 00:00:00 +0000 Let鈥檚 Encrypt had a great year in 2018. We鈥檙e now serving more than 150 million websites while maintaining a stellar security and compliance track record.

Most importantly though, the Web went from 67% encrypted page loads to 77% in 2018, according to statistics from Mozilla. This is an incredible rate of change!

We’d like to thank all of the people and organizations who worked hard to create a more secure and privacy-respecting Web.

This year we created a new website for the legal entity behind Let’s Encrypt, Internet Security Research Group (ISRG), because we believe there will be other instances beyond Let’s Encrypt in which ISRG might be able to help to build, or improve access to, a better Internet.

While we鈥檙e proud of what we accomplished in 2018, we spend most of our time looking forward rather than back. As we wrap up our own planning process for 2019, We鈥檇 like to share some of our plans with you, including both the things we鈥檙e excited about and the challenges we鈥檒l face. We鈥檒l cover service growth, new features, infrastructure, and finances.

Service Growth

Let鈥檚 Encrypt helps to drive HTTPS adoption by offering a free, easy to use, and globally available option for obtaining the certificates required to enable HTTPS. HTTPS adoption on the Web took off at an unprecedented rate from the day Let鈥檚 Encrypt launched to the public.

The number of certificates and unique domains we support continues to grow rapidly:

We expect strong growth again in 2019, likely up to 120M active certificates and 215M fully qualified domains. You can view our recently revamped stats page for more information.

One of the reasons Let鈥檚 Encrypt is so easy to use is that our community has done great work making client software that works well for a wide variety of platforms. We鈥檇 like to thank everyone involved in the development of more than 85 client software options for Let鈥檚 Encrypt. Support for our protocol, ACME, is built in to Apache and we鈥檙e hoping 2019 will be the year that it comes to Nginx.

Other organizations and communities are also doing great work to promote HTTPS adoption, and thus stimulate demand for our services. For example, browsers are starting to make their users more aware of the risks associated with unencrypted HTTP (e.g. Firefox, Chrome). Many hosting providers and CDNs are making it easier than ever for all of their customers to use HTTPS. Government agencies are waking up to the need for stronger security to protect constituents. The media community is working to Secure the News.

New Features

In 2018 we introduced several new features, including ACMEv2 support and wildcard certificates. We鈥檝e got some exciting features planned for 2019.

The feature we鈥檙e most excited about is multi-perspective validation. Currently, when a subscriber requests a certificate, we validate domain control from a single network perspective. This is standard practice for CAs. If an attacker along the network path for the validation check can interfere with traffic they can potentially cause certificates to be issued that should not be issued. We鈥檙e most concerned about this happening via BGP hijacking, and since BGP is not going to be secured any time soon, we needed to find another mitigation. The solution we intend to deploy in 2019 is multi-perspective validation, in which we will check from multiple network perspectives (distinct Autonomous Systems). This means that potential BGP hijackers would need to hijack multiple routes at the same time in order to pull off a successful attack, which is significantly more difficult than hijacking a single route. We are working with a talented research team at Princeton to design the most effective multi-perspective validation system we can, and have already turned parts of this feature on in our staging environment.

We are also planning to introduce a Certificate Transparency (CT) log in 2019. All certificate authorities like Let鈥檚 Encrypt are required to submit certificates to CT logs but there are not enough stable logs in the ecosystem. As such, we are moving forward with plans to run a log which all CAs will be able to submit to.

We had planned to add ECDSA root and intermediate certificates in 2018 but other priorities ultimately took precedence. We hope to do this in 2019. ECDSA is generally considered to be the future of digital signature algorithms on the Web due to the fact that it is more efficient than RSA. Let鈥檚 Encrypt will currently sign ECDSA keys from subscribers, but we sign with the RSA key from one of our intermediate certificates. Once we have an ECDSA root and intermediates, our subscribers will be able to deploy certificate chains which are entirely ECDSA.

Infrastructure

Our CA infrastructure is capable of issuing millions of certificates per day with redundancy for stability and a wide variety of security safeguards, both physical and logical. Our infrastructure also generates and signs around 40 million OCSP responses daily, and serves those responses approximately 5.5 billion times per day. We expect these numbers to grow approximately 40% in 2019.

Our physical CA infrastructure currently occupies approximately 55 units of rack space, split between two datacenters, consisting primarily of compute servers, storage, HSMs, switches, and firewalls. When we issue more certificates it puts the most stress on storage for our databases. We regularly invest in more and faster storage for our database servers, and that will continue in 2019.

All of our infrastructure is managed by our Site Reliability Engineering (SRE) team, which is comprised of six people. SRE staff are responsible for building and maintaining all physical and logical CA infrastructure. These staff are largely responsible for our high standards for security and compliance. The team also manages a 24/7/365 on-call schedule and they are primary participants in both security and compliance audits.

Finances

We pride ourselves on being an efficient organization. In 2019 Let鈥檚 Encrypt will secure a massive portion of the Web with a budget of only $3.6M. We believe this represents an incredible value and that contributing to Let鈥檚 Encrypt is one of the most effective ways to help create a more secure and privacy-respecting Web.

Our 2019 fundraising efforts are off to a strong start with Platinum sponsorships from Cisco, OVH, Mozilla, Google Chrome, Electronic Frontier Foundation, and Internet Society, as well as many other Gold and Silver sponsors. The Ford Foundation has renewed their grant to Let鈥檚 Encrypt as well. We are seeking additional sponsorship and grant assistance to meet our full needs for 2019.

Support Let鈥檚 Encrypt

We depend on contributions from our community of users and supporters in order to provide our services. If your company or organization would like to sponsor Let鈥檚 Encrypt please email us at sponsor@www.syntaxclothes.com. We ask that you make an individual contribution if it is within your means.

We鈥檙e grateful for the industry and community support that we receive, and we look forward to continuing to create a more secure and privacy-respecting Web!

]]>
http://www.syntaxclothes.com/2018/12/31/looking-forward-to-2019.html
小草在线影院观看在线播放-电影大全 - 高清在线观看 - 海量高清视频免费在线观看