Location of letsencrypt.org issuance policy documentation


#1

I am looking for the letsencrypt.org issuance policy documentation, especially containing the list of allowed domain ownership validation methods. I am interested in to know specifically about the use / exclusion of TLS-SNI method since the flaw was discovered at the beginning of 2018.
Unfortunately I did not found document in https://letsencrypt.org/repository/, but may be I was not careful enough and overlooked it.


#2

Hi @bruncsak

do you want to use the tls-sni-01 - validation? Or do you want to exclude it?

The tls-sni-01 - validation is deprecated. There is another (new) method tls-alpn-01 instead.

https://tools.ietf.org/html/draft-ietf-acme-tls-alpn-01

So you may find nothing in the documentation.


#3

Hi @JuergenAuer,

I am not interested in using the TLS-SNI method. I am the DNS administrator of the domains of my company, so I can issue any certificate using DNS-01 method, so far all good.
The point is that our security administrator told: “Letsencrypt has a serious security issues and I’d not recommend it at all.”
I am interested to know is it true or not that he wrote. I need to access a policy document from Letsencrypt that Letsencrypt do not use the TLS-SNI method to issue certificate at all. If it is still issuing then under which condition or restriction. Otherwise I am screwed not on technical but on trust level with Letsencrypt.


#4

Except that’s not the case. There are many active accounts using TLS-SNI.

See this post:


#5

Then he should create an account and start a thread.


#6

Hi @_az,

Thanks for the reply. I would like to know as well those white-list exceptions are how long maintained? How much time does it take to switch to reliable method? It must be very short, since in the post it is mentioned that they are ‘large’ hosting providers, so they must have enough resource to fix it quickly. Since TLS-SNI method is in use there, theoretically those providers may issue certificates for the domain names my company is owning. Here my trust in Letsencrypt has implicitly transferred to those hosting providers and I dislike that situation. What can I answer to my security officer?


#7

TLS-SNI is also in use by (probably 10s or 100s of thousands of) regular individual users using e.g. Certbot. There hasn’t been any sunset announced.

If your existing ACME accounts (if any) didn’t already meet the renewal whitelist criteria written in the post, then there’s no way to issue a certificate with TLS-SNI for them today.

So it really shouldn’t be a concern to you. Whether you issue a certificate using this CA or that CA doesn’t affect the security of your domain - each CA is still trusted by browsers in the end.

The upcoming ACME CAA extensions will also allow you to restrict what validation methods the CA may use for your domains.

example.org. IN CAA 0 "letsencrypt.org; validationmethods=dns-01"

#8

I have no any ACME account which used TLS-SNI. That is not a problem. A problem arise if someone else has an ACME account which used TLS-SNI in the past, and from now on he could issue certificate for my domains using that account.


#9

Use

https://crt.sh/

or

https://transparencyreport.google.com/https/certificates

to check if there are certificates


#10

They can’t, because the criteria requires that the ACME account was also the last account to issue a certificate for your domain. If they haven’t issued a certificate for your domain, they have no way to start now.

Maybe those ACME accounts that have a cart-blanche to issue TLS-SNI for any domain (the “large hosting providers” aka CDNs) could issue certificates for your domain, but that pretty much requires them to be hosting your domain, and I’m sure they’ve been vetted such that their TLS-SNI implementations are not vulnerable anyway.


#11

They do not need the control of my domain, that is the flaw in the TLS-SNI or am I wrong? And that is the implicit transfer of trust from Letsencrypt to the hosting provider I was mentioning earlier. May I trust they code? May I trust their intention?


#12

The hosting provider isn’t an adversary in this scenario.

There’s a thin slice of a scenario in which a still-vulnerable TLS-SNI implementation by one of those whitelisted ACME accounts could lead to a mis-issuance (by other users of the host, not the host themselves), I can grant you that much. You’d have to actually be using that host though, by pointing your domain to them.

If your sysadmin is not happy with that, then that’s up to them. Maybe you can re-kindle the discussion once ACME CAA extensions are deployed to production and you can enforce the non-usage of TLS-SNI.


#13

The problem with this mindset is that it misses the big picture. If you’re concerned about misissuance (as you should be with any CA), that’s a concern whether or not you use that CA. If a CA is insecure (or goes rogue), it can issue for your domain whether you use that CA or not, unless you lock out that CA using CAA records. And if you’re going to use CAA records, you can also specify in those records which validation methods LE will use to issue.


#14

Yes, CAA may help if I can be explicit with allowed domain ownership validation method. I am waiting this to be deployed on the boulder server.
There is theoretical problem with CAA (DNS tree traversing) but that is an off-topic here.


#15

Well, I know how that work theoretically. All the certificate are enlisted there which was issued to my domains.
I have only trouble to use it practically. I have the find the only certificate which was issued to someone else than me (the bad guy) from the thousands of certificates I legitimately issued. But I guess it is off-topic here.


#16

I used CAA in the past and I had to stop using it. There is a serious theoretical problem with the method of identifying the DNS record for a given domain name of the certificate, it is using DNS tree traversal. It is a killer for the sites which has different subdomains under different administrative entities. CAA is bad in its current form. Sorry being off-topic.


#17

Do you have a reasonably comprehensive view of which hosting providers and software platforms your company’s domain names use? The TLS-SNI vulnerability is a risk only if you have domains whose A records point to a hosting provider that allows third parties to upload arbitrary certificates for domains they do not control. It sounds like you have a relatively tightly controlled infrastructure, so I’m guessing that may not be the case for your domains?

In terms of time to switch off the TLS-SNI whitelist: We’ve taken a few months, because we wanted to standardize the replacement TLS-ALPN validation method. We’ve recently released that method on our staging servers and should be turning it on in production soon, after which we can start switching off the “major integration” part of the whitelist. The “renewal whitelist” will remain in place several months longer to minimize disruption of unattended renewals, but will also be phased out.


#18

The problem with the tls-sni-01 challenge was that customers within one hosting provider could possibly issue certificates for another customer, without consent of the original owner of the domain.
The hosting provider would have been able to issue certificates for all their customers, and only for their customers.

If your domains DNS entry doesn’t point to an IP of any tls-sni-01 challenge using hosting provider (which would have been white-listed by Let’s Encrypt anyway, so they would have been vetted to be secure), there’s no issue with the tls-sni-01 challenge anyway.

So to recap: the tls-sni-01 challenge was a security issue limited to within the confines of the hosting provider itself, where customers could possibly issue certs for another customer, but NOT for random domains outside of the hosting provider. Therefore, it shouldn’t be an issue for you.


#19

Hi @jsha,

Thanks for the reply. Most of our domains are hosted on our infrastructure. But we have some hosting as well on wpengine.com, talentlms.com, azurewebsites.net, and may be some others too, I just quickly looked at the most trivial ones from our DNS. Should I interpret that the TLS-SNI is a kind of extension of the HTTP method, that there is the requirement of my domain pointing to an IP address, and only precisely on that IP address it is possible to fulfill the challenge for the given domain name?


#20

HTTP-01 and TLS-SNI-01 are different in almost every detail, but…

Yes. They’re the same in that way.

(HTTP-01 will follow redirects, though.)