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 ) are not covered by any valid certificate
however, here is the issue:
Until the valid certificate containing *.example.tld is uninstalled from the anyvalue.example.tld vhost, AutoSSL will only fail bcs it will not touch a valid, non-expiring, non-AutoSSL certificate
Obviously, this means that any other names at the anyvalue.example.tld vhost will not work with https without intervention (eg. cert mis-match at 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
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 ) are not covered by any valid certificate
however, here is the issue:
Until the valid certificate containing *.example.tld is uninstalled from the anyvalue.example.tld vhost, AutoSSL will only fail bcs it will not touch a valid, non-expiring, non-AutoSSL certificate
Obviously, this means that any other names at the anyvalue.example.tld vhost will not work with https without intervention (eg. cert mis-match at anyvalue.tld www.anyvalue.tld and mail.anyvalue.tld ).
Code:
# 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=stable
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.
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
Last edited: