
Let's Encrypt: an automated certificate authority to encrypt the entire web - godelmachine
https://blog.acolyer.org/2020/02/12/lets-encrypt-an-automated-certificate-authority-to-encrypt-the-entire-web/
======
3dfan
It's still a pain in the ass to manage wildcard certificates with letsencrypt.

Especially when your DNS registrar does not support DNS changes via API.

And even _if_ the registrar supports it, you have to build and maintain the
code that talks to the API. Yuck.

I wonder why they don't allow whover controls the domain name to use the
domain/.well-known/acme-challenge to create wildcard certs that are valid for
all subdomains of that domain.

~~~
hannob
My personal take on this is that with easy automation wildcard certificates
simply shouldn't be used any more.

In the past one reason for wildcards was that it's too annoying to request
certs for each subdomains. With automation this reason goes aways.

The other reason is that you can have "secret hostnames". But if your security
relies on secret hostnames that's a bad idea to begin with. You still leak the
hostnames to the DNS and as long as we don't have ubiquitous DoH+ESNI also to
the network.

Wildcard certs on the other hand have certain risks. If you have a
vulnerability in the TLS stack on subdomain1.example.org that may compromise
the security of subdomain2.example.org if they share the same cert.

~~~
jacobparker
Wildcards have use cases. An example:

You have a .example-usercontent.com wildcard certificate for domains like
user-1234.example-usercontent.com and you have millions of users. A wildcard
certificate is appropriate because:

* LetsEncrypt rate limits are a thing

* The domains exist to leverage origin sandboxing in browsers, but are served by the same infrastructure. It's not more secure (but it is more complicated) to have more certificates here.

Generally, the assumption that two subdomains are served by independent
infrastructure is often wrong. Think of things like blogger.com/blogspot.com.
So the concern about compromising keys doesn't really apply.

------
rkagerer
_Initially, ISRG was funded almost entirely through large donations from
technology companies. In late 2014, it secured financial commitments from
Akamai, Cisco, EFF, and Mozilla, allowing the organization to purchase
equipment, secure hosting contracts, and pay initial staff. Today, ISRG has
more diverse funding sources; in 2018 it received 83% of its funding from
corporate sponsors, 14% from grants and major gifts, and 3% from individual
giving._

~~~
castillar76
This is good, because having something that owns ca. 60% of the SSL
certificates on the internet supported by corporate largesse is not a good
route forward. I'm glad that's shifting.

------
pornel
It's fantastic that Let's Encrypt made short(er)-lived certificates possible.
With automation in place it doesn't matter if the cert lives a year or a week.
Eventually it will get short enough that we won't have to bother with
revocation lists, OCSP, etc.

~~~
tialaramex
In the medium term the intent here is Delegated Credentials. The TLS working
group is putting the finishing touches on a mechanism which goes like this:

You still have TLS certificates like today, but the private key corresponding
to the public key in that certificate lives on a dedicated machine that's not
accessible to the outside world, rather than your web server.

This dedicated machine uses the private key to sign tiny messages which
basically say "I, the owner of this TLS certificate you've seen, authorise
this web server for a short period (say 24 hours) to prove its identity using
a short-lived key which you can verify using public key P".

Then your web servers serve up the TLS cert (for which they don't know the
private key) this short message with P in it, and proof they do know their
short-lived private key which can be verified using P. Browsers check the
certificate, the delegated credential message and so on and you've got all the
same security but with much shorter lived credentials.

This way, when somebody finds a zero day in your tremendously complicated web
site and uses it to steal the private key, that key is only valid for maximum
24 hours and so you can close their window of opportunity relatively swiftly
if you're on top of it. Meanwhile the dedicated server for making the signed
messages is not publicly accessible and can be simpler and thus more secure.

This isn't really a way forward for making toy web sites with 1000 visitors
per day, but if you're building anything where you already have multiple
servers possibly in different locations then it's more interesting.

------
jhoechtl
I have deep concerns about the development to criminalize and ban non-https
web sites from functioning in mainstream web browsers. Many flee to
Letsencrypt certificates which have a short TTL frame.

What if Letsencrypt gets bought by Google / Microsoft and the free lunch is
over? The end of the free web as we know it... ?

~~~
buboard
Lets hope that SSL certs will only be a temporary solution. Why can't we
switch to a system that doesn't depend on central authority?

In the meantime, it would be nice for letsencrypt to pledge not to take big
donations from corporates.

~~~
Spivak
> pledge not to take big donations from corporates

You mean the people who actually benefit financially from the service? Look, I
get the sentiment but this is a case where the incentives are remarkably
aligned. Companies that derive real business value from the service foot the
bill while the rest of the world gets free certs.

~~~
buboard
oops i mean big corporates, like, major companies throwing millions at them

------
feisuzhu
I'm always annoyed by the fact that no spec exists for a `intermediate CA for
a particular domain`. If it exists, multiple level wildcard pain disappears
and Subject Alternative Names stuff is not needed.

~~~
szubster
X.509 Name Constraints extension is what you are looking for. They are VERY
expensive when ordered from public CA, but we use them at work for internal
PKI.

~~~
yrro
Do real world https clients actually verify the end entity certificate against
the name constraints of all the certificates in the trust chain?

~~~
szubster
Yes, they are. The extension should be marked as critical, so if the client
does not understand it it should error out. At least java, go, curl and all
major browser support it.

------
evenh
There is an alternative ACME server implementation available from Buypass:
[https://www.buypass.no/ssl/products/acme](https://www.buypass.no/ssl/products/acme).
Haven't tried it personally, but they launched support for ACME v2 in late
2019.

------
throw0101a
ACME wasn't the first attempt at automating certs. See Simple Certificate
Enrollment Protocol (draft) and Enrollment over Secure Transport (RFC 7030):

* [https://en.wikipedia.org/wiki/Simple_Certificate_Enrollment_...](https://en.wikipedia.org/wiki/Simple_Certificate_Enrollment_Protocol)

* [https://en.wikipedia.org/wiki/Enrollment_over_Secure_Transpo...](https://en.wikipedia.org/wiki/Enrollment_over_Secure_Transport)

~~~
tialaramex
ACME's secret sauce is the name validation challenges, not present in SCEP and
other prior standards. The same people, roughly, worked on two things, one of
which is made very visible in ACME a published standard, but just as important
is the other side of the coin.

The Baseline Requirements [https://cabforum.org/baseline-requirements-
documents/](https://cabforum.org/baseline-requirements-documents/) from the
CA/Browser Forum set out shared rules for how a publicly trusted CA must do
its job. From the outset the BRs have been clear that a CA needs to somehow
validate that it's issuing the certificate for some-fqdn.example.com to the
people who actually have some-fqdn.example.com or else this PKI is futile. But
until relatively recently the BRs were pretty vague on how exactly they ought
to do that. As a consequence some CAs did an admirable job, many did a
passable job, some were a bad joke either through not grasping the threat
model or just ordinary incompetence.

A trusted CA for example once had a system which would check you owned
www.example.com by connecting to example.com over HTTP and making a request
for a magic document, say
[http://example.com/xyzzy.html](http://example.com/xyzzy.html) then it would
grep the reply from the server for a magic string, which was the same as the
name of the document, in this case xyzzy, and if it was found the check
passes. But wait a minute, this means if your server says "404 Not Found:
xyzzy.html was not found" the check passes and you get a certificate. Oops.
Now, not checking for a 200 OK was a bug, but even if you do check for 200 OK
this validation clearly more of a polite "Keep out" notice to bad guys rather
than any sort of actual defence.

So in the same period Let's Encrypt was being set up and ACME was being
defined, the CA/B Forum also reformed the BR definition of how to validate DNS
names using some of the same personnel. The result is the Ten Blessed Methods
(although right now there are actually more than ten of them) and ACME is an
automation of just three of those specific methods. Since then CA/B Forum has
also worked on obsoleting the riskier and less useful methods and creating
newer safer ones. Today that would be /.well-known/pki-validation/xyzzy.html
safely in a reserved namespace, and it'd need a value inside it that's either
entirely random or is determined by some other factor not under an attacker's
control (in Let's Encrypt the equivalent string is a hash of the LE user's
public account key).

Some of the Ten Blessed Methods are inherently kinda manual. Some just aren't
very universal. So ACME and Let's Encrypt focus on the three which are most
suitable for automation, surfaced in a way that is hopefully even more secure
than required by the BRs and made available to everyone.

------
shill_predictor
For me it was a cherry on top of my home built pipeline. I was able to learn
the general cert usage through setting up my CI/CD. It was fun and costed me
nothing.

~~~
Spivak
What does your pipeline look like? I've always wanted to do this but a lot of
CD systems are so heavy. Great at work but super overkill for a homelab.

~~~
shill_predictor
Gitlab for CI, Nexus for jars and docker containers and routing traffic with
traefik. Its super easy if you setup them using docker. I will move to jenkins
CI tough. Its plugin/ecosystem brings you much more value over gitlab.

------
orsenthil
Adrian does a great job in summarizing the Let's Encrypt paper. He highlights
all the important sections and gives the reader the complete overview of the
system. Thanks for the summary.

------
buboard
It s funny how free certificates are now easier to use than overpriced ones.
Knock on wood, letsencrypt works well , except when it doesn't , e.g. when you
remove a subdomain from your webserver and then it refuses to renew them for
the entire domain. But still it s the best thing to happen to the web in a
long time.

~~~
GuyPostington
You should post on the community forum if you ever experience an issue like
that again. Https://community.letsencrypt.org

~~~
buboard
thanks. it was actually my fault, i shouldn't have deleted the virtualhost.
but when you have many domains these things can happen

------
abrowne2
Kudos to the Let's Encrypt team for their service. I've used it in every
project. Much praise!

------
zeroz
Let's encrypt support for S/MIME would be great.

While seeing great progress in securing the web via HTTPS email still lacks
fundamental security. While I would love to see a functioning PGP or other
decentralized setup, network effects are a strong force and it's still to much
hassle for non-technical people. Free S/MIME would help me to distribute
secure e-Mail setup for friends & family.

Looking for free or cheap certificates there was no satisfying provider.
Either expensive, or not trustworthy server-side generated certificates, or
not compatible/ not trusted root authority, or dedicated Windows software for
generating certificates:

[0] [https://www.swisssign.com/email/email-id-
silver.html](https://www.swisssign.com/email/email-id-silver.html) [1]
[https://www.sslplus.de/bestellen/step1.html?cert=79](https://www.sslplus.de/bestellen/step1.html?cert=79)
[2] [https://www.dgn.de/e-mail-zertifikat-dgncert/](https://www.dgn.de/e-mail-
zertifikat-dgncert/) [3] [https://en.sklep.certum.pl/data-safety/id-
certificates/certi...](https://en.sklep.certum.pl/data-safety/id-
certificates/certificate-basic-id.html) [4]
[https://wiseid.com/pricing/](https://wiseid.com/pricing/) [5]
[https://www.actalis.it/products/certificates-for-secure-
elec...](https://www.actalis.it/products/certificates-for-secure-electronic-
mail.aspx) [6]
[https://volksverschluesselung.de/](https://volksverschluesselung.de/) [7]
[https://en.sklep.certum.pl/data-safety/id-
certificates/certi...](https://en.sklep.certum.pl/data-safety/id-
certificates/certificate-basic-id.html) [8]
[https://www.bundesdruckerei.de/de/loesungen/Certificate-
Serv...](https://www.bundesdruckerei.de/de/loesungen/Certificate-Service-
Manager#CSM) [9] [https://www.instantssl.com/](https://www.instantssl.com/)

~~~
Avamander
LE for domain-validated code signing would be good as well. Knowing an
executable came from a trusted domain even if it was mirrored or rehosted
sounds nice.

------
pfarnsworth
Can I use Let's Encrypt to sign my own personal CA so that I can issue certs
for my domain that are in that chain?

~~~
schoen
Nope! For various reasons, including that the IdenTrust cross-signature has a
path length constraint that doesn't allow any longer chains for this path.
Also, Let's Encrypt doesn't want to be responsible for supervising the
correctness of your CA's operations.

In theory this could be practical if you look at name-constrained delegations
but it seems to me that there are a lot of practical problems with making this
widespread. If you happen to be interested in discussing them in more detail,
come over to
[https://community.letsencrypt.org/](https://community.letsencrypt.org/) and
create a new "Issuance Policy" thread and we can get into it in more depth.
But the short answer to your question is simply no—Let's Encrypt doesn't offer
this service, isn't currently permitted to offer this service, and isn't
interested in offering this service.

------
mmmuhd
While let's encrypt is great I keep getting worried let not what happened to
the team managing openssl resulting to heartblead bug happen to the let's
encrypt team it would be a disaster

~~~
GuyPostington
Can you give some more insight on what happened to the team managing openssl
during that time? I remember being on-call at a job when the news dropped.

