Let's encrypt works for the main domain, but not for any sub-domains (wildcard)

[Aspegic]

The problem:
When a browser requests the certificate for the main domain colorbase.com, it returns the correct Let's encrypt certificate.
But if the browser requests the certificate for any subdomain, instead of the Let's encrypt certificate, DirectAdmin returns its own default self-signed certificate.

This stopped working about a week ago, it used to work fine for over 2 years. I have no idea what changed.
I verified that Let's Encrypt is installed and working correctly.
letsencrypt=1, dns_ttl=1, mail_sni=1 and secure_access_group=access are all present in Directadmin.conf
I can execute a new certificate request and Let's Encrypt will return a new certificate as expected. Yes, I made sure that the "Wildcard" checkbox was checked. That is also confirmed on the SSL Certificates page in DirectAdmin, that the certificate is valid for both the main domain as well as for wildcard domains "*".

I think the problem is not with Let's Encrypt, but I am not 100% sure. It seems more like a DirectAdmin/Apache/Nginx problem.
I do not know why DirectAdmin returns its own default self-signed certificate for all sub-domains, instead of the Let's Encrypt one. That's what I can't figure out.

Does anyone have an idea what could be wrong?

PS. I discovered that the www subdomain does return the correct Let's Encrypt certificate. But that's the only subdomain name that seems to be working correctly.

 

[Richard G]

So which browser is having the issue?
Because you have a massive amount of subdomain SSL certificates valid (end time) between around june 11th and august 24th.
The new wildcard certificates requested today are all until august. There are also wildcards valid until august 2nd. So you might have requested more than needed.

But when I visit any of the subdomains the issue is that you have an automatic redirect working. That might mess up things for you.
domain -> working fine with https
www -> redirects to main domain without www
id -> redirects to main domain without www
app -> causes a re-initialisation error (check your logs)
gitlab -> is working fine with https
procure -> is working fine with https

For this last one, there is no seperate certificate anymore, this one had a validation of march this year, so must be using the valid wildcard now.

So I don't know which issue you think you are having, but as you can see, 2 are redirect issues but do work with https.
One needs investigation in your logs, doesn't seem a LE issue.
And the rest is working fine.

Test shows www is not the only subdomain working, almost all are working, except the app one.

 

[Aspegic]

Hello Richard, thanks for replying!

id, app, gitlab and procure are 4 exceptions. They work because they are actually extisting dns A records pointing to different servers.

However, besides those 4 subdomains, colorbase.com itself uses a list of redirects (via a wordpress plugin) that all basically do the same thing. They redirect to a specific wordpress page. For example, yupo.colorbase.com should redirect to colorbase.com/yupo
there are about 20 of those redirects, all handled by that wordpress plugin.
But regardless of that, any colorbase.com subdomain should return a valid certificate, because of the wildcard certificate, even if it isn't used. So even gusgyusgygdogoigdoi.colorbase.com should return a valid certificate.

If you do a certificate check on yupo.colorbase.com it should return a valid letsencrypt certificate (because of the wildcard certificate), but instead it returns directadmin's own self-signed default certificate. That's the problem I am having, as you can see here:

SSL Checker

Use our fast SSL Checker will help you troubleshoot common SSL Certificate installation problems on your server including verifying that the correct certificate is installed, valid, and properly trusted.

www.sslshopper.com

PS. This is independent of the browser. Chrome, Firefox, Safari, Edge all produce the same result.

 

[Richard G]

So even gusgyusgygdogoigdoi.colorbase.com should return a valid certificate.

Yes only if it does exist as far as I'm aware. But I must say I only used wildcard with existing records, not with redirects to pages.

For example, yupo.colorbase.com should redirect to colorbase.com/yupo

But then that is a page, not a real subdomain. But did you create the yupo.colorbase.com subdomain? Or wasn't that necessary?

If this was not required before, then I don't know.

However I am aware that SSL can have odd issues if there is no valid FQDN hostname present. And if I look to the PTR/rDNS record, then it's pointing to your domain name, not to an FQDN hostname. While your hostname is mail.colorbase.com which is also not advisable and I've seen odd issues too when people used kind of reserved names (like mail, www, ftp) in the hostname.
Issues which shouldn't occur, but were gone with the wind after changing to a decent fqdn hostname and rdns/ptr.

If you say it always worked like this, and I believe you, but at least the rDNS/PTR record is wrong.
And now we have the issue that SSLlabs also sees the mail as common name. And mail is also a record in your domain name as well as it's your hostname.

I can't guarantee, but I would suggest to first fix your hostname, change it to something else (not something which is present in a default domain name, so use for example server.colorbase.com or something else), create a seperate record for it and update the according records for it including the rDNs/PTR record.

Ofcourse if you don't want to make changes and feel it should just keep working as before, best send in a ticket for this issue. Because I don't know if this has something to do with some LE change or something within newer DA binaries or something else happened.