[Guide] Wildcard certificates

Wildcard Certs

This is from my personal kb how I set up wildcard certs for some of my subdomains which should not show up in the certlog (https://crt.sh/).

I replaced my private domain with yunohost.org so be aware commands are hand edited!

To use wildcard certs I am going to use acme.sh. In this example I use yunohost.org as my base domain and want to use a wildcard cert for some-fancy-subdomain.yunohost.org subdomain.

Install acme.sh as root

Check the source before piping it into a shell!


wget -O -  https://get.acme.sh | sh -s email=my@example.com

This will install acme.sh and all needed stuff in /root/.acme.sh

Set up cert folders for yunohost

cd /etc/yunohost/certs/
ls -la

Find a valid folder with LE / ZeroSSL Certs in it an copy it to something meaningful for replacement (acme.sh script will change permissions of the newly generated cert debending on the certs it will find in the folder you deploy the certs to.
Hint: PLEASE read the acme.sh documentation for further infos!)

cp -r /etc/yunohost/certs/yunohost.org-history/[some date]/ /etc/yunohost/certs/wildcard.yunohost.org

Test acme.sh with dns challange

I am using hetzner as my dns provider so I can use the hetzner_api:

https://github.com/acmesh-official/acme.sh/wiki/dnsapi#74-use-hetzner-api

Please look in the wiki for the other DNS Apis.

INFO:
You can NOT issue a wildcard certs without DNS records

export HETZNER_Token="my token here"
# MAKE SURE THAT WILDCARD DOMAINS ARE IN single quotes
acme.sh --test --issue --dns dns_hetzner -d '*.yunohost.org' 

If test is running fine you can go on and issue the real cert otherwise try and error :wink:

Issue cert

# I am switching to letsencrypt
acme.sh --issue --dns dns_hetzner / 
-d '*.yunohost.org' /
--server letsencrypt --force

I sometimes need --dnssleep to avoid timeouts

Create nginx conf

create a file called wildcard.yunohost.org.conf in /etc/nginx/conf.d

# include as wildcard.yunohost.org
# override ssl_certificate
ssl_certificate /etc/yunohost/certs/wildcard.yunohost.org/crt.pem;
# override ssl_certificate_key
ssl_certificate_key /etc/yunohost/certs/wildcard.yunohost.org/key.pem;

Symlink this file into each folder needed

Edit: apperantly you have to comment out the self-signed cert otherwise nginx will present both certs and SSL Server Test (Powered by Qualys SSL Labs) is not happy about that

ln -s /etc/nginx/conf.d/wildcard.yunohost.org.conf /etc/nginx/conf.d/some-fancy-subdomain.yunohost.org.d/

Deploy cert

acme.sh --install-cert -/
d '*.yunohost.org' /
--key-file /etc/yunohost/certs/wildcard.yunohost.org/key.pem /
--fullchain-file /etc/yunohost/certs/wildcard.yunohost.org/crt.pem /
--reloadcmd "service nginx force-reload"

you can check with curl if the wildcard cert is working:

curl some-fancy-subdomain.yunohost.org

Maybe I find some time to write a simple bash script to automate the symlink part

Known limitations

For the wildcard cert to work you have to change some lines in the yunohost generated nginx configs (comment out the self signed cert) which means, that the diagnosis will warn you about these modifications. (If anybody knows how someone can apply the cert to nginx without modifications to the original conf file, please share!)

3 Likes

What’s the use case for this in YunoHost context where the certs are/should be/can be managed automatically?

1 Like

For me its all about certlog and discoverability. Each certificate you generate is forever writen in the certlog and you can watch your logs for that as well:

  1. create a subdomain without LE Cert → nobody is probing the subdomain for anything
  2. create a LE/ZeroSSL Cert and the probing begins.

You can have a look what the certlog knows about you if you go to crt.sh and query your domain (or any other :wink: )

A wildcard cert is a simple way to limit the open knowlegde about software running on your server.

2 Likes

And when the certificate arrives to expiration, will yunohost regenarate the certificate? Or will it create certificates for all the subdomains? Does the diagnosis complain about it?

Thank you Marc for sharing your knowledge with this nice tutorial, I really appreciate.
You could maybe add the tutorials tag?

acme.sh will auto generate and deploy the certs it generates via --issue, --install-cert or --deploy every 60 days if you installed acme.sh (which installs a cronjon) correctly.

Please read the acme.sh wiki for further infos

I have a bunch of subdomains on multiple domains in yunohost and I have the following setup:

  • LE Cert via yunohost for each *.domain.tld and www.domain.tdl
    yunohost will update these certs
  • Self-signed certs via yunohost and wildcard cert via acme.sh
    yunohost will update the self-signed cert (which is not used. I disabled the cert part in the nginx-conf) and acme.sh will update and deploy the wildcard

The diagnosis will OF COURSE complain about it. You have to disable/ overwrite/remove the original self-signed cert part in the config of ngix. If you know a better way, please feel free to help out!

2 Likes

I remember there was some discussion about this being implemented officially in YunoHost.

Nice job :+1:

Bumping to ask for native wildcard support.

@YunoHost

another usecae is random.domain.tld redirects to domain.tld but still gives a certificate error instead of just showing domain.tld.

Related: Support Lets Encrypt wildcard certificate · Issue #2089 · YunoHost/issues · GitHub and Support DNS-based challenge for Lets Encrypt · Issue #1292 · YunoHost/issues · GitHub

Related : Add a domain setting to redirect www.$domain to $domain · Issue #249 · YunoHost/issues · GitHub but i don’t think we want to have random.domain.tld redirecting to domain.tld by default, idk

1 Like

Its not about wanting to direct random.domain.tld to my server but typos happen.

Even to handle www.domain.tld and domain.tld I need to register both and install individual certificates on both.

as the CNAME sends it to the server but without having to register it just causes a NET::ERR_CERT_AUTHORITY_INVALID as I have the CAA record set to 0:issue:letsencrypt.org

In case of those typos it still leads to NET::ERR_CERT_AUTHORITY_INVALID and doesn’t actually redirect(on modern browsers). to say domain.tld. which I do see is a security point(more of an inconvenience than safety if you have a DNS record for it).

so while the A record of *.domain.tld redirects to the IP it still gets stuck.

There was of course the privacy point where, services like https://crt.sh/ can be used to get a good estimate of services hosted on the server in certain cases.