Re: [Acme] Proposed changes to TLS-SNI, autorenewal removal

Andrew Ayer <> Fri, 22 January 2016 19:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2AE011B2C76 for <>; Fri, 22 Jan 2016 11:18:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ngqQcPsnKdxP for <>; Fri, 22 Jan 2016 11:18:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 228C01B2C60 for <>; Fri, 22 Jan 2016 11:18:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=alcazar2; t=1453490327; bh=Jg7baLJXijItcyDHCw7hG9uxup0tPfhWPCIMW3xCEQY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=zjqv2aXklr/prRbgZIK+dq1Zb8c2U20DRZZsCTf08SC6Rc+PWWmNsrSGbSSlJFp4x bhd9dfId0UIVMXfbDZcIDVi7y1EBivZywRr2GVvxv3w8NuN9eosJ0kmX4LGVkABjcQ AtkHuP38U7fGnYs+8OS4hU6gJUGESDhOmQSm/X9UE4ZiTrD1NGpBNVQ7lzP1OxeppQ eXXqUGxoHILP9DXw/lr8FwnuLW4ci+fRdl15/wjnSl6SJ2zsGMKdkGcQx8kevsyb6V 6uskIH9DvIOB4TrEfcxyc4ogS994LQVmvWpwPnKSYQghMC5ELvFJbP/l8rhqs8+laW QpNtTtBhkUfDg==
Date: Fri, 22 Jan 2016 11:18:46 -0800
From: Andrew Ayer <>
To: Hugo Landau <>
Message-Id: <>
In-Reply-To: <20160122185442.GA27811@andover>
References: <20160122161306.GA19607@andover> <> <20160122185442.GA27811@andover>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Acme] Proposed changes to TLS-SNI, autorenewal removal
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Jan 2016 19:18:49 -0000

On Fri, 22 Jan 2016 18:54:43 +0000
Hugo Landau <> wrote:

> Certificates should probably contain SAN A. If they don't, this is
> liable to confuse TLS implementations and supporting infrastructure,
> which doesn't expect that an SNI request for x should result in a
> certificate not listing x.

Agreed, but that doesn't mean the ACME server has to check for such a
SAN.  What the client has to do and what the server has to do are
separate things, and the server should only do what's necessary to
ensure the security of the challenge.  Superfluous checks obscure the
security-critical checks, which makes the challenge harder to reason
about, and makes it harder to audit server implementations.

So I say keep the client-side part of the spec the same, but change
item three of the server-side part to say:

"Verify that the certificate contains a subjectAltName extension
containing a dNSName entry of SAN B.  The comparison MUST be
insensitive to case and ordering of names."

-- Andrew