All letsencrypt certificate registrations are being tracked by backing corps, and made public. See https://certificate.transparency.dev
As yunohost includes specific subdomains for apps and features like xmpp-upload… etc., maybe it is actually better for yunohost to consider switching, or allowing, to register wildcard domains?
At least this is what cloudron seems to have concluded (it’s in their docs).
I was thinking that just generating and using wildcard certificates, would not necessarily require to actually support adding wildcard domains to yunohost. Or am I reading that incorrectly?
A wildcard certificate for *.domain.tld may be applied and work for all individually configured, specific (classic yunohost) subdomain setups. It would make it unnecessary to generating a separate certs for each subdomain, or having certs that list multiple subdomains.
But would yunohost have to actually be configured to respond (serve content or redirect) on every possible *.domain.tld address?
Related issue on GitHub : https://github.com/YunoHost/issues/issues/1292
I guess we could use the DNS challenge to create LE certificates for domains excluding subdomains, but this will need some research because the script we use at this time will not support DNS challenge.
This could be a different thing from handling wildcard domains, and be usefull for user experience. When someone have a LE cert for the main domain, every subdomain will use the same cert.
On the other hand, wi still need to support HTTP Challenge bevabecause some registrar don’t have a DNS API…
From what is written here, it seems not necessary to have a DNS API.
Looks as if it is enough to manually configure a wildcard domain in the DNS.
Plesk for example gives you the option to add wildcard LE certificates.
You simple Copy&Paste the ACME Verification Code to your Domain records, wait some minutes, hit refresh and thats it.
I’m playing currently with my yunohost setup, and I have 9 (2x) subdomains…
The link you refer is about having a wildcard domain, not a wildcard certificate.
Let’s Encrypt require a DNS-01 challenge to obtain a wildcard certificate.
You could run a DNS-01 challenge without DNS API, but this will need you to manually edit the DNS at every certificate renewal.
According to this page, Cloudron uses DNS API provider to get a wildcard certificate.
Thanks, that one page you linked does explain it very well. I was indeed looking on the wrong page.
So I guess there could be direct DNS API support, which may be rather complex to implement.
Or, maybe just a script hook that notifies the admin, and may even let the admin automate the dns server update and contribute a script for the used DNS registrar?
@ploedman Do you maybe also happen to know how renewal works in Plesk?
The Plesk Documentation is a bit old.
https://lstu.lixl.nl/KnrD38Ru
It does not mention that the renewal is also done manually (if API is not supported). I didn’t use Plesk more than 80 Days, so I don’t know. But shouldn’t be a issues, to do it again for renewal, you get a e-mail from ACME before it expires.
Certbot (snap) with the third-party API plugin is pretty easy to setup, I’m running AdGuard Home on my Pi at home (static IP) with the inwx.de plugin, without issues.
Is it possible to configure Yunohost that way to use Certbot (snap) without conflicting with the built-in LE service?
How do you reach those subdomains? In case of my server (it is Internet-facing), I reach them via DNS, which is publicly available.
There are people and companies using DNS to find my server on the internet, in general that is why I put the information on DNS in the first place.
I am no fan of large corporations, nor of tracking behaviour of many parties nowadays, but I fail to see how a mechanism to enable certificate revokal is a problem.
This is quite ironic to post in a thread about tracking, using a URL shortener (of 30 characters), via a Google-DNS, without revealing where the link leads to!
I am no fan of large corporations, nor of tracking behaviour of many parties nowadays, but I fail to see how a mechanism to enable certificate revokal is a problem.
I am also reading this thread but am unsure of what is being talked about. What is the problem in plain language?
https://docs.cloudron.io/certificates/#certificate-transparency
From what I read, it’s only one case to set up a public website, say on a www. subdomain.
And it’s a different case if subdomains are not to be published, e.g. because they are only for temporary or own use like xmpp-upload for chat users, admin, webmail login, whatever.
Say it’s a separate subdomain that’s not getting published, only answered but not listed by your dns, and not linked. Firewalls can catch and block port scans and the logs are clean.
I must disagree here.
You will ever only make certificates for (sub)domains. Registering a certificate only makes sense if the domain is available in DNS. DNS is public, so you will never be in a position where any corporation behind letsencrypt can get hold of your secret domains because there are no secret domains that are in DNS
All domains having installed an ssl certificate are listed in the website of the certificate company (letsencrypt for example).
So registering blog.myyuno.nohost.me drive.myyuno.nohost.me pass.myyuno.nohost.me etc… Are all listed in the website of letsencrypt.
But when using wildcard, there will be only *.myyuno.nohost.me
This may “help” bad guys look for servers in this list. With ‘*.’ it will be harder for them.
I don’t know if using wildcard with subdomains pointing to different servers would be possible.
Ok but does it matter that much? It might help those using the *.nohost.me addresses, but for anybody with their own domain name, if they know *.blah.com exists, they know your IP address and can attack SSH or the LDAP login page.
Anyways, more security is better, so carry on guys 
What IP addresses would be known from *.domain.tld ?
DNS server has disabled zone transfers and is not returning a list when queried for “any”. So one could only guess for not publicly advertised subdomains, and could further only probe or portscan for services.
PS: Maybe check this out, when looking at the dns queries that yunohost is doing, the log will show (outgoing) probing for many external cryptic-string subdomains. (Identifying metadata from all incoming and outgoing emails to someone else’s network.) Are all of them known?