#2128 adding issuewild

[utkarshsethi]

The problem

Allow Let's encrypt wildcard subdomain certificates in CAA records #2128

Solution

@alexAubin @tituspijean Just add additional CAA resource records in /src/dns.py lines 141 and 251 (dev-branch) with the "issuewild" tag. It is the same record like the "issue" tag:

;; CAA Records
example.com.	3600	IN	CAA	0 issue     "letsencrypt.org"
example.com.	3600	IN	CAA	0 issuewild "letsencrypt.org"

After that change Let's Encrypt wildcard-certificates can be requested via the DNS-challenge.

YunoHost/issues#2128 (comment)

PR Status

...

How to test

...

[utkarshsethi]

#2089

[tituspijean]

In my opinion we should, before merging, have a setting to declare that all subdomains of a domain will be handled by that same YunoHost server (a fortiori and more technically correct, to declare that the subdomains certificates will be delivered by Let's Encrypt).

I see many use cases on the forum where users use the same main domain for multiple servers, not all running YunoHost.

[utkarshsethi]

An option between using a wildcard vs a normal certificate can be a solution.

Even if you're using wildcard cert, it is possible to use separate certificates for the main/subdomains separately.

CAA records further still allow having more than one CA, if set correctly. An example of this is also available at https://letsencrypt.org/docs/caa/#examples.

A simple CAA record which allows Let’s Encrypt to issue for “example.org” might look like this:
example.org CAA 0 issue "letsencrypt.org"
A more complex CAA record set might look like this:

example.org         CAA 0 issue "myca.org;validationmethods=dns-01"
example.org         CAA 0 issuewild "myca.org"
example.org         CAA 128 issue "others.com;accounturi=https://otherca.com/acct/123456"

In this example, MyCA can issue for “example.org”, but only using the DNS-01 validation method. It can also issue wildcard certificates, using any validation method. Finally, OtherCA can also issue certificates, but only if the request comes from account number 123456, and only if OtherCA recognizes and knows how to correctly handle the account restriction.

Even if you're using multiple servers for the same domain, the certificate will have to be picked up from a specific source.

For example, my own domain uses 2 servers. I host my mail services from a second server not using YunoHost, I still use LetsEncrypt there but I have to generate the certificates for mail.example.com and host them on that server separately from example.com and subdomain.example.com, which are on the server running YunoHost.

In my understanding, #2128 raised by @renne just allows the possibility to have issuewild certs in the DNS and doesn't seem to be a blocker to anything.

[alexAubin]

Don't know what to do with this considering that in its current state, YunoHost cannot request wildcard certs, and yet this means that every diagnosis for every yunohost instance in the wild will "complain" that this DNS record should be set ...

Maybe your point is that you want to be able to get a wildcard cert, but Yunohost suggestion doesn't stop you from manually adding this record and fetching the wildcard cert ...

[utkarshsethi]

I don't know what is supposed to happen here until YunoHost/issues#2089 or YunoHost/issues#1292 becomes a priority either.