Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#2128 adding issuewild #1820

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

utkarshsethi
Copy link

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
Copy link
Author

#2089

@tituspijean
Copy link
Contributor

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants