Facebook
Twitter
learning_curve
Golden Pleskian
Since switching over to Plesk, so far our experience has been very good indeed. This one is only a minor issue, but somebody may possibly have the answer. We had some previous challenges with renewing Let's Encrypt SSL Certs (Previous Thread) but the latest Plesk extention update has cured that completely on our setup now, which is great.
We have 15 domains on one server. Some domains are setup as re-directs, some are live sites. One of the domains has a GeoTrust Wildcard SSL certificate, the others all have Let's Encrypt SSL certificates. Within the Plesk panel, the server Full Hostname was intentionally given the title of a real, valid, sub-domain of the domain that has the GeoTrust Wildcard SSL certificate. Using this setup and all the other security setting that are configured, this provides an A+ report for that specific domain when using Qualy SSL Labs as the certificate path is 100% correct.
The other domains (despite having Certificate and Protocol Support Scores of 100%) only have A reports as the certificate path (i.e. above ^ the valid Let's Encrypt SSL Cert) is slightly compromised because there is a name mismatch. There's No SSL certificate issues at all, just the slight name mismatch in the certificate path itself and... this is only when using the Qualy SSL Labs tests. When running tests via High Tech Bridge for instance, the second certificate on all the other domains i.e. the certificate path itself outside of Let's Encrypt is ignored. High Tech Bridge simply validate the Let's Encrypt certificates for each domain itself report all these other domains as A+ too.
That's not the problem, it's just the background to understand the current setup. The minor issue is that the Plesk Panel itself i.e. https:// IP Address :8443 when run on Mozilla, provides this error:
https:// IP Address :8443 uses an invalid security certificate. The certificate is only valid for the following names: *.domain name, domain name Error code: SSL_ERROR_BAD_CERT_DOMAIN
Technically speaking, we guess this is correct (but there is the Mozilla option to 'Add Exception') however, we are wondering why this is being reported because a) The Plesk Panel Full Hostname setting is correct to match the Wildcard GeoTrust SSL Cert, the https:// IP Address :8443/admin/ssl-certificate/list page shows that the Wildcard GeoTrust SSL is being used as the certificate for securing both Plesk and Mail and, the cloud server itself is also correctly named via the (non-plesk) Cloud Server Control Panel.
Is this error simply because the Wildcard GeoTrust SSL doesn't list an IP address (only a domain name) and whilst ignoring DNS for whatever reason (the ptr / reverse IP look up is 100% correct for the IP being used i.e. a verifiable link back to the sub-domain name mentioned above) the url used in the Mozilla browser is only an IP address, hence the Wildcard element of the SSL Certificate fails?
Or, is there perhaps an old Plesk database setting (e.g. the original Full Hostname) that wasn't overwritten when we originally set all this up, thus the Wildcard element of the SSL Certificate fails? This maybe unlikely but the "Advanced' option in Mozilla does allow a view of the offered SSL Certificate, which is the correct one i.e. the above GeoTrust Wildcard SSL certificate, so Mozilla would be looking for that domain name / server hostname against the url...
Or finally, is it something we have completely missed, but need not be concerned about anyway, as all the domains themselves are totally unaffected, it's only the Plesk Panel itself (via Mozilla) that has this error and we are the only people who use it?
We have 15 domains on one server. Some domains are setup as re-directs, some are live sites. One of the domains has a GeoTrust Wildcard SSL certificate, the others all have Let's Encrypt SSL certificates. Within the Plesk panel, the server Full Hostname was intentionally given the title of a real, valid, sub-domain of the domain that has the GeoTrust Wildcard SSL certificate. Using this setup and all the other security setting that are configured, this provides an A+ report for that specific domain when using Qualy SSL Labs as the certificate path is 100% correct.
The other domains (despite having Certificate and Protocol Support Scores of 100%) only have A reports as the certificate path (i.e. above ^ the valid Let's Encrypt SSL Cert) is slightly compromised because there is a name mismatch. There's No SSL certificate issues at all, just the slight name mismatch in the certificate path itself and... this is only when using the Qualy SSL Labs tests. When running tests via High Tech Bridge for instance, the second certificate on all the other domains i.e. the certificate path itself outside of Let's Encrypt is ignored. High Tech Bridge simply validate the Let's Encrypt certificates for each domain itself report all these other domains as A+ too.
That's not the problem, it's just the background to understand the current setup. The minor issue is that the Plesk Panel itself i.e. https:// IP Address :8443 when run on Mozilla, provides this error:
https:// IP Address :8443 uses an invalid security certificate. The certificate is only valid for the following names: *.domain name, domain name Error code: SSL_ERROR_BAD_CERT_DOMAIN
Technically speaking, we guess this is correct (but there is the Mozilla option to 'Add Exception') however, we are wondering why this is being reported because a) The Plesk Panel Full Hostname setting is correct to match the Wildcard GeoTrust SSL Cert, the https:// IP Address :8443/admin/ssl-certificate/list page shows that the Wildcard GeoTrust SSL is being used as the certificate for securing both Plesk and Mail and, the cloud server itself is also correctly named via the (non-plesk) Cloud Server Control Panel.
Is this error simply because the Wildcard GeoTrust SSL doesn't list an IP address (only a domain name) and whilst ignoring DNS for whatever reason (the ptr / reverse IP look up is 100% correct for the IP being used i.e. a verifiable link back to the sub-domain name mentioned above) the url used in the Mozilla browser is only an IP address, hence the Wildcard element of the SSL Certificate fails?
Or, is there perhaps an old Plesk database setting (e.g. the original Full Hostname) that wasn't overwritten when we originally set all this up, thus the Wildcard element of the SSL Certificate fails? This maybe unlikely but the "Advanced' option in Mozilla does allow a view of the offered SSL Certificate, which is the correct one i.e. the above GeoTrust Wildcard SSL certificate, so Mozilla would be looking for that domain name / server hostname against the url...
Or finally, is it something we have completely missed, but need not be concerned about anyway, as all the domains themselves are totally unaffected, it's only the Plesk Panel itself (via Mozilla) that has this error and we are the only people who use it?
