WP Toolkit shows missing Let's Encrypt on Addon Domain
I wonder if that is just a misinformation in WP Toolkit, a bug or something else
Usually I have one WordPress install per cPanel account.
Sometimes though I have additional addon domain on a single cPanel account. That means I see several WordPress instances in WP Toolkit within this account.
It shows me a warning sign at SSL/TLS - Let's Encrypt in WP Toolkit. It's like the SSL certificate does not exist.
From what I know the SSL certificate are always signed for the main account, but the addon domain can be a different domain or a subdomain.
What does it mean?
Is this only cosmetics or is this an issue?
I think every addon domain actually has a respective subdomain of the main domain, and I can imagine that this is somewhat connected.
Please ignore the old PHP version, it's also for some reason shown wrong in WP Toolkit. I actually run PHP 8.2 it just does not show here
-
Hey there! I think the easiest answer to this would be "does the SSL work on the site?" If that answer is "yes" then there is an issue with WP Toolkit we need to examine.
If that is the case, could you submit a ticket to our team so we can take a look at this?
0 -
Yes it does work. I need to check out if I can do that, I don't have a licence, my hosting provider has the license.
My theory is as a beginner: The SSL certiciate is issues ot the maindomain.com of the cpanel account. When you create an addon domain (not sure if we still call it addon domain these days) within a cPanel account then that's a different domain, and this domain gets for some cpanel internal structure a subdomain of the maindomain e.g. myaddondomain.maindomain.comIn WP Toolkit it manages the domain myaddondomain.com and the SSL certificate is not for myaddondomain.com but for maindomain.com - maybe as wildcard so it could include myaddondomain.maindomain.com but not myaddondomain.com
The result → it does work in real life but it shows broken in WP Toolkit
I have no idea if that could be right, I am just guessing here
0 -
That sounds like a good guess to me, but I don't have other reports of that happening at this point. If the host could make a ticket for you, that works for me as well.
0 -
Oh boy .. the host .. yes I'll try to explain it to them
0 -
But I think it must be very easy to reproduce in the end. I can imagine that everyone is actually getting similar results, and if not, then I know it's the host that does something wrong
0 -
I was able to easily reproduce the issue. If you hover over the yield symbol you'll see some additional details on what it is warning about. So it isn't saying the SSL is bad, but that the https access could be better implemented.
0 -
Now that I read it, I maybe have seen this already in the past. And the HTTPS redirect can only be applied on the main domain and not on the addon domains, as those only inherit the redirect status from the main domain
I just checked also - the main domain shows the green lock, the addon domains show the orange warning shield at SSL/TLS
Interpretation: SSL/TLS is in place but redirect from HTTP to HTTPS is turned off, which is true, because the redirect feature doesn't exist for addon domains but only for the main domain. and even though the addon domain is inheriting it from the main domain, it shows it this way - technically it could be seen as a not fully correct but also not fully false information
0 -
If you click the blue gear wheel to the top right of the Domains section, that will let you show the associated subdomain and you should be able to toggle the redirection there.
0 -
That shows those technical subdomains that are necessary to implement/configure the addon domain, but the redirection can't be toggled. But that could be also because of a configuration of the host.
Maybe if you got to it, you can see what you see here:
Auto SSL not active or SSL certificate not valid
0 -
Ah, that does seem to be a limitation of the host, possibly. If there is no SSL in place on the account, you can't toggle the SSL redirection as that just wouldn't work.
0 -
that sounds like one level higher to what I have access to with a reseller account
Usually the AutoSSL on the domains in cPanel I can add works. My main reseller account also has SSL active (from AutoSSL). It's difficult to imagine what is one level above as I don't know that world
If I know what I might to suggest or ask my host, I can do that (after some break as they are already quite annoyed by me)
0 -
I would just ask them why the AutoSSL isn't being applied to the addon domain. You could also check this in cPanel >> SSL/TLS Status if you have that area available to you.
0 -
cPanel >> SSL/TLS Status says:
An error occurred the last time AutoSSL ran, on April 15, 2024:
DNS DCV: No local authority: “addondomain.maindomain.com”; HTTP DCV: “addondomain.maindomain.com” does not resolve to any IP addresses on the internet.
And it makes sense, because addondomain.maindomain.com does not exist on the nameserver. I could try tomorrow to add it and see what AutoSSL is doing, but it just feels wrong as this is only something like a technical helper subdomain
0 -
I tested it right away:
Interesting result, when I add addondomain.maindomain.com to the nameserver, AutoSSL works for it as it can resolve the domain. But in WP Toolkit nothing changes, it stays exactly like shown in the very first screenshot
0 -
I wouldn't expect just adding the SSL to change anything related to WP Toolkit, but I would expect you to be able to toggle the HTTPS redirect option now, which should change things in WP Toolkit.
0 -
Yes you are right! That made the difference now.
Does this mean, technically all works as expected? You can question all of this in many ways, but I wonder in the case of actual website projects as addon domains, how important it would be to set it all up this way (starting by adding the "technical helper domain" to the DNS).
I am not sure in the end if
a) doesn't matter in real life
b) the hosting provider has a config and could do somethign about it
c) if it's a real website, it's essential do set it up the way as described in this discussion
0 -
From what I am seeing here this is all working as expected. If you have a "real" website it's best to go with option C to ensure users always reach the secured version of the page.
0 -
Thanks for going over all this together! It's nice to see how things in the end fall into place, but it's also crazy how complicated cPanel is under the hood (and that can probably not be changed easily, as usual with systems that exist for ages)
0 -
You're very welcome!
0
Please sign in to leave a comment.
Comments
19 comments