Google / HTTPS and SNI issue

Does Google count sites running through SNI as secure?

[surfgatinho]

So, Google announce a couple of years back that you get a boost for implementing SSL. Fine I think, but most of my sites are on shared IP addresses and certificates are expensive.

Now I have decided to bite the bullet, partly because I can get free certificates through LetsEncrypt. Also it seems that modern servers use SNI (Server Name Indication) meaning I don't need a unique IP address for every domain to run HTTPS and this is supported by every modern browser.

After moving a couple of sites over to HTTPS without incident I get a message in Webmaster Central when I move the third over. This message basically tells me that my certificate is self-signed and cannot be trusted by the majority of browsers. This is strange as SSL Labs give my site a rating of A+ with the caveat of "This site works only in browsers with SNI support."

Given that IPv4 addresses are becoming a scarce commodity and SNI is virtually universally accepted by browsers what is Google thinking?!

For my websites there is no compelling reason to have SSL implemented except for a possible SEO boost. However, if Google isn't giving me this all I will be getting is the downside of having lots of redirects and wiping my social media stats.

Obviously I can try and get more IP addresses, but if everyone does this...

[surfgatinho]

TL;DR - No SEO boost for HTTPS sites run through SNI?

[keyplyr]

Related thread: [webmasterworld.com...]

The LetsEncrypt certs are supported but self-signed certs will cause issues.

[surfgatinho]

The LetsEncrypt certs are supported but self-signed certs will cause issues.

Thanks for the reply, but this is not the issue at all.

The question is whether SNI is supported by Google.

[keyplyr]

Sorry, I was responding to your statement above where you mentioned self-signed certs not being accepted. Your server may not however.

I really don't undetstand what you mean "is SNI supported by Google." Major browsers have all announced support.

What is "Webmaster Central?"

[graeme_p]

For my websites there is no compelling reason to have SSL implemented except for a possible SEO boost. However, if Google isn't giving me this all I will be getting is the downside of having lots of redirects and wiping my social media stats.

That is not a compelling reason at all. The SEO boost is probably tiny.

I have seen Google Webmaster Tools/Search COnsole called Webmaster Central before.

I assume these are not self-signed certs. Perhaps Google does not recognise the certificate authority?

[graeme_p]

It is not worth doing everything Google tell you to. Ask yourself whether it will have a positive ROI or not. In this case I am not sure why it would mess up anything to do with social media, or why the redirects are such a problem, but if it is causing problems it is probably doing net damage.

[surfgatinho]

What is "Webmaster Central?"

Google webmaster tools? I believe this is what it was ( and maybe still is) called.

I really don't undetstand what you mean "is SNI supported by Google." Major browsers have all announced support.

I am sure you are aware Google announced an SEO boost for HTTPS sites some time ago. This would rely on whether they feel a site is secure - this is what I mean by supported.

If Google does not support SNI then they will not classify a site as being secure.

I have discussed this on the Google Product forums and the received wisdom is SNI might be an issue. This is also mentioned on the LetsEncrypt forum.

For further reference the message I received from Google was "Self signed SSL/TLS certificate for [...."...] and is message type [WNC-606601].

[keyplyr]

Personally, I didn't switch to HTTPS because of the small ranking advantage. I switched to avoid the non-secure warning Chrome will start displaying in January 2017. Chrome is default for an awful lot of Android phones, tablets & notebooks.

surfgatinho, have you made sure your server supports SNI? I use LetsEncrypt and Google Search Consol has no issues with my sites.

[surfgatinho]

I am not sure why it would mess up anything to do with social media, or why the redirects are such a problem

Social media stats link to HTTP site not HTTPS version.
301 are widely regarded as costing a percentage of link juice.

Even a tiny SEO boost is worth it IMO. Also HTTPS will become the norm as well as providing possible speed benefits via HTTP/2 - I was being slightly disingenuous when I said no compelling reasons!

[graeme_p]

@keyplyr

Beginning in January 2017 (Chrome 56), we’ll mark HTTP pages that collect passwords or credit cards as non-secure, as part of a long-term plan to mark all HTTP sites as non-secure.

If you collect passwords or credit card numbers you should be using HTTPS anyway. Otherwise you have a long time (if Google rush it people will get blind to the warning anyway).

@surfgatinho

Possible speed boost - you do not know until you have tested. It may even be slower.

301 are widely regarded as costing a percentage of link juice.

Does that apply to the same URL with a different protocol? How important are these links?

[keyplyr]

@graeme_p - later it was announced Chrome will *eventually* indicate *any* HTTP page as non-secure. Further, it was indicated pages with a submission form may trigger the warning if non-secure. All my pages include a members login & a site-search.

[keyplyr]

301 are widely regarded as costing a percentage of link juice.

Not when switching from HTTP to HTTPS. Google adjusted that almost 2 years ago.

[graeme_p]

@keyplyr eventually could be a very long time!

It definitely makes sense for your site as it has login forms. You comment is the first time I have heard the suggestion that other forms could trigger the warning. I was going by this, which is where I got the quote from [security.googleblog.com ] (I forget to link above)

[robzilla]

The question is whether SNI is supported by Google

That question is moot. SNI has been around for over a decade, and is widely used. Of course it's supported. The problem is more likely to be on your end. Check, double-check, triple-check your implementation.

Is your certificate valid for both www.example.com and example.com, or at least for your exact canonical domain? Are you manually implementing the certificates or are you using a control panel? I believe there have been some issues with Plesk and Let's Encrypt. The SSL Labs test is great but it can't tell you everything.

[surfgatinho]

@Robzilla I think you are right about SNI not being the issue. This would be ridiculous. I was just being led in this direction by the "experts" on the Google Products forum...

I believe there have been some issues with Plesk and Let's Encrypt.

Yes, this is what I am running.

As I have had no issue with the two other domains I moved over to SSL I have compared all the differences in implementation I could find. The only thing I have come up with is the problem domain has an IPv6 address set in the DNS AAAA settings, whilst the others don't. This seems to default to the server domain name which has the dodgy Plesk certificate.

I have deleted the AAAA record so will see what happens....

[robzilla]

Right, that probably solves it. If IPv6 for your domain is not properly set up on the server and Googlebot accesses your site via IPv6, it'll probably get the same certificate you get when you access the Plesk interface, and that's not valid for your domain. Control panels often use self-signed certificates for their administration interfaces. Even when that self-signed certificate is accepted or ignored by Googlebot, it won't actually see your content; it will probably see a Plesk log-on page instead, so you'll probably now have fixed a crawling/indexing issue as well.

[surfgatinho]

Think I have solved this. It seems to be a mix of SNI and Plesk problems. The IPv6 thing was along the right lines but might not have been the issue.

The IP address of the site giving me problems is the same as the default IP address - the same that is used to access the Plesk control panel. The other sites I've moved over were on a different IP address.

This wasn't a problem to SNI enabled clients, but a non-SNI enabled client would see the self signed Plesk / Parallels certificate.

For the record here are the commands to check non-SNI / SNI:

openssl s_client -connect www.example.com:443 -CApath /etc/ssl/certs/
openssl s_client -connect www.example.com:443 -servername www.example.com -CApath /etc/ssl/certs/