AutoSSL fails for addon domains when valid wildcard cert is installed
If example.tld is the cPanel account primary domain
and if there is a valid certificate installed that covers *.example.tld
then when a new addon domain anyvalue.tld is created, using anyvalue.example.tld
the feature to 'automatically install the best certificate...' installs the certificate containing *.example.tld for the anyvalue.example.tld vhost
and then, when AutoSSL runs it reports that other names at the anyvalue.example.tld vhost (eg. anyvalue.tld www.anyvalue.tld and mail.anyvalue.tld ).
and fwiw, the wildcard certificates I am using are generated and deployed using acme.sh via UAPI github.com/Neilpang/acme.sh/wiki/Simple-guide-to-add-TLS-cert-to-cpanel I use my server to host an application that requires using wildcard subdomains with valid certificates in order to operate effectively. I don't need, or even want, AutoSSL to get and install the relatively few certificates containing wildcard names that I may need. (though, when its an option, I'll try it) I would strongly prefer to rely upon AutoSSL to manage the relatively larger number of certificates for addon domains (and their renewals). Currently, the host for my fully managed server (LiquidWeb) is doing their internal process to review the issue. I believe that they have been able to replicate it but are not yet prepared to file a ticket. LW said they did not replicate independently but are going to submit a ticket anyways noting the circumstance for the report and linking to this thread. The only workable solution I have verified is to install my application at a subdomain, like apps.example.tld and then use *.apps.example.tld in operation. If I use my workaround, then I either leave *.example.tld with no installed certificate, or remove *.example.tld entirely. These options are less than great. I also create addondomains using pattern like: anyvalue.tld --> anyvalue.additionalvalue.example.tld and would be cool if this works also even if there is a valid cert for *.additionalvalue.example.tld [edit: when I have used this approach in past I was not using AutoSSL for the addons, see ps. below - also, may as well mention, I often do this via Api2] Though I do understand the current install logic, not totally sure if this is currently expected - or intended - behavior for AutoSSL? Here is a Q: I have been testing with LetsEncrypt wildcard certs via acme.sh rather than paid certificates... What would happen if I purchased and installed a valid wildcard certificate through the cPanel SSL/TLS Wizard's basic interface: is there different logic involved in certificate installation and precedence that I'm not aware of, or would the same logic be used and the same outcome expected? (my expected outcome being that AutoSSL would not effectively function for addon domains without intervention or workaround bcs of logic in 'install best available certificate' feature) Seems like there should be a way around this. Perhaps an option to not use wildcard certificates when system is selecting 'best available certificate' to install for new addon domains when AutoSSL is active would do the trick? I would really love to use AutoSSL to automatically secure addondomains upon addon creation while also retaining ability to have valid wildcard certificates installed. Please advise :) Cheers, Max ps. ...and then I realized that, esp via Api2, perhaps I had the pieces for a better workaround: just create the addon domains that I want AutoSSL to cover using second level subdomains eg. anyvalue.tld as addon domain at example.tld like anyvalue.tld --> anyvalue.additionalvalue.example.tld bcs then the cert with *.example.tld would not be a valid match (caveat: no available certificate can contain name *.addionalvalue.example.tld or it will be installed upon addon creation as 'best available') (?: in this model is it just a matter of preference/use-case that aditionalvalue.example.tld is a subdomain with a vhost versus a serveralias of example.tld vhost - also, any reason other than cert size for an individual certificate vs included in some other certificate?) [edit: drrp, if second lvl subdomain workaround works, then I'm thinking to do a wildcard sudomain with an individual cert, other first lvl subdomains will have own vhosts and certs - yeah?] ...will test; would appreciate input :)
# grep '' /etc/redhat-release /usr/local/cpanel/version /var/cpanel/envtype ; grep CPANEL= /etc/cpupdate.conf
/etc/redhat-release:CentOS Linux release 7.5.1804 (Core)
/usr/local/cpanel/version:11.68.0.39
/var/cpanel/envtype:kvm
CPANEL=stableand fwiw, the wildcard certificates I am using are generated and deployed using acme.sh via UAPI github.com/Neilpang/acme.sh/wiki/Simple-guide-to-add-TLS-cert-to-cpanel I use my server to host an application that requires using wildcard subdomains with valid certificates in order to operate effectively. I don't need, or even want, AutoSSL to get and install the relatively few certificates containing wildcard names that I may need. (though, when its an option, I'll try it) I would strongly prefer to rely upon AutoSSL to manage the relatively larger number of certificates for addon domains (and their renewals). Currently, the host for my fully managed server (LiquidWeb) is doing their internal process to review the issue. I believe that they have been able to replicate it but are not yet prepared to file a ticket. LW said they did not replicate independently but are going to submit a ticket anyways noting the circumstance for the report and linking to this thread. The only workable solution I have verified is to install my application at a subdomain, like apps.example.tld and then use *.apps.example.tld in operation. If I use my workaround, then I either leave *.example.tld with no installed certificate, or remove *.example.tld entirely. These options are less than great. I also create addondomains using pattern like: anyvalue.tld --> anyvalue.additionalvalue.example.tld and would be cool if this works also even if there is a valid cert for *.additionalvalue.example.tld [edit: when I have used this approach in past I was not using AutoSSL for the addons, see ps. below - also, may as well mention, I often do this via Api2] Though I do understand the current install logic, not totally sure if this is currently expected - or intended - behavior for AutoSSL? Here is a Q: I have been testing with LetsEncrypt wildcard certs via acme.sh rather than paid certificates... What would happen if I purchased and installed a valid wildcard certificate through the cPanel SSL/TLS Wizard's basic interface: is there different logic involved in certificate installation and precedence that I'm not aware of, or would the same logic be used and the same outcome expected? (my expected outcome being that AutoSSL would not effectively function for addon domains without intervention or workaround bcs of logic in 'install best available certificate' feature) Seems like there should be a way around this. Perhaps an option to not use wildcard certificates when system is selecting 'best available certificate' to install for new addon domains when AutoSSL is active would do the trick? I would really love to use AutoSSL to automatically secure addondomains upon addon creation while also retaining ability to have valid wildcard certificates installed. Please advise :) Cheers, Max ps. ...and then I realized that, esp via Api2, perhaps I had the pieces for a better workaround: just create the addon domains that I want AutoSSL to cover using second level subdomains eg. anyvalue.tld as addon domain at example.tld like anyvalue.tld --> anyvalue.additionalvalue.example.tld bcs then the cert with *.example.tld would not be a valid match (caveat: no available certificate can contain name *.addionalvalue.example.tld or it will be installed upon addon creation as 'best available') (?: in this model is it just a matter of preference/use-case that aditionalvalue.example.tld is a subdomain with a vhost versus a serveralias of example.tld vhost - also, any reason other than cert size for an individual certificate vs included in some other certificate?) [edit: drrp, if second lvl subdomain workaround works, then I'm thinking to do a wildcard sudomain with an individual cert, other first lvl subdomains will have own vhosts and certs - yeah?] ...will test; would appreciate input :)
-
Hello @MaxFein, This topic was brought up in a support ticket. Here's a summary of the response sent by one of our Technical Analysts: [QUOTE] After reviewing the issue. It seems to be working as intended per reviewing the changes documented in the change logs. We definitely intend to scan the account's SSL datastore to find ANY available certificate which would match the new domain under the account. 2017-05-02 v62. Fixed case CPANEL-11278: Only install best available ssl when setting up a new vhost. Fixed case CPANEL-12327: Ensure best available ssl is installed for new vhosts. == Automatically install best available certificate for new addon domain, parked domain, or subdomain When you create an addon domain, parked domain, or subdomain, the system will attempt to automatically secure that domain with an existing certificate. If no certificate exists within the domain's virtual host, but another certificate matches the domain, the system will secure the domain with that certificate. If no certificate matches the domain, the system will install a self-signed certificate for the domain. == Disabling "Generate a self signed SSL certificate if a CA signed certificate is not available when setting up new domains. [?]" in the tweak settings should resolve this issue. cPanel mainly implemented this change for two reasons. -- AutoSSL can issue an SSL automatically if enabled for accounts. -- Now that Apache SNI is available on most servers, this change resolves an issue regarding sites not having an SSL installed on their vhost causing them to display a different site. == Warning: If you disable this option, and a CA signed certificate is not available, when a user attempts to visit the newly created domain over https, the user will see the first SSL certificate installed on that IP address. Warning: If you enable this option and do not have a CA signed certificate or AutoSSL enabled, Google search results may point to the SSL version of the site with a self-signed certificate, which will generate warnings in the users' browser. To avoid both of these concerns, we strongly recommend that you enable AutoSSL. ==
Let us know if you have any additional questions. Thank you.0 -
Hi, I am unsure how the ticket described the issue... I understand how/why the wildcard certificate got installed, as per Fixed case CPANEL-11278: Only install best available ssl when setting up a new vhost. Fixed case CPANEL-12327: Ensure best available ssl is installed for new vhosts. The issue that I'm trying to raise is that if I install a wildcard certificate for the first level subdomain of the cPanel primary domain (like *.primary.tld) then the automatic nature of AutoSSL is essentially blocked/broken for addon domains. This seems to be the case regardless of how the wildcard certificate is obtained (eg. applies to wildcard certificates purchased via cPanel SST/TLS Wizard or other 3rd party, or issued by LetsEncrypt via acme.sh/certbot/etc). I know that all I have to do is uninstall the certificate, but I'd like to be able to use AutoSSL to automatically issue certificates without needing a touch. So, if I have to choose between using either wildcard certificates or automatic AutoSSL for addon domains, then I'd like to choose a third option... namely, using second level subdomains when creating addon domains, for example, like this: #--------------------------------------------- #--> Addon: example.com cpapi2 --user=user_name AddonDomain addaddondomain dir=%2Fpublic_html%2Fexample.com newdomain=example.com subdomain=example.com9 #--------------------------------------------- note: '9' in subdomain=example.com9 is an arbitrary value (can be useful for rewrites and such...)
This seems like it will work with the current certificate install logic. Wondering if using second level subdomains for addons like this seems to present any issues? Cheers, Max0 -
Hello Max, Wondering if using second level subdomains for addons like this seems to present any issues?
I can't think of a scenario where that would present a problem. The addon domain itself will work the same way with a second-level subdomain that it would with a first-level subdomain. Simply ensure you configure the document root to your preference when creating it. I encourage you to vote and add feedback to the following feature request: Let's Encrypt Wildcard Certificates Once implemented, it would allow for Wildcard SSL support with AutoSSL. Thank you.0 -
This is an interesting issue. Very similar to one of my on-going issues. In my case it relates to EV certs rather than wildcard but the principle that it's not an autossl generated cert still remains. Let me see if I can reword the issue: Day 1 - Create account with primary domain example.com - DNS resolves - Install wildcard or EV cert. Day 2 - Create Addon domain example2.com [domain] (DNS does not resolve now), sub.example.com [subdomain] (DNS does reslove), doc root doesn't matter. Day 3 - AutoSSL runs. It determines that the best cert for the addon VHOST block is the wildcard/EV cert because it only thinks it needs to cover sub.example.com at this time. Cert is applied. Day 4 - example2.com's DNS resolves now. Day 5 - AutoSSL runs. It sees the addon VHOST already has a valid non-autossl cert and does not attempt anything. This leaves example2.com uncovered forever. In my particular case it involves parked domains that are in the main VHOST block with the primary domain (which has an EV cert). My workaround was to always use addons and create a fake subdomain that is never used. This puts the domain in it's own VHOST block. This works when wildcard certs are not used. So to the OP, I'd just recommend not using a wildcard cert. Just make part of your creating a subdomain process, running autossl for that account. You'll get a usable cert in a few minutes. There is still the issue that EV certs on the primary domain prevent prevent autossl from working on parked domains. 0 -
I have found another workaround for this issue. Remove the incorrectly applied certificate from the addon domain's vhost, then rerun AutoSSL. 1. cPanel > SSL/TLS > Manage SSL sites 2. Click "Uninstall" opposite addon.domain.com, addon.com, www.addon.com, etc. 3. cPanel > SSL/TLS Status 4. Click: RunAutoSSL
This is a manual process through the UI, but I suppose it could be scripted.0
Please sign in to leave a comment.
Comments
5 comments