SOLVED [CPANEL-31544] How to install a Wildcard SSL Certificate using the free Let's Encrypt provider plugin

[sneader]

Since v84, there is apparently an option to have a Wildcard SSL Certificate installed, if you are using the free Let's Encrypt plugin in WHM. However, I cannot seem to find any documentation on how, exactly, to go about this.

1. I'm assuming that the cPanel user needs to use the Zone Editor to create a wildcard A record , *.example.com, that points to their IP on the server? When the user does this, it does NOT show up under TLS/SSL Status, so they cannot "include" or "exclude" it.
2. Does the cPanel user need to delete all other subdomains from the Zone Editor? AND/OR
3. Does the cPanel user need to Exclude all the other subdomains from SSL/TLS Status?
4. The docs say that the wildcard certificate cannot cover the naked domain, example.com, so how do you get both the naked domain, and all the wildcard subdomains, covered?

Or maybe I can ask another way... if the cPanel user has an existing SSL certificate today, installed by cPanel's Let's Encrypt plugin, covering example.com, www.example.com, webmail.example.com, webdisk.example.com, etc., and they would like to switch to using a wildcard SSL certificate (perhaps for a WordPress Multisite setup using subdomains for each site)... What is the process to accomplish this? If I've missed the docs on this, a link would be appreciated.

Thank you!

 

[cPanelLauren]

Hi @sneader

This is a great question, the explanation is pretty simple but complicated at the same time:

Understanding the purpose of the wildcard subdomain feature Let's Encrypt supports here is paramount. This is solely to cover domains that don't exist in the Apache configuration i.e., if you allow users to create subdomains on the fly, or potentially link to subdomains that don't exist but you still want to display a page.

• If you create a wildcard subdomain, and it is secured by autossl, *.domain.tld will secure any subdomain that does not exist or does not have a certificate yet.
  • In the event the domain does not have a certificate yet, it will display the documentroot of the wildcard subdomain.

• When you create a subdomain on the server, it's provided an SSL automatically, which uses the subdomain name in the SAN, the wildcard cert cannot cover it.

• This is detailed here: The Let's Encrypt Plugin | cPanel & WHM Documentation though it's a bit different in concept than when you traditionally think of wildcard certificates.
  • An important portion of that document to note is:

This plugin does not currently secure non-wildcard domains via wildcard certificate. For example, it cannot secure the foo.example.com and bar.example.com subdomains with a *.example.com wildcard.

I was initially going to address your questions inline but I think, they may be irrelevant now, ultimately if you want what you might call a standard wildcard certificate which covers domain.com as well as existing and non-existing subdomains with *.domain.com you'd need to use methods used prior to implement this at this time.

 

[sneader]

Thanks, Lauren! With your clues, I believe I have this sorted out now:

• Pre-requisite is that the cPanel server in question must be using the Let's Encrypt™ SSL Provider (and not cPanel/Sectigo Provider).
• Pre-requisite is that the cPanel server must provide DNS services for the domain in question. No using CloudFlare or Registrar's DNS servers, etc. This is because Let's Encrypt requires validation via DNS. The validation DNS record is created in the local DNS Zone.
• The first step for the cPanel user is to create a "wildcard" subdomain, by going to Subdomains in cPanel, and putting an asterisk ( * ) into the Subdomain field and setting the Document Root as appropriate (note bug below).
• After creating the Subdomain, cPanel will automatically create the wildcard ( * ) DNS A Record, and then AutoSSL will be launched automatically, which will create the validation DNS record, and then IF Let's Encrypt™ is able to validate the DNS record, a new Wildcard SSL Certificate will be generated and installed.
• The cPanel user does NOT need to remove the existing SSL certificate or any of the existing subdomains, as they will still be covered by the existing, separate SSL certificate(s). However, the user COULD choose to delete those subdomains, if they point to the same document root as the new Wildcard SSL certificate (right?)

I'd appreciate your input on these points, especially the last one.

BUG WITH SUBDOMAINS FEATURE: When you put "anything" in the subdomain field, it automatically populates the Document Root as /public_html/anything. If you backspace and remove 'anything' so that the document root is just /public_html/ and click "create" to create the subdomain, you will see it ignored your Doc Root change, and it creates the subdomain with a doc root of /public_html/anything. You must go back to Subdomains, and click the pencil icon to edit the Doc Root to be /public_html/. If you agree this is a bug, and want me to file it with a ticket, let me know.

- Scott

 

[cPanelLauren]

• Pre-requisite is that the cPanel server in question must be using the Let's Encrypt™ SSL Provider (and not cPanel/Sectigo Provider).
• Pre-requisite is that the cPanel server must provide DNS services for the domain in question. No using CloudFlare or Registrar's DNS servers, etc. This is because Let's Encrypt requires validation via DNS. The validation DNS record is created in the local DNS Zone.
• The first step for the cPanel user is to create a "wildcard" subdomain, by going to Subdomains in cPanel, and putting an asterisk ( * ) into the Subdomain field and setting the Document Root as appropriate (note bug below).
• After creating the Subdomain, cPanel will automatically create the wildcard ( * ) DNS A Record, and then AutoSSL will be launched automatically, which will create the validation DNS record, and then IF Let's Encrypt™ is able to validate the DNS record, a new Wildcard SSL Certificate will be generated and installed.
• The cPanel user does NOT need to remove the existing SSL certificate or any of the existing subdomains, as they will still be covered by the existing, separate SSL certificate(s). However, the user COULD choose to delete those subdomains, if they point to the same document root as the new Wildcard SSL certificate (right?)

Exactly! On all points.

BUG WITH SUBDOMAINS FEATURE: When you put "anything" in the subdomain field, it automatically populates the Document Root as /public_html/anything. If you backspace and remove 'anything' so that the document root is just /public_html/ and click "create" to create the subdomain, you will see it ignored your Doc Root change, and it creates the subdomain with a doc root of /public_html/anything. You must go back to Subdomains, and click the pencil icon to edit the Doc Root to be /public_html/. If you agree this is a bug, and want me to file it with a ticket, let me know.

Which version of cPanel & WHM are you running? I have a server on edge and when I attempt to leave the document root blank for a subdomain I get "That directory is reserved for use by the system." Which I would expect because it can't make the document root for the domain /home/$user without a separate folder like /home/$user/subdomain. It should give you a warning though, and not allow you to proceed with creation and if that is not what's occurring, It does sound like an issue and if I can replicate it, I'll go ahead and open a case for this, no need to open a ticket.

 

[sneader]

This is on v86.0.3. Note that we have "Restrict document roots to public_html" to the default of "on" in Tweak Settings, so in our environment, it would not be possible to set the doc root to just /, it is forced to /public_html/, so I am not getting that error, or any error at all. It just ignores the user when they remove the auto-created subdirectory. I'm curious what your setting is in Tweak Settings. Suppose I could/should have started a different thread for this topic.

 

[cPanelLauren]

This is on v86.0.3. Note that we have "Restrict document roots to public_html" to the default of "on" in Tweak Settings, so in our environment, it would not be possible to set the doc root to just /, it is forced to /public_html/, so I am not getting that error, or any error at all. It just ignores the user when they remove the auto-created subdirectory. I'm curious what your setting is in Tweak Settings. Suppose I could/should have started a different thread for this topic.

I have restrict document roots to public_html turned off, in fact, I even toggled it at first to make sure it was being properly recognized in /var/cpanel/cpanel.config. I'm also running 86.0.3 - I'll attempt this again with it restricted.

 

[cPanelLauren]

Updating your system to reflect any changes...
Updating “Restrict document roots to public_html” from “Off” to “On”.
“Restrict document roots to public_html” was updated.

And sure enough after removing the documentroot from the input box I was able to successfully create the domain, though it reassigned the documentroot

Success: “docroot.mydomain.tld” has been created.

docroot.mydomain.tld

/public_html/docroot

 

[cPanelLauren]

I'm currently opening a case for this @sneader but I did want to let you know that this issue is *not* present when creating a domain at cPanel>>Domains>>Domains -> Create an New Domain

Success: You have successfully created the new “scary.skeleton.tld” domain with the document root of “/home/skeletonuser/public_html”.

 

[sneader]

Thanks Lauren. I guess I'm old school and used to using Addon Domains, Alias/Parked Domains, and Sub Domains. I know that cPanel would like me to use the new Domains feature, instead. And I know I will be forced to, eventually.

- Scott

 

[cPanelLauren]

Hi @sneader

I guess I'm old school and used to using Addon Domains, Alias/Parked Domains, and Sub Domains.

That's completely fine, in my opinion, they should function the same.

I got the case open for you CPANEL-31544 - Unable to use public_html as document root by default for subdomains when "Restrict Document Root to public_html" is enabled

I'll update here when there is more information on the case

 

[cPanelLauren]

Hello,



This is just an update to let you know that this issue is marked as resolved in v88 of cPanel & WHM and can be referenced in our changelogs here: 88 Change Log | cPanel & WHM Documentation