Have a look here for basic requirements on your end:
Admittedly, I’m not fully up to speed regarding Apache/SSL/SNI etc., but for what I’ve found out so far, there seems to be no way of making a couple of virtual hosts with individual SSL certificates work on an Apache server for older browsers, even if the server itself (such as mine) supports SNI. Older browsers (and the Google bot) will always land at the ‘default’ vhost and presented it’s ‘default’ certificate (in my case, the default self-signed one from Plesk). Even if I configure one of the vhosts as the default one and assign the appropriate certificates, all other vhosts will produce a ‘site mismatch’ error with these older browsers. Or would putting all vhosts I’d like to secure by SSL into 1 certificate help?
Edit: I tried it with creating a combined certificate - I still get the message that a SNI-compatible browser is required.
You need to find out how to remove/replace the default cert in Plesk, it must be there somewhere.
Thanks for flagging this. I just installed my first certificate on http://www.edenstudios.com and soon after registering the site with Google Webmaster Tools also received the email.
Ironically Googles troubleshooting link in the email leads to a 404 not found page.
I’m on CPanel Plesk and pretty similar setup to you so looking forward to resolving.
What versions of Plesk are you two running? There are plenty of google search results pertaining to Plesk with SNI issues. Depends on your version though.
Plesk 12.5.30 w/ latest update here.
12.5.30 here too. Thanks for tip.
I dont know if this is related but the latest update (#17) for Plesk
Obsolete files for SSL certificates issues using the Let’s Encrypt extension were not removed after > certificate renewal. (PPPM-3778)
Wondering is this will help?
Not sure; does that mean Plesk should have removed all traces of the default cert as part of the process? Did you enroll with LE using a Plesk provided plugin? Or was it done manually using their official client or another?
@Sparrow due to some configuration error (that occured since 2 or 3 days ago only) I couldn’t even install update #17 yet, so that’s won’t be the reason (I’m running on update #14). Thanks anyway!
@Fsantiago1979 I installed with “letsencrypt-auto certonly -a manual” , so I’m quite sure there was no interference of any kind with Plesk. The only thing I did was extending the existing httpd.conf files of the respective domains by the SSL sections and adding the LE certificate paths in there.
Good news: Plesk ‘natively’ supports Letsencrypt certificates now!
I ran into it by chance actually … the “Extensions Catalog” popped up with the Letsencrypt option a few days ago. This motivated me to reinstall my server because I had updating issues that annoyed me since a few weeks, also, I wasn’t sure if I hadn’t messed up the ssl and certificate configurations too much already. So I clicked the button…
As far as I can tell, several adjustments would still be required to make everything work smoothly:
- only 2048 bit certificates are issued, I have to find out how to push Plesk to request 4098 bit ones
- security rating went down to “C” again -> I have yet to figure out how to add the required directives without directly hacking the plesk-generated httpd.conf files
- ssllabs still says ‘This site works only in browsers with SNI support.’ which makes me expect Google will still not qualify them as ‘secure’ sites.
- not possible to create certificates for domains containing German Umlauts, but I think that’s not a Plesk problem but Letsencrypt doesn’t support encoded domain names yet.
Any findings: please feel free to add here as a reference!
That’s good news.
Just curious, why push for 4096 certs? Don’t recall if you mentioned this already.
4096 for my extremely secret data of course. No, no special reason.
For everyone interested, I now get an “A” (no A+ though ) rating with the following settings in in ssl.conf
SSLHonorCipherOrder on SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4" SSLProtocol all -SSLv3 -SSLv2 -TLSv1 -TLSv1.1 SSLCompression Off KeepAlive On
Still, “This site works only in browsers with SNI support.” and as said, Letsencrypt doesn’t support umlauts yet.
Restricting tls1.1 isn’t too much for your audience?
good thinking … I’ll remove that, thanks!
That’ll require HSTS as far as I know
Hello I have the same problem of @rookey, Google sent me the same email, on the website www.sinfonieonline.it
I have a web hosting with plesk panel 12.5.30 with the include option to activate a Let’s Encrypt Certificate, and I did it.
If I try the terminal command @sahsanu used I have this kind of results:
openssl s_client -connect www.sinfonieonline.it:443 -CApath /etc/ssl/certs/
depth=0 /C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/emailAddressemail@example.com
verify error:num=18**:self signed certificate**
i:/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
1 s:/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
Any idea how can I fix it, because looks like google is ranking down the website
I found same issue with our site.
Google has detected that the SSL/TLS certificate used on https://edupediapublications.org/ is self-signed, which means that it was issued by your server rather than by a Certificate Authority.
How to resolve it?
As with some of the other people above, the problem appears to be the behavior of your site when accessed by a non-SNI capable client that does not send a specific hostname as part of the TLS session negotiation.
I gave some more information about this in your new thread at
We are having a similar issue with Google Console
We are hosting on Google Cloud using Cloudways.com and Lets Encrypt Cert. Anyone else use Cloudways and LetsEncrypt?
SSLabs is reporting an A across the board however Google is notifying us of the following:
To: Webmaster of https://www.socialproof.xyz/
Google has detected that the SSL/TLS certificate used on https://www.socialproof.xyz/ is self-signed, which means that it was issued by your server rather than by a Certificate Authority. Because only Certificate Authorities are considered trusted sources for SSL/TLS certificates, your certificate cannot be trusted by most of the browsers. In addition, a self-signed certificate means that your content is not authenticated, it can be modified, and your user’s data or browsing behavior can be intercepted by a third-party. As a result, many web browsers will block users by displaying a security warning message when your site is accessed. This is done to protect users’ browsing behavior from being intercepted by a third party, which can happen on sites that are not secure.