Google nags me about the certificate being self-signed?



looks like Letsencrypt certificates are not trusted by Google. I received the following email today:

Self signed SSL/TLS certificate for https://www

To: Webmaster of https://www

Google has detected that the SSL/TLS certificate used on https://www… 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.
Recommended Action:

Get a new certificate

To correct this problem, you need to get a new, dedicated SSL/TLS certificate from a trusted Certificate Authority (CA). This certificate must match your complete site URL, or be a wildcard certificate that can be used for multiple subdomains on a domain.

So basically I’m back to square 1?!


Sounds to me like they actually believe you to be using a self signed cert which would differ from them believing your LE cert to be untrusted.

When you check your browser’s reported SSL certificate info when you browse your own site, does it look correct?

What does say on a server test result? Are the transmitted certs actually LE?

#3 tells me that my site has an “Overall C Rating”. :-/

Details of the report:

Prefix handling: Not valid for “” CONFUSING
Protocols: SSL 3 2 INSECURE
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH secp521r1 (eq. 15360 bits RSA) FS INSECURE 128
Handshake Simulation:
Incorrect certificate because this client doesn’t support SNI
Protocol Details:
POODLE (SSLv3) Vulnerable INSECURE (more info) SSL 3: 0xa
Forward Secrecy With some browsers


It looks like you’ve just picked a few lines out of the ssllabs report, which aren’t very helpful in determining whether your server is actually using a Letsencrypt cert. In the top block of the report (marked Authentication), under Server Key and Certificate #1, what does it say for Issuer? What does it say next to Trusted? What about under Additional Certificates and Certification Paths?

The insecure protocols are a problem, and you should configure your server to disable them, but they aren’t causing anyone to believe you have a self-signed certificate.


As @danb35 has mentioned your reports are incomplete.

By removing your URL in your first post and only providing a partial report in your second you essentially hindering anyone helping you.

If you have a website live and accessible through the internet then you don’t need to obscure the information on this website, additionally with open vulnerabilities you should look to get help as soon as possible.

If you provide the full reports then members of this community will be able to help you.

I would imagine though from the partial reports that you are not using the LetsEncrypt issued certificate and have a server environment that has not been configured correctly.


Thanks for your feedback, guys.

Based on your comments, I analyzed the warnings in the reports, and was able to fix my httpd.conf appropriately. The key was to remove SSL-v3 support and to activate forward secrecy. I’m now at an A+ rating instead of C! :slight_smile:

For everyone running into the same issues, I’ve found most of the necessary information at and

Now I just hope that Google will realize quickly how great and secure my server has become over night …lol


hmm… I’ve added my site to Google Webmaster tools again, and AGAIN received the email stating that
"Self signed SSL/TLS certificate for [domain]".
My website even got an A+ rating on, but Google thinks it’s self-signed?!

My site is in case anyone wants to take a look.


In my browser (iPhone) (safari & chrome) your cert looks fine and is trusted. And in SSL detective it looks fine too. Not sure what’s up with Google.

In webmaster tools you did actually add it as an https://… Site I assume correct?


Yes, the email from Google refers to the https:// … version (only) and nags me about the ‘self-signed certificate’ on this site.

I have added the http:// version too (separately) in Webmaster tools, but iirc, that’s the recommended way to do it. I don’t think that’s the reason for the problem.


Your cert does seem to only apply to

And not

Maybe something to do with what google’s telling you?


Could it be because I’ve created a 4096 bit certificate?
Here, Google recommends to use 2048 bit. Not sure whether that means ‘create at least 2048 bit certificates’ or ‘we won’t recognize certs with higher encryption’. x-)


I’m not 100% positive but i would have to imagine Google would accept the higher bit cert. I can find no evidence to the contrary. I will try it out with one of my domains and a 4096 key. standby.


Tried and tested; works fine.

Google webmaster tools hasn’t reported any issue either.


I think I have found out the reason with a helpful reply in another forum. Looks like if the server doesn’t provide SNI support, Google reports this problem as it tests the certificate with a non-SNI compatible bot (!).

So I’ll have to figure out how to enable SNI support on my CentOS/Plesk server and will update the thread according to my findings… not sure how to have Google fetch/test my site again though.


Hello @rookey,

I don’t know anything about Google bot nor Plesk, but I’m pretty sure your site is using SNI.

Here is what a browser/bot/etc. without SNI support will get trying to connect to your web server:

$ openssl s_client -connect -CApath /etc/ssl/certs/                      CONNECTED(00000003)
depth=0 C = US, ST = Washington, L = Seattle, O = Odin, OU = Plesk, CN = Plesk, emailAddress =
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = Washington, L = Seattle, O = Odin, OU = Plesk, CN = Plesk, emailAddress =
verify return:1
Certificate chain
 0 s:/C=US/ST=Washington/L=Seattle/O=Odin/OU=Plesk/CN=Plesk/
Server certificate
No client certificate CA names sent
SSL handshake has read 1588 bytes and written 424 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: B078EAD3B7BE2168425E35FE7F8045CA32A175B89831DFC1E8AE42BE60D30499
    Master-Key: 4EF4BFB3D33D5288BFDCA0BD555B80BF9121EE03C245BDB7A5D124D1F3AA314C0AA9F6BD044622E4333752A3D386D39E
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - ab df 21 1c cb ae cb 61-c7 63 09 30 9d 31 6f 85   ..!....a.c.0.1o.
    0010 - 0d 2e 0f ea 58 3b ee 6c-bd 98 cf 3b aa 9e 2e a7   ....X;.l...;....
    0020 - a4 38 13 88 0d 13 6d 7d-59 56 be 32 2c 9a 79 bc   .8....m}YV.2,.y.
    0030 - ec 34 30 29 9f c8 ab 03-8a d9 61 f1 8a e2 5e f4   .40)......a...^.
    0040 - cb 0e c9 b0 c4 69 6a f2-e4 d0 14 15 e5 8a 4f 85   .....ij.......O.
    0050 - 5a be 44 dc cc 7c f7 9e-37 30 db d7 48 1c 3a 9c   Z.D..|..70..H.:.
    0060 - cd 85 e2 7d 98 90 51 2e-ca c3 c0 69 9a f8 b6 85   ...}..Q....i....
    0070 - 06 53 c5 0c 27 23 d4 02-23 dd 9d 30 5c bb e3 80   .S..'#..#..0\...
    0080 - fe a5 41 19 b9 48 37 33-d2 02 c9 b2 9f e3 6e 1a   ..A..H73......n.
    0090 - 18 98 7d c3 8e 5b 2a ed-1c cb dd 9c c4 a2 a9 aa   ..}..[*.........
    00a0 - 19 99 dc 8f 0a 8f 20 90-e9 51 7d ca ea a7 25 f4   ...... ..Q}...%.
    00b0 - 7c cd 3a 7c d0 b2 ef 07-f8 de 19 82 c3 64 4d c3   |.:|.........dM.

    Start Time: 1450736596
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)

And this is what a browser/bot/etc. with SNI support will get:

$ openssl s_client -connect -servername -CApath /etc/ssl/certs/
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X1
verify return:1
depth=0 CN =
verify return:1
Certificate chain
 0 s:/
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
Server certificate
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
No client certificate CA names sent
SSL handshake has read 3773 bytes and written 460 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 657BB6D1081E964C6858640032A54E35C3CF0688A36B2826F533656405EE1BB5
    Master-Key: 1749CBAA9E46C162DAF967577BEBA669DCD1327557F91BEDEAA302A81F60664E9C3A0C63EA8D114EAB02D0A440F3FD07
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - ab df 21 1c cb ae cb 61-c7 63 09 30 9d 31 6f 85   ..!....a.c.0.1o.
    0010 - 91 71 81 af aa b3 1a a0-d0 29 ca 66 b7 40 27 b5   .q.......).f.@'.
    0020 - 6e ff 93 54 ae ed ad c5-fb 6b df 1a 7a 2a dd 5f   n..T.....k..z*._
    0030 - 9a d1 a1 41 2b 72 36 e9-06 be 8a 8c a6 cd 65 c0   ...A+r6.......e.
    0040 - c9 21 a3 08 cd 02 73 44-c9 ad 2b 52 b0 91 c2 63   .!....sD..+R...c
    0050 - 07 ce 0b 78 1b 64 02 0a-24 5c fe e5 a2 53 a6 12   ...x.d..$\...S..
    0060 - f8 cf c9 40 aa 84 48 24-0e f6 3a 21 89 b5 c1 70   ...@..H$..:!...p
    0070 - 1a 70 a2 8a 19 8b ea 00-05 1b e1 b3 14 c9 cf b6   .p..............
    0080 - c4 c7 06 7e ed 1a 8b fe-6e 6d e2 fb 3a da c1 97   ...~....nm..:...
    0090 - 99 aa c9 1c f1 85 40 44-d6 a2 62 6d 81 31 3c 75<u
    00a0 - 57 4c b9 db dc 1e ac 26-04 b1 c4 b0 34 a0 47 03   WL.....&....4.G.
    00b0 - 83 bc c7 24 b9 c4 c5 1a-84 64 0b 13 c9 5c 55 d7   ...$.....d...\U.
    00c0 - 8c ad 8b 8a e1 d9 d2 a1-8d 8f cb e6 27 0e f9 3e   ............'..>
    00d0 - 72 d9 9e 70 4b 9c ca 19-b4 2f 75 8d a6 ec 17 80   r..pK..../u.....

    Start Time: 1450736739
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

The first certificate is a self-signed certificate by Plesk, I don’t know what is this cert used for… also, don’t know if you share that plesk server, maybe you could change the default cert (plesk signed cert) by your own cert, so the Google bot will see your site cert correctly, don’t know… I’m here only to tell you that your site supports SNI ;).



So perhaps I can learn something here as well; all of my sites use SNI (except one) and have yet never received such a warning from google or elsewhere. If it is related to SNI, what about his config would be causing issues?


Thanks for your response, Sahsanu! I’m learning something new every day right now! :wink:
I feel we’re getting closer. Basically I was thinking that my (brand new w/ Plesk 12 and CentOS 7) server supports SNI, I just have to set it up the right way!
Looks like I’ll have to go through Plesk to avoid my settings being overwritten at every little change of config of OS update. In domain settings, Plesk asks me for

Private key (.key) *
Certificate (
.crt) *
CA certificate (*-ca.crt)

I guess “Private Key” is supposed to be privkey.pem, “Certificate” is cert.pem, and “CA Certificate” fullchain.pem?


In this case, CA should be chain.pem instead of fullchain.pem.


Clients that do not properly support SNI will end up getting all the certs tied to that IP, and may freak out for any irregularity that involves any of those certs. In this case the self-signed cert needs to be removed, or the server needs to be configured in such a way to serve the desired cert as primary. For example, nginx has a setting called default_server for this purpose:


do you have some information on how to do that without nginx (only Apache)? I have Apache 2.4.6 installed. I have spent 2 days and night so far without being able to find out how to serve non-sni capable browsers correctly.