From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <t.lamprecht@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id 86E2C726C3
 for <pmg-devel@lists.proxmox.com>; Tue, 13 Apr 2021 06:56:07 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id 6ECDD25AA6
 for <pmg-devel@lists.proxmox.com>; Tue, 13 Apr 2021 06:55:37 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
 [212.186.127.180])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS id C281625A96
 for <pmg-devel@lists.proxmox.com>; Tue, 13 Apr 2021 06:55:35 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 89F4D4202D
 for <pmg-devel@lists.proxmox.com>; Tue, 13 Apr 2021 06:55:35 +0200 (CEST)
Message-ID: <e7364f10-8922-b995-3718-78e16966b190@proxmox.com>
Date: Tue, 13 Apr 2021 06:55:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101
 Thunderbird/88.0
Content-Language: en-US
To: Stoiko Ivanov <s.ivanov@proxmox.com>, pmg-devel@lists.proxmox.com
References: <20210412192833.21988-1-s.ivanov@proxmox.com>
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
In-Reply-To: <20210412192833.21988-1-s.ivanov@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL -0.042 Adjusted score from AWL reputation of From: address
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 NICE_REPLY_A           -0.001 Looks like a legit reply (A)
 RCVD_IN_DNSWL_MED        -2.3 Sender listed at https://www.dnswl.org/,
 medium trust
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
 http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
 information. [letsencrypt.org]
Subject: Re: [pmg-devel] [PATCH pmg-api/pmg-docs/proxmox-widget-toolkit v2
 0/1] allow wildcard DNS-names for ACME
X-BeenThere: pmg-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Mail Gateway development discussion
 <pmg-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pmg-devel>, 
 <mailto:pmg-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pmg-devel/>
List-Post: <mailto:pmg-devel@lists.proxmox.com>
List-Help: <mailto:pmg-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel>, 
 <mailto:pmg-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2021 04:56:07 -0000

On 12.04.21 21:28, Stoiko Ivanov wrote:
> v1->v2:
> * reaad up on the requirements and infered from [0], a few HOWTOs and the
> response from the LE staging directory that:
> ```
> Orders that contain both a base domain and its wildcard equivalent (...) are
> valid.
> ```
> means that only such orders are valid (hence the requirement for the base

I'm afraid, that's bogus.

> name in addition to the wildcard name
> * added a short stanza to pmg-docs describing the requirements
> * added a patch for pwt to allow '*.' as prefix for domains in ACMEDomains

actually read your linked article:
> To request a wildcard certificate simply send a wildcard DNS identifier in the newOrder request.

And from the actual RFC #8555
> Any identifier of type "dns" in a newOrder request MAY have a wildcard domain name as its value.

So, it's:

1. just wildcard '*.domain.tld', totally fine
2. if an order contains a wildcard and the base domain, it's seen as valid too,
   but definitively *not* a requirement..

2. stand in contrast to cases where a wildcard domain and a subdomain, which the
wildcard would already cover, are passed in an order - as that is bogus.

How do I know it works? Because I order wildcard certs with just the wildcard
domain since ACME/Let's Encrypt supports it ;-)

> [0] https://community.letsencrypt.org/t/acme-v2-production-environment-wildcards/55578