> One of the most common ACME deployment failures observed in practice is
> for servers to be configured to serve only the end-entity certificate,
> without the intermediate certificates. This is a particularly pernicious
> problem because some browsers will still trust the resulting
>
> The most likely out-of-band channel is email, right? So the CA would
> send out email informing their customers that there's a new ToS, and the
> customer needs to explicitly agree to it in the next N days, or they
> will be unable to use the service.
>
> There are a couple of options the CA
I am inclined to think that this is a good change, on the basis that
it means that the server is minting the identifiers that the client
uses. I think that Jacob is probably understating the potential for
bugs here. And key canonicalization is a bad smell.
On 27 September 2016 at 14:51, Jacob
I understand the concern, but I think that clients already have to store
a significant amount of state: the ACME directory URL, the private key,
and the domain names, certificates, and private keys of existing
certificates. I think that one more item, the account URL, is not a
heavy burden,
One of the most common ACME deployment failures observed in practice is
for servers to be configured to serve only the end-entity certificate,
without the intermediate certificates. This is a particularly pernicious
problem because some browsers will still trust the resulting
one-certificate
On 09/24/2016 06:03 PM, Hugo Landau wrote:
>> Very specifically, I am trying to make life easier for clients that
>> hardcode the agreement URL.
> How can hardcoding the URL ever be legitimate?
Sorry, this was one of those worst-case typos. It should have read:
"Very specifically, I am *not*
> By issuing a single certificate with Subject Alternate Names to cover
multiple domains, LetsEncrypt can leak the IP of an origin server that is
behind a service such as Cloudflare. This increases the risk of DDOS attack.
I echo Hugo and Rich's position that ACME is the wrong place to solve this
