Let's Encrypt Root Trusted by All Major Root Programs

https://letsencrypt.org/2018/08/06/trusted-by-all-major-root-programs.html

by okket • 8 years ago

1532 144 8 years ago

wwhitlow• 8 years ago

That's great I'm always glad to hear about the progress updates from them. Setting there service up on my personal website was one of the easiest improvements I have ever made. Thanks mostly to the fact that I have shell access to the server I host on. The auto renew works perfectly haven't even had to put thought about renewing my cert since last year and Let's Encrypt Certs don't last that long. We are getting very close for there to be no reason not to have an HTTPS connection to any website which is a great progression.

Thanks For Everything You Guys Have Done To Accomplish This Let's Encrypt!

classichasclass• 8 years ago

This is very good news, though they don't really show their work on that five year number. Are they waiting on a specific operating system to drop below a certain level?

duskwuff• 8 years ago

Reading between the lines a bit: the last major vendor to accept the ISRG Root was Microsoft. Windows is supposed to pick up new roots through updates, but there are probably enough systems out there with updates disabled or broken that it's safest to wait a few years for them to cycle out.

collinmanderson• 8 years ago

They'll probably re-evaluate market share once they get closer to the five year number. I bet they'll find they'll need to cross-sign for more like 10 years.

tialaramex9• 8 years ago

I don't have an explanation for the five years beyond your guess.

Rather sooner, at the end of September 2021 the DST Root CA X3 that cross-signs their existing intermediates expires.

In practice many systems don't directly obey expiries baked into root certs, a self-signed root certificate is largely a vehicle for conveniently moving the key inside it, it's not signed by anybody we trust independently so why care what it does or does not say about that key?

And of course if the IdenTrust / ISRG relationship remains good there's no reason IdenTrust can't sign new Let's Encrypt intermediates with another of their CA roots that hasn't expired. The short lifetime of Let's Encrypt leaf certs means they wouldn't even need to have decided before 2021 what to do about this.

hardwaresofton7• 8 years ago

Glad to hear this! Let's Encrypt is such an amazing resource -- it single-handedly caused a leap in internet security as well as removing what was essentially a artificially inflated (IMO) barrier to entry (for most people) to getting certs.

Has anyone set up the new wildcard certs? If so, who did you choose as your DNS 01 Challenge[0] provider? I currently do DNS through a local provider and they don't have an API so it's been out of my reach.

DrPhish• 8 years ago

For wildcard certs, I run my own DNS infrastructure, so I just created the _acme-challenge records as indicated by the first run of certbot

Are you unable to add arbitrary TXT records with your provider?

hardwaresofton7• 8 years ago

I am, but I'm trying not to do it manually -- I actually use cert-manager[0] on a tiny kubernetes cluster -- which means when I make an Ingress for an application (app.example.com) (which does what it sounds like), watcher processes kick off and go get a cert for me with http 01 validation currently. This works thanks to cert-manager being able to automate the process of setting up the proper /.well-known/xxx route with access to kubernetes features.

cert-manager also supports DNS 01, but of course they support the bigger providers (so they'll take some options and do the web requests to set up the TXT records)...

I haven't looked into it a crazy amount (since in the end I can still just make multiple http 01 validated certs), but was just curious.

[0] https://github.com/jetstack/cert-manager/

kragniz• 8 years ago

You can also set up a CNAME record to delegate the challenges to a provider with a supported API.

hardwaresofton7• 8 years ago

Thanks for the tip -- that sounds like a great way forward. I can't find any documentation on it however after checking the community page (https://community.letsencrypt.org/t/acme-v2-production-envir...)... Do you have a pointer to the documentation on this feature?

Thinking about it again I'm not sure that I fully understand what you were suggesting -- are you suggesting adding a CNAME for x.example.com that redirects to yyyy.different-provider.com, and letting let's encrypt follow and work it out?

I also wanted to know how everyone was trusting with their DNS requirements/how people were making the decision (cost, trust, privacy, country of origin, whatever else).

Ajedi322• 8 years ago

Doing it this way is also more secure, since it means you don't have to give your web server unrestricted write access to every DNS record under your domain.

acme-dns is specifically designed for this purpose: https://github.com/joohoi/acme-dns

luastoned• 8 years ago

I've had no issues with wildcard certs and Cloudflare as my DNS provider.

auslander12• 8 years ago

You're OK giving your browsing history to Cloudflare?

TomK32• 8 years ago

yeah, I bought a secondary domain for my budgeting project on Saturday and as soon as I had the dns configured I ran certbot on the server. something like 30 minutes from finding a good domain name to having ssl set up.

newman3142• 8 years ago

Haven't tried with the wildcard certs yet but I've been using lego + Cloudflare as the DNS challenge provider with no issue. Works very nicely and it's scripted to automatically renew every 60 days.

Now, it would be great if Cloudflare supported LE integration at it's free tier (replacing the Cloudflare wildcard cert).

scardine• 8 years ago

I use digitalocean, but also have a few wildcard manually verified with the --manual flag and a bit of cut & paste. It is 5 minutes every 3 months but it is free so I haven't bothered to automate it (just get an intern doing it every couple months). Lame, I know.

h1d2• 8 years ago

Wildcard certs suddenly make auto renewing a challenge. For now, I just manually do it by updating DNS when monit tells me certs are getting old.

karlgrz• 8 years ago

I use digitalocean's DNS and had no problems getting wildcard certs. It's a bit annoying to wait for the updated records to resolve but other than that I had no issues.

projektir2• 8 years ago

I would really like it if some of these services would support non-Paypal donations. I have little interest in supporting Paypal and their questionable practices, but many services have no other donation option.

jaas2• 8 years ago

We provide multiple options, including PayPal. The primary option here uses Stripe via DonorBox:

https://letsencrypt.org/donate/

projektir2• 8 years ago

Looks like the Stripe widget is completely invisible when JS is disabled, so all I saw was the PayPal button. There isn't even so much as a link or text, it's just completely blank.

Now I'm wondering how many invisible Stripe widgets I've been missing.

schoen• 8 years ago

Just in case anyone isn't aware, this isn't about browser compatibility today (which uses the DST certificate from IdenTrust) but about future compatibility without the IdenTrust cross signature.

https://letsencrypt.org/certificates/

Edit: lvh has explained this better at https://news.ycombinator.com/item?id=17699037

mholt• 8 years ago

Also of note, they've raised the rate limit for certificates per registered domain per week: https://community.letsencrypt.org/t/certificates-per-registe...

The ‘certificates per registered domain per week’ limit has been raised from 20 to 50.

https://letsencrypt.org/docs/rate-limits/

driverdan• 8 years ago

Why would you need 50 new certs a week for a single domain?

dumbfounder• 8 years ago

"The main limit is Certificates per Registered Domain, (50 per week). A registered domain is, generally speaking, the part of the domain you purchased from your domain name registrar. For instance, in the name www.example.com, the registered domain is example.com. In new.blog.example.co.uk, the registered domain is example.co.uk. We use the Public Suffix List to calculate the registered domain.

If you have a lot of subdomains, you may want to combine them into a single certificate, up to a limit of 100 Names per Certificate. Combined with the above limit, that means you can issue certificates containing up to 2,000 unique subdomains per week. A certificate with multiple names is often called a SAN certificate, or sometimes a UCC certificate."

Operyl5• 8 years ago

In my case, we provision a wild card for accounts on our service (*.account.companycustomers.com). While we bundle these together with a few other sign ups, it's sometimes better to get it out the door initially, and then bundle them with more subdomains on renewal. We have received an exemption to the certificate limit per domain to achieve this at least.

apawloski• 8 years ago

Because you could have 50 subdomains, for which you'd need either a wildcard cert or 50 separate certs.

That might seem like a ton per week, but consider a PaaS (example-123.herokuapp.com) or a blog platform (example-diary.someblogapp.com).

Personally I'd prefer a wildcard cert there, but at organizations where certificate inventory is a requirement (where they need to track, procure, and invalidate on a per-subdomain basis) Let's Encrypt is a solid option.

profmonocle2• 8 years ago

The 20 per week limit has been an issue for large organizations with tons of different subdomains managed by different groups. Universities are a good example: you might have things like bobsmith.faculty.example.edu, cs101.compsci.example.edu, etc., which all count against the example.edu rate limit.

This can especially be a problem because the renewal exception to the rate limit doesn't work like you might expect. If a particular cert (meaning the exact same set of domains) has already been created, it can be renewed regardless of whether it would exceed the rate limit - but it still counts against the rate limit. If 45 certs have already been renewed in the last week, you can only create 5 new ones. If 80 certs have been renewed in the last week, you can't create any new ones. They plan to change this, but it hasn't happened yet: https://github.com/letsencrypt/boulder/issues/2800

Some organizations have gotten rate limit exceptions to handle this particular issue. Maybe they looked at some internal metrics and decided raising it to 50 would reduce the number of exceptions they have to make while still curbing misuse.

lvh3• 8 years ago

Some context on how this works: your system (usually OS) ships with a bunch of root certificates that are allowed to sign any certificate (de facto). New CAs need to get in that store to be trusted, but they don't get to be in that store until they convince a vendor (here, "root program") to include them.

But LE has been around for a while and its certs mostly work fine everywhere! That's partially because it was already in a ton of root programs, and partially because of cross-signed roots. A cross-signed root is effectively the root CA except signed by a different CA. A client that doesn't trust the new root yet trusts it via the cros-signed root.

Most sites need 2 certificates in the chain to be validated: the leaf certificate certifying the site itself and the intermediate online CA that signs leaf certs. The intermediate is signed by the root, which is in your trust store so you don't need to send it. Lots of sites send it anyway. This is a misconfiguration and just serves to make TLS connections slower: you're sending an extra certificate along that by definition nobody uses. This is because it's self-signed: you either already trusted it anyway (and then didn't need it) or you don't trust it and then the self-signed certificate is unconvincing.

New CAs also need their cross signed root sent along to be widely supported, so they basically get that worse performance all the time. Unfortunately, you don't know in advance which roots a TLS client will trust, so until you're in every major trust store, you have to. Now that LE is in every major trust store, it's a real first-class CA and everyone gets to look forward to doing away with the cross-signed root crutch. (You can't do it immediately because old, unpatched machines.)

LE is great and has done wonders to make all the other CAs up their game.

You can read more about LE's trust chain here: https://letsencrypt.org/certificates/

tialaramex9• 8 years ago

A reason you might want to send a "root" in some cases:

New roots get spun up all the time (maybe a dozen a year? That sort of ballpark). For Let's Encrypt that meant the cross signing arrangement described, but for an existing CA they can use their older roots to sign newer ones while they wait for trust stores to do their thing, this produces a certificate for the same name, but instead of being self-signed it's signed by the old root.

If you send this cert as well as your ordinary intermediate, some older clients that had no reason to trust the intermediate can now connect it back to a root they do trust. So for a few bytes you get a compatibility win.

This type of thing is also done when a root is replaced urgently due to distrust. Clients that are on top of their game trust the replacement root. Clients that don't know about this distrust trust the old root, which has signed the replacement. So everybody trusts the replacement, yet up-to-date devices aren't at risk from the old root any more.

A mechanism called AIA chasing lets browsers which use it "fix" an incomplete chain, but at some cost to privacy, another approach is to cache bits of chains and try to use the cached bits to fix broken chains, again this has privacy problems. Definitely send your intermediate (any modern leaf cert in the Web PKI has an intermediate) but more might be necessary.

I would like to see AIA chasing done by TLS servers (there's no major privacy concern there) so that this isn't extra work for admins, but we don't live in that world, so it's on you (or tools you use) to get it right.

lvh3• 8 years ago

You're correct, but for clarity for those playing along at home: that's just another variant of a cross-signed root. It's not an actual root CA in the sense that I was using it (self-signed): that is still always pointless.

tialaramex9• 8 years ago

Interestingly, as shown in the diagram you've linked, in this particular scenario, Let's Encrypt didn't have IdenTrust (owners of the DST Root CA X3 used for the cross signature) sign their new root (ISRG Root X1). Instead DST Root CA X3 was used to sign Let's Encrypt's intermediates, so there isn't actually anything to "do away with" really.

As a result there are two versions of each intermediate certificate, one signed by DST Root CA X3, one signed by ISRG Root X1. The URL for the former is baked into your leaf certificate, you _can_ configure servers to send the other version, and Let's Encrypt in fact does so for the test server required by Mozilla's CA root trust program, but most people don't need to do that.

If there ever is a good reason to switch over (maybe in a few years when DST Root CA X3 is due to expire) thanks to the relatively short lifetime of Let's Encrypt certificates they can move all their subscribers (at least, all those with compliant ACME implementations, if you hard code everything you get to keep both halves when it breaks) without those subscribers needing to even know about it, let alone make any changes.

0xakhil• 8 years ago

If somehow the private key of a root CA gets leaked, will that make all devices vulnerable?

Also what is stopping a government from getting access to these private keys?

saalweachter• 8 years ago

Yes; nothing.

lvh3• 8 years ago

Until we discover the compromise, yes. We have a few better tools for doing that now, like Certificate Transparency.

A number of CAs are effectively under the control of a government: https://ccadb-public.secure.force.com/mozilla/IncludedCACert...

The CABforum BRs define, de facto, the rules/requirements for being a CA: https://cabforum.org/baseline-requirements-documents/

DonHopkins• 8 years ago

I've heard great things about Let's Encrypt, many people who I trust use and trust Let's Encrypt, and I use and trust them too.

But beyond that warm fuzzy feeling, and what they write about themselves on their web site, I'd love to know more particulars about the nature of why they're different, why so many people trust them, how they came about, who's running it, who's supporting it, who are they competing against, and what their mission and back story is. Why are they pushing other CAs to up their game, and why weren't those other CAs doing what Let's Encrypt is now pushing them to do, in the first place?

Belphemur• 8 years ago

Provides an API to generate, renew and revoke certificate.

Provides certificate for free that are accepted by all browser/OS.

Let the user easily generate wildcard certificate if you control the domain link to it.

In other words, remove the human interaction.

Server can now easily and automatically renew certificate. No need to go through weird interfaces and obscure settings to always have an up-to-date certificate.

tcd• 8 years ago

Belphemur said it best: before LE SSL/TLS was relatively 'obscure', sure many sites had it, but it was an optional extra that cost a yearly fee. Now, any old joe bloggs can setup a webserver (or use tools like cPanel which have LE integrated) and get the nice shiny green padlock with 'secure' in their browser.

And, if you run your own server, their client even generates the configs for most major web servers on most major OS', so you don't even need to lift a finger. Type 1 command and boom, you're secure.

Doesn't get easier than that.

dddw• 8 years ago

congrats Letsencrypt!

burdzwastaken• 8 years ago

I am so proud of letsencrypt. This is a huge step forward for https everywhere!

forapurpose3• 8 years ago

Our root is now trusted by all major root programs, including Microsoft, Google, Apple, Mozilla, Oracle, and Blackberry.

What about Linux and the BSD's?

Tangential questions: OS's usually are the system's primary stores of root certs, if I understand correctly[0], but browsers and other applications store them too. How are conflicts resolved? If Mozilla untrusts Fubar CA's root cert and the OS still trusts it, what happens? And why have redundant stores? I suspect the answer is that the browser vendor wants to ensure the user has a happy TLS experience despite OS problems, but that's just a reasonable guess.

[0] A reference right in front of my nose: https://news.ycombinator.com/item?id=17699037

hsivonen2• 8 years ago

What about Linux and the BSD's?

Linux distros typically use Mozilla's root list.

If Mozilla untrusts Fubar CA's root cert and the OS still trusts it, what happens?

Then it no longer works in Firefox but works in other apps.

walrus013• 8 years ago

using debian as an example, the ca-certificates package uses the mozilla root CA list as an upstream source.

https://packages.debian.org/stretch/ca-certificates

tialaramex9• 8 years ago

To answer your tangent: Only two major browser vendors also operate a distinct major trust store. If you're Microsoft (IE, Edge) or Apple (Safari) this is de facto not a problem since you also control the OS.

For Mozilla their NSS is almost completely independent of OS trust stores, with the special case that on Windows (maybe macOS but I'm not sure) they offer to look in your OS trust store for any additions you've made to the OS vendor store and trust those on the rationale that you must have had some reason to do that.

For Chrome the OS trust store is used, (on Android this of course is Google's trust store but on a desktop it isn't) but, Chrome layers some Google policy rules on top.

forapurpose3• 8 years ago

Thanks; that's helpful. One point confuses me:

Only two major browser vendors also operate a distinct major trust store. If you're Microsoft (IE, Edge) or Apple (Safari) this is de facto not a problem since you also control the OS.
For Chrome the OS trust store is used, (on Android this of course is Google's trust store but on a desktop it isn't) but, Chrome layers some Google policy rules on top.

If only two major browser vendors operate a distinct major trust store, and they aren't Microsoft or Apple, I infer that Google operates a distinct major trust store (along with Mozilla). But that seems to contradict the second statement: Why operates a trust store that you don't use. For ChromeOS?

dev_dull• 8 years ago

It’s amazing to me that there a multiple entities which can sign valid TLS certain for the same domain. Seems like a serious design flaw, especially with some of those trust authorities being overseas

jaas2• 8 years ago

You can limit that by deploying CAA records for your domain in DNS. All trusted CAs are required to respect those records.

pornel• 8 years ago

This is being fixed:

• You can use CAA DNS records to choose which CAs can create certs for your domain.

• You can watch Certificate Transparency logs to catch CAs that didn't obey.

AFAIK both are becoming mandatory for CAs. It doesn't technically stop violations, but ensures they get caught and shut down if they fail to obey the rules (like StartCom and Symantec).

kardos3• 8 years ago

You can watch Certificate Transparency logs to catch CAs that didn't obey.

Isn't there a timing issue there? Eg, if I get a cert from Comodo and change my CAA record to specify Let's Encrypt immediately afterwards, anyone checking if issuer doesn't match CAA can get a false positive

Spivak• 8 years ago

Will browsers actually refuse a 'valid' cert if my DNS record indicates a different CA than the one presented?

SmellyGeekBoy• 8 years ago

Damn those untrustworthy "overseas" people, the only trustworthy people happen to be born in the same place I was! (Wherever that is)

lawn• 8 years ago

As a side question is there a guide to setup https for a static website hosted at AWS buckets?

jimwalsh• 8 years ago

Yes, you will need to front the bucket with CloudFront and use the AWS Cert Manager to manage your own cert or to get one through AWS (free) and apply it to CloudFront.

geofft• 8 years ago

I looked at using Let's Encrypt for this, but it's much simpler to use AWS Certificate Manager's own certificate authority for this, because it's also free and it's built in so it will handle renewals for you. It's basically a checkbox in CloudFront; just put your files in S3 and set up a CloudFront distribution.

(If you're hosting an apex domain, e.g., example.com and not just www.example.com, it also makes things easier if you can use Route 53 as your DNS host, because CloudFront IPs keep changing and you can't make a CNAME for an apex.)

mahesh_rm• 8 years ago

Cloudflare is your friend. Either with a cloud front distribution or with a simple S3 bucket website. Guide: step 1, sign up for free at cloudflare. Step 2, follow instructions. As simple as it comes!

Qwertie2• 8 years ago

Doesn't that only encrypt half the trip?

bks• 8 years ago

Congratulations to the LE team, we have been a very happy major sponsor the product. It works amazingly well in conjunction with Caddy for https://www.phishprotection.com.

I would be very interested to see the percentage of the Internet that is actively using LE certificates vs. the number of certificates that have simply been generated for valid domains.

kimdotcom• 8 years ago

JRE7?

tialaramex9• 8 years ago

That's a very terse question, but I'll take it that you're interested in whether TLS clients running on Java 7 will (out of the box) trust Let's Encrypt server certificates

The answer is that for Oracle's Java updating to 7u111 is necessary for this to work (or to 8u101 if you run Java 8) and that for other people's Java implementations it will depend upon where they get their trust store, Oracle's is the most popular in Java.

rushughes2• 8 years ago

Is Let's Encrypt good enough for say a production e-commerce site, or is it more for personal blogs and the HTTPS everywhere movement?

blahyawnblah• 8 years ago

Its certs are the same in the end as anyone else's certs. You just don't have to pay or go through a bunch of hoops to get one.

Fine for e-commerce. They don't do extended validation or any of the more "I am really who I say I am certs."

mike1o1• 8 years ago

Shopify uses Let Encrypt for their shops, so I'd imagine it's pretty safe for e-commerce sites.

https://www.shopify.com/blog/73511365-all-shopify-stores-now...

rushughes2• 8 years ago

Awesome, that's great to hear! Thank you.

perlgeek• 8 years ago

Let's Encrypt gives you a DV (domain validated) cert. That is good enough for most use cases, including amazon.com.

Most German banks for example use EV (extended Validation) certs, where the organization name appears in the browser's address bar. However, the benefit of EV certificates is debatable, since it's pretty easy to register a valid-sounding company under some jurisdiction or another.

Also, organization structure aren't transparent to everybody (how many of your non-tech friends would be surprised if google.com had a certificate issued for "Alphabet Inc."?).

gsnedders2• 8 years ago

Also, organization structure aren't transparent to everybody (how many of your non-tech friends would be surprised if google.com had a certificate issued for "Alphabet Inc."?).

A clear example of this is KLM, where www.klm.com's certificate is registered to "KONINKLIJKE LUCHTVAART MAATSCHAPPIJ N.V." (try that on a mobile browser!). It's sufficiently different to what people expect (which is, admittedly, just an initialism) that I've known various people who actually understand EV certificates get thrown by it.

Qwertie2• 8 years ago

I heard the cost of EV certs is pretty high so it's much less likely a scammer will buy an EV cert vs just a similar domain and a regular cert.

snowwrestler• 8 years ago

Amazon.com does not have DV cert, they have an OV cert. You can tell because the country, state, locality, and organization name fields have values. In a DV cert they are empty (since a DV cert does not verify those things).

Like a lot of big companies, Amazon has a cert from Digicert. To my knowledge, Digicert does not issue DV certs, only OV and EV.

That said, I agree that DV certs are good enough for production for most people.

walrus013• 8 years ago

From a technical standpoint it's no different than any other DV (domain validated) cert. If you're selling a LOT of stuff online and care about user interface, the $85/year that it costs to have an EV SSL cert may be worth it just for the "green bar" user interface change which seems to be reassuring to non-technical users.

They're used to seeing EV SSL type address bar when they sign in to their online banking and such.

Some people think that EV SSL is like $400, it's not, you really shouldn't be paying over $100/year. Still a racket in my opinion but not one that's easy to circumvent.

https://www.google.com/search?q=EV+SSL+user+interface&num=10...

h1d2• 8 years ago

It's almost a false sense of "reassuring" as the users are blindly made to think it may be more trustworthy, in fact they don't know who did what to gain the (fake) trust.

apo• 8 years ago

Odd question I know, but does this mean that LE certs can be used to sign Java applets?

newman3142• 8 years ago

The last time I looked into this, the LE certs did not support code signing.

tialaramex9• 8 years ago

No. Let's Encrypt is focused only on the Web PKI. So that includes web servers (obviously), and everything that speaks TLS on the Internet (e.g an IMAP server for your email) but it doesn't include either type of end-to-end email encryption (S/MIME or PGP), nor any kind of code signing, document signing, timestamp services or similar.

Technically this is implemented in two ways. One: Where Trust Stores themselves have distinct trust for different feature sets, ISRG/ Let's Encrypt asked only for the flags needed to do Web PKI. e.g. In Mozilla they didn't ask for S/MIME or code signing (today Mozilla doesn't do code signing anyway).

Two: Certificates have a section called Extended Key Usage (EKU) which can list arbitrary purposes for which the certificate's issuer says the Public Key included in this certificate is to be used. EKUs on Let's Encrypt certificates specify two purposes, 1.3.6.1.5.5.7.3.1 (TLS Server) and 1.3.6.1.5.5.7.3.2 (TLS Client) so these certificate proclaim themselves not to be suitable for other purposes.

pritambaral• 8 years ago

I wonder why LE certs specify TLS Client EKU.

jmtame• 8 years ago

I'm wondering when I can use them for my wildcard SSL certs on Heroku. Anyone hear of them adding support?

Ajedi322• 8 years ago

`certbot --certonly` + `heroku certs:add` + cron?

tialaramex9• 8 years ago

Here's Microsoft's notice:

https://social.technet.microsoft.com/wiki/contents/articles/...

I don't know anything about Gordon Bock (credited with that page), or indeed Microsoft's PM for their root trust programme, Mike Reilly. All the trust programmes (except Mozilla's) are run in a way that doesn't give us (as relying parties, or as subscribers) much insight. I'd love to know more about why it took so long to approve ISRG, but likely we'll never be told.

thingsilearned• 8 years ago

Congrats Josh!

samgranieri• 8 years ago

Awesome!

azerooth• 8 years ago

congrats

quintin• 8 years ago

I have a letsencrypt cert for my domain but I still use the cloudflare’s certificate and terminate (I keep my cert code commented). I do think so that I reduce the load/content between Cloudflare and my web server.

Is this a good approach? FYI, I have a blog and not too paranoid about security between CF and my web server.

Let's Encrypt Root Trusted by All Major Root Programs

Related Stories