Re: [Acme] Wildcard certificate via http-01

"Matthew D. Hardeman" <mhardeman@ipifony.com> Thu, 25 January 2018 00:40 UTC

Return-Path: <mhardeman@ipifony.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A8512D859 for <acme@ietfa.amsl.com>; Wed, 24 Jan 2018 16:40:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd7ilumupCi0 for <acme@ietfa.amsl.com>; Wed, 24 Jan 2018 16:40:25 -0800 (PST)
Received: from mail.ipifony.com (mail.ipifony.com [199.71.210.39]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4028A12D85F for <acme@ietf.org>; Wed, 24 Jan 2018 16:40:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.ipifony.com (Postfix) with ESMTP id BA81DB4091A; Wed, 24 Jan 2018 18:40:24 -0600 (CST)
X-Virus-Scanned: amavisd-new at ipifony.com
Received: from mail.ipifony.com ([127.0.0.1]) by localhost (mail.ipifony.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q51hLCU32tC8; Wed, 24 Jan 2018 18:40:23 -0600 (CST)
Received: from mail.ipifony.com (mail.ipifony.com [199.71.210.39]) by mail.ipifony.com (Postfix) with ESMTP id C848BB40447; Wed, 24 Jan 2018 18:40:23 -0600 (CST)
From: "Matthew D. Hardeman" <mhardeman@ipifony.com>
MIME-Version: 1.0
Message-ID: <A0F872F3-0819-414D-A5E7-256533B85E3A@ipifony.com>
Date: Wed, 24 Jan 2018 18:40:23 -0600
To: Alan Doherty <ietf@alandoherty.net>
Cc: Hugo Leisink <hugo@leisink.net>, acme@ietf.org
X-Mailer-Connector: zimbrabackend 54.z-push-2
Content-Type: multipart/alternative; boundary="=_bdeb23ba0a20b4f8d97feda25bd23270"
X-Mailer: Zimbra 7.2.5_GA_2906
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/M0dW_jt6CqwimuDv6_opRfxNWlc>
Subject: Re: [Acme] Wildcard certificate via http-01
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2018 00:40:27 -0000

You make your own case for using a mechanism other than this, though.

Your described use case of your domain strongly suggests routine frequent changes to your dns zone.

Presumably you’re already using a dynamic zone.  Or probably should be.

Your path to wildcard certs is probably better via dns-01.

> On Jan 24, 2018, at 6:04 PM, Alan Doherty <ietf@alandoherty.net> wrote:
> 
> I would second this proposal
> but as for all my domains where we need wildcard certs do not have wildcards in dns
> 
> like I instruct users to pop from username.pop3a.example.org smtp to username.smtps.example.org
> or https api to api-key.api.example.com for other stuff
> 
> specifically so when username/api-key is deleted/revoked his dns fails and he stops bothering our servers (as he will inevitably never tell gmail or other webclient stop ;) 
> so rather than have huge san certs we'd prefer *.pop3a.example.org on our tls certs
> (we have a http listener for *.pop3a.example.org and *.smtps.example.org that redirects to our pop3 and smtp help page (that we could respond to acme challenges on easily)
> 
> that said I now see we could easily do
> 
> deleted.pop3a      A 127.0.0.1
> deleted.smtps      A 127.0.0.1
> *.pop3a            A our.rea.lip.add
> *.smtps            A our.rea.lip.add
> but then users could (thus would) setup random-typo.pop3a.example.org in their clients and we'd be none the wiser till we try and swat them years later as dead users ;)
> 
> but I guess much like DNS-01 we could add a temporary wildcard to dns for the time needed for the authentication to succeed then remove afterward (and during the period also see how many ex-users are still retrying ;) )
> 
> but dns-01 will likely still serve us better
> 
> but I still approve for those with actual wildcards in their actual zone files for whatever reason
> 
> but for those with wildcard in dns simply connecting to http://random.wildcarddomain.com/.well-known/acme-challenge/whatever
> once for ownership
> then dns lookup of random1.wildcarddomain.com random2.wildcarddomain.com random3.wildcarddomain.com
> to verify same ip(s) returned should prove the wildcard exists
> if ips differ only then should it be necessary to follow up with http gets (say its got dns loadbalancers or summit)
> http://random1-3.wildcarddomain.com/.well-known/acme-challenge/whatever
> 
> 
> At 21:42 24/01/2018  Wednesday, Hugo Leisink wrote:
>> Hi,
>> 
>> While implementing ACMEv2 for Let's Encrypt, I noticed that wildcard
>> certificates can only be obtained via dns-01. Because it's not possible
>> for me to do that automatically, I proposed them a way to do it via
>> http-01. After they said that 'it might work', they told me to contact
>> you about this.
>> 
>> My idea is that when a client requests a wildcard certificate
>> (*.domain.tld), the CA server offers a challenge and requests that
>> challenge via HTTP while using a random hostname (<long random
>> string>.domain.tld). Because only a webserver with a website configured
>> for *.domain.tld and with a properly configured DNS can respond to this
>> challenge, it's enough proof that the request for a wildcard certificate
>> is valid. Perhaps the CA server can do multiple requests with a new
>> randomly chosen hostname for more proof. After all, they will all end up
>> at the same website.
>> 
>> The discussion about this at the Let's Encrypt forum can be found here:
>> https://community.letsencrypt.org/t/wildcard-certificates-via-http-01/51223
>> 
>> I really like to hear your thoughts about this.
>> 
>> Kind regards,
>> Hugo Leisink
>> 
>> 
>> _______________________________________________
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
> 
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme