From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 92F03230C7 for ; Mon, 15 Jan 2024 18:40:12 +0100 (CET) Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Mon Jan 15 12:38:28 -0500 2024 Received: from mimir.eigenstate.org (localhost [127.0.0.1]) by mimir.eigenstate.org (OpenSMTPD) with ESMTP id 97c660e8; Mon, 15 Jan 2024 09:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=eigenstate.org; h= message-id:to:subject:date:from:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=R2eyq8+3PG21 j+/X2VR9cpfbxdM=; b=DyxZD356tvPVjulcC0ExTkaCdo0KZ4Wsm+TDfJYTTZrw QoNKUJE0MJ1w9Cyhg+PbrYQTk3Ps1hurq/VP236oEreWo/XFxWxqYnXqWpQpNAwB vLRT2PxZgBGyVlk156iCmDCfskDYSODKn34+8QJmEj3eo4EZz+k9lF1KNTKhGPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eigenstate.org; h=message-id :to:subject:date:from:in-reply-to:mime-version:content-type :content-transfer-encoding; q=dns; s=mail; b=GiNatA9NiYwSfUFZNII 6DtdgTray6Ax0EnzgfsxG20eqef2N+povXZzp6/RmU6opWT2uy6OeF+p2wHueDWE 8nRyf4e6WUW0iYcY2GCMgi5Iuir0AEv1hLTqX4UI1ojMCng1068eCi6Om7ca4Ita V6sxF4hTOovchFMo7X+BTmEU= Received: from abbatoir (pool-108-6-24-2.nycmny.fios.verizon.net [108.6.24.2]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id b69b0c8b (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO); Mon, 15 Jan 2024 09:38:27 -0800 (PST) Message-ID: To: 9front@9front.org, driusan@driusan.net, ori@eigenstate.org Date: Mon, 15 Jan 2024 12:38:25 -0500 From: ori@eigenstate.org In-Reply-To: <2CEDDEA2213DC4D744EAF757A28E45EC@driusan.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: webscale abstract NoSQL core NoSQL rails Subject: Re: [9front] wildcard in auth/acmed Reply-To: 9front@9front.org Precedence: bulk Quoth Dave MacFarlane : > It's not a question of what challenge we request to use, > it's a question of what challenges Let's Encrypt sends > back to our request when we submit the csr. It doesn't always > match what we requested. > > It will always include a dns challenge for a wildcard > certificate, even if we request an http challenge. In the case > where I requested a wildcard and the non-subdomain certificate, > it was sending back a dns challenge for the wildcard > and an http challenge for the domain root, even if I submitted > the signing request with auth/acmed -t dns. > > The hybrid means "I don't know what the signer is going to request, > so figure it out when I get the challenge." is there a reason to keep the '-t' flag if we add logic to just figure it out? Maybe we split up the output location flags, and have one per type, and figure it out from that?