SNI and certs.

steve steve at
Wed Nov 30 22:09:13 UTC 2016

On 12/01/2016 08:30 AM, Jonathan Vanasco wrote:
> On Nov 28, 2016, at 4:07 PM, Jeff Dyke wrote:
>> And you do get a small SEO boost for being https forward.
> Not necessarily -- some SEO engines are now doing the opposite, and 
> penalizing non-https sites.  Google announced plans to start labeling 
> non-https sites as "insecure" in 2017 too.
> It's incredibly simple (and free) to set up SSL via LetsEncrypt on all 
> domains - so I would do that.
The LetsEncrypt concept was corrupted from the start by it's use by 
hackers / malware sites. If you're serious with security then an 
oldschool $10 cert from Comodo is far better.
Sure LE is a solution, but multiple SSL cert providers is getting a bit 
complex really.

( plus LE have already been hacked themselves )
> On Nov 28, 2016, at 2:37 PM, steve wrote:
>> It seems that search engines are probing https: even for sites that 
>> don't offer it, just because it's available for others, with the end 
>> result that pages are being attributed to the wrong site.
> In terms of your current situation with SEO and attribution -- can the 
> original poster share any examples of the search engines and 
> domains/results?  I'd honestly love to see some of what is going on, 
> what you interpreted pretty much never happens.  A search engine might 
> probe for data via https; but it won't attribute a resource to a 
> domain/protocol it didn't actually load it from.     This alleged 
> Search Engine behavior is something that I've never seen with Google, 
> Bing (or other "standard" engines) and I've managed SEO for a handful 
> of top publishers.   From my experience and a lack of evidence, I have 
> no reason to believe this is the actual problem.
Well, no as I've fixed this. However, if you have a probe for site x on 
https: and it doesn't exist, then the default https site for that IP 
address will be returned. Depending on configuration, it may still be 
attributed to the original search domain. I don't understand why people 
keep trying to shoot me down on this!
> OTOMH, there are a lot of possible issues that could cause this.
> The most likely issue is that there is a misconfiguration on nginx and 
> 3 things are happening:
> 1. there exists a link to the "wrong domain" for the content somewhere 
> on the internet
> 2. nginx is serving a file on the "wrong domain"
> 3. the pages do not list a "canonical url"
> If you have a thoroughly broken nginx installation and are serving the 
> content on a wrong domain, almost every search engine will transfer 
> the resource's link equity to the canonical URL.  They're only going 
> to show the data on the wrong domain/scheme if you allowed it to be 
> served on the wrong domain/scheme, and failed to include a canonical.
Note: I host these sites, I do not write the sites in question. Addition 
of canonical headers is beyond my remit, although I suppose nginx could 
be coerced into adding one. Interestingly, neither of the CMSes I 
primarily work with ( Magento and WordPress ) seem to add in canonical 
headers either. I must research this further.
> If you are dealing with a broken search engine/spider for random 
> service, there are lots of those, and you want to address it....  The 
> problem could be because the client doesn't process SSL or SNI 
> correctly, so you might be able to do:
> A) single certificate HTTPS on IP#1 + (SNI HTTPS & plain-http on IP#2)
> B) single certificate HTTPS on IP#1 + SNI HTTPS on IP#2 + Plain HTTP 
> on IP#3
> You could also just isolate the given spiders by their browser id, and 
> handle them with custom content or redirects.
> None of the major search engines work in the manner you suggest though.
The problem was with Google...

Steve Holdoway BSc(Hons) MIITP
Skype: sholdowa

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx mailing list