Is Let's Encrypt going from savior to single point of failure (SPOF)?

That article (in french):


highlight the fact that Let’s Encrypt is now used by more that 50% of websites:
https://nettrack.info/ssl_certificate_issuers.html

Congratulations, btw!

But it’s a worrying situation… does Let’s Encrypt plan to help other initiatives to create alternatives?

We put a lot of time and effort into the standardization of the ACME protocol. Our server-side implementation is also 100% free software.

5 Likes
  • The standardization of the ACME protocol is indeed an excellent thing
  • The fact that the Boudler is 100% open-source and free software too

If a serious alternative wishes to start, they have to:

  • Find founding, for human resources, certifications and hosting.
  • They probably will reuse your open source back-end
  • What they will miss is an entry point as a trusted CA

Does Let’s Encrypt/ IRSG consider cross-signing such initiative?

(I’m aware that the risk - in the worst case scenario - would be the distrust of Let’s Encrypt by a browser.)

If LE/IRSG does consider it, what could be the terms?

If the concern is Let's Encrypt being a SPOF wouldn't a cross-signature from our organization to bootstrap trust in an alternative have the same problem?

2 Likes

Depends of the failure.

If it’s a not a revocation, it helps.

If it’s a revocation, it may still help they had the time to be trusted by the majority of browsers.

Furthermore, in the case of a revocation, it may impact only some Roots/intermediates.

Let’s Encrypt can’t use the Let’s Encrypt Authority X3 intermediate to sign other intermediates.

            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0

Let’s Encrypt could use the ISRG Root X1 certificate to sign other intermediates, but if that root continues to be valid, Let’s Encrypt could also use it to sign new Let’s Encrypt intermediates in case there is a problem with the old ones. So, there might not be a lot of marginal benefit from this course of action.

I’m sure Let’s Encrypt staff would be happy to talk to anyone who wants to set up a new ACME-based CA on the Let’s Encrypt model.

4 Likes

If an alternate CA – say, Lettuce ‘n’ Crypt – were created for redundancy, it would be prudent to stay away from Let’s Encrypt’s software, and design decisions, and even Go, and use a highly independent implementation. ACME can’t really be avoided, but any bugs, outages, or vulnerabilities are likely to be in the ACME protocol, or Let’s Encrypt’s software, or the Go libraries it uses. (Or HTTPS, or Linux, or…)

That would be very expensive, though.

4 Likes

:green_salad: :lock:

7 Likes

Can you put emoji in an intermediate certificate’s Common Name? :thinking:

1 Like

Hmmm, I think so!

1 Like

I doubt this can resolve all of the concerns about the risks created by Let’s Encrypt as a single point of failure, but it’s really nice to see that another CA is now offering a free ACME DV product: the Norwegian CA Buypass.

https://www.buypass.com/ssl/products/acme

At least acme.sh and Certbot are reportedly compatible with it, which is a good sign for the ability to use ACME clients with more than one CA.

2 Likes