Question letsencrypt certificate for fourth level domain not served from subdomain

[johnrdorazio]

I have a domain example.com to which a letsencrypt wildcarded certificate is issued.

I also have a subdomain thirdlevel.example.com which would have worked theoretically without another certificate, since the main domain is wildcarded. But the subdomain has some fourth levels to designate languages: en.thirdlevel.example.com, it,thirdlevel.example.com, fr.thirdlevel.example.com etc. These fourth levels were not being recognized by the browser as being included in the domain's wildcarded certificate, so I explicitly issued a letsencrypt wildcarded certificate for the third level domain (thirdlevel.example.com and *.thirdlevel.example.com).

The strange thing is, that when I navigate directly to the third-level domain, the correct third level certificate is seen and used by the browser, but the fourth levels are associated with the main domain's certificate by the browser and not with the third level domain's certificate. Only if I navigate to the third level domain first, and then to a fourth level domain, do they pick up the wildcarded third-level certificate. If instead I try to navigate directly to a fourth level, the browser tries to associate it with the main domain certificate. Which is a problem, because I have activated HSTS stapling on all of my domains, and when the fourth level domain tries to pick up the main domain's wildcarded certificate Chrome blocks navigation saying the certificate is not valid.

Is there any way of making sure the third-level wildcarded certificate is always associated with the fourth-level domains?

If it helps any this is my setup:

DNS records (gandi.net):
example.com A record to ###.###.###.### IP address
thirdlevel.example.com A record to ###.###.###.### IP address (same as above)
* CNAME record to example.com
*.thirdlevel CNAME record to thirdlevel.example.com
_acme_challenge.example.com TXT record for letsencrypt DNS challenge
_acme_challenge.thirdlevel.example.com TXT record for letsencrypt DNS challenge

Apache/Nginx setup for thirdlevel.example.com:
Additional directives for http / https: ServerAlias *.thirdlevel.example.com

Are there any directives I can issue to make sure the wildcarded third level certificate is associated with all fourth level domains, and not the wildcarded base domain certificate, which apparently doesn't work for the fourth level domains?

 

[johnrdorazio]

I've tried a few things but nothing seems to fix this issue. I tried adding explicit CNAME records for each fourth level in my DNS records:

de.thirdlevel 1800 IN CNAME thirdlevel.example.com.
en.thirdlevel 1800 IN CNAME thirdlevel.example.com.
es.thirdlevel 1800 IN CNAME thirdlevel.example.com.
pt.thirdlevel 1800 IN CNAME thirdlevel.example.com.
it.thirdlevel 1800 IN CNAME thirdlevel.example.com.
fr.thirdlevel 1800 IN CNAME thirdlevel.example.com.

The certificate for the fourth levels is still served from the base domain.
If it were possible to manually add fourth level domains from the main domain's LetsEncrypt settings page the problem would be solved.
Is there any way of doing this manually, like editing an xml file somewhere?

 

[johnrdorazio]

Well I was able to manually issue a LetsEncrypt certificate using DNS challenge, by making use of the acme.sh client, which supports Gandi LiveDNS along with many many other DNS services with APIs. I issued a certificate for:

example.com
*.example.com
en.thirdlevel.example.com
it.thirdlevel.example.com
es.thirdlevel.example.com
fr.thirdlevel.example.com
de.thirdlevel.example.com
pt.thirdlevel.example.com

Now I have to understand how to automate the application of the resulting certificates to that domain from the command line. I tried copying the certificates over to `/opt/psa/var/modules/letsencrypt/etc/archive/example.com` with an incremental number and then updating the symlinks in `/opt/psa/var/modules/letsencrypt/etc/live/example.com` to point at these latest certificates, but even after restarting apache and nginx the new certificates were not being served by the domain. I thought it would be enough for the 'live' certificate to be updated, but I guess not.

I had to manually create the certificate for the domain, pasting in the contents of the certificates returned from the DNS acme challenge by the acme.sh client. Only then did the domain start serving the certificate.

I see there is a `plesk bin certificate` utility that might be able to do the job, but it seems to want to create certificates for an IP address rather than a domain?

Any suggestions on how I should go about doing this?

 

[johnrdorazio]

I believe I'm making some progress seeing this thread (344076) .

 

[learning_curve]

....I had to manually create the certificate for the domain, pasting in the contents of the certificates returned from the DNS acme challenge by the acme.sh client. Only then did the domain start serving the certificate....

Not the same requirement as yours @johnrdorazio or even close really (as currently, we don't use any sub-sub-domains like you) but, as well as using the Plesk Let's Encrypt & SSL It Extensions for normal certificates & renewals, we have always used the acme.sh tools to provide a multi-domain / *wildcard (for all of the domains included here) Let's Encrypt certificate (effectively a SAN certificate) for some time now. One of the sub-domains that's covered, we use exclusively for hosting Plesk & rDNS server ID etc.

Once the acme.sh process is complete, we create the certificate within the Plesk Panel here: https://**your-plesk-hosting-domain:8443/admin/ssl-certificate/list You can use the copy/paste method you've described above or, just upload the certificate files. This works perfectly / allocates the certificate perfectly every time.

Just guessing, but are you NOT wanting to do this because it's a "repeat 5 times process" in your case at present and you're looking for something more automated? If so, a suggestion (which we've not tried but) could you not combine all of those sub-sub-domains into just one multi-domain / *wildcard (if needed for your sub-sub-domains! ) Let's Encrypt certificate, in a very similar way to the way that we do? That would reduce the amount of manual work needed from you.

FWIW You can run a quick check afterwards using an SQL query & CLI if needed e.g. Access Plesk DB via SSH then against the MariaDB [psa]> prompt, run

select d.name as dom, c.name as cert, c.id as cert_id, r.rep_id from certificates c, domains d, Repository r where d.cert_rep_id = r.rep_id and r.component_id=c.id;

which gives the domain, the certificate, the certificate id & the repository id.

 

[johnrdorazio]

Just guessing, but are you NOT wanting to do this because it's a "repeat 5 times process" in your case at present and you're looking for something more automated? If so, a suggestion (which we've not tried but) could you not combine all of those sub-sub-domains into just one multi-domain / *wildcard (if needed for your sub-sub-domains! ) Let's Encrypt certificate, in a very similar way to the way that we do? That would reduce the amount of manual work needed from you.

Yes I have already done this. I am currently making a single request through the acme client which includes two wildcards:
example.com
*.example.com
*.thirdlevel.example.com

This is producing a single certificate that covers all subdomains and fourth levels. However having to manually paste the certificate into the Plesk interface every two months, I think can be avoided with some simple automation (bash script + cron job).

I'm looking into the

plesk bin certificate

tools to do this, I'm still figuring them out. I wish there were a way of saving an exact sequence of commands as issued by the plesk interface so I could reproduce exactly on the command line and automate it with a cron job.

 

[learning_curve]

...I am currently making a single request through the acme client which includes two wildcards:
example.com
*.example.com
*.thirdlevel.example.com

This is producing a single certificate that covers all subdomains and fourth levels. However having to manually paste the certificate into the Plesk interface every two months, I think can be avoided with some simple automation (bash script + cron job)

Ahhhhh yes, saw that above in your earlier post. Thought there was a number of different domains too (which could be included in the same certificate as well as all the wildcards). My misunderstanding there, not yours.

I'm looking into the plesk bin certificate tools to do this, I'm still figuring them out. I wish there were a way of saving an exact sequence of commands as issued by the plesk interface so I could reproduce exactly on the command line and automate it with a cron job

If /when you do, posting it in this thread would be much appreciated. We may also be able to use adapt it and use it

Have you not thought about posting a Plesk support ticket? That would save you a lot of searching time. They are very helpful & responsive.

 

[johnrdorazio]

So far what I have is a cron job that runs this:

/usr/local/bin/acme.sh/acme.sh --issue --dns dns_gandi_livedns -d mydomain.com -d *.mydomain.com -d *.subdomain.mydomain.com

plesk bin certificate --update "LetsEncrypt wildcard_mydomain.com" -domain mydomain.com -key-file /root/.acme.sh/mydomain.com/mydomain.com.key -cert-file /root/.acme.sh/mydomain.com.cer -cacert-file /root/.acme.sh/mydomain.com/fullchain.cer -csr-file /root/.acme.sh/mydomain.com/mydomain.com.csr

plesk bin certificate --update "LetsEncrypt wildcard_mydomain.com" -domain subdomain.mydomain.com -key-file /root/.acme.sh/mydomain.com/mydomain.com.key -cert-file /root/.acme.sh/mydomain.com.cer -cacert-file /root/.acme.sh/mydomain.com/fullchain.cer -csr-file /root/.acme.sh/mydomain.com/mydomain.com.csr

plesk bin subscription_settings --update mydomain.com -mail_certificate 'Lets Encrypt wildcard_mydomain.com'

I do this for each of the domains on my plesk instance (though they don't all have fourth level domains like in the above example).
However I am now seeing that on one of my domains, the new certificate was not picked up by the 'webmail' subdomain for some reason.
I'm trying to investigate further.