On Dec 4, 2016, at 11:03 AM, Reinis Rozitis wrote:
> In case of https I don't even think it makes sense to provide any
> certificates (even self-signed).
> Without those the connection will/should be just terminated because of peer
> not providing any certificates and self-signed certs shouldn
> Create an initial default server for failover on the ip address, and have it
> 400 everything. Do it for http and https. For https you can use a
> self-signed cert; it doesn't matter as you only need to be a valid protocol.
> # failover http server
># failover https server
You don't
On Nov 30, 2016, at 5:09 PM, steve wrote:
> 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
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
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 i
Lukas Tribus Wrote:
---
> As I said, the best way would be to drop the TLS handshake, but nginx
> doesn't support this afaik.
If you mind the overhead, ssl_preread_server_name could be used for this.
Posted at Nginx Forum:
https://forum.nginx.o
> Why should I? I clearly defined the problem/misconfiguration. I don't
> really see the need to justify why I want to fix it.
To help others, myself included to comprehend a possible problem in similar
configurations and learn more about it. After all, this is a community.
> Well, you told me
On 11/30/2016 09:17 AM, Lukas Tribus wrote:
Does it cause warnings in the webmaster tools? Who cares?
Does it affect your ranking? I doubt it.
Does it index pages or error pages from the default website and assign to
your website? I doubt that even more.
Does it upset my customer? YES.
That's
> > Does it cause warnings in the webmaster tools? Who cares?
> > Does it affect your ranking? I doubt it.
> > Does it index pages or error pages from the default website and assign to
> > your website? I doubt that even more.
>
> Does it upset my customer? YES.
>
> That's all the justification I
On 11/29/2016 09:28 PM, Lukas Tribus wrote:
What I don't see is why and how that would be a problem, even when HTTPS
is not properly setup for that particular domain.
Does it cause warnings in the webmaster tools? Who cares?
Does it affect your ranking? I doubt it.
Does it index pages or error
There's no "nice" way to handle this in nginx as far as I'm aware. I think
the best setup is a default vhost with a generic (server hostname?)
certificate, and for any bots or clients that ignore the common name
mismatch you can return the 421 Misdirected Request code.
https://httpstatuses.com/421
> > Any real life experience and evidence backing this?
> yes
Care to elaborate?
> Not sure why you're doubting me here Lukas. Yes, this is a problem. No
> I'm not making it up.
We know that crawlers like Googlebot try HTTPS as well, even if there is no
https link towards the website. That is
On 11/29/2016 09:55 AM, Lukas Tribus wrote:
It seems that search engines are probing https: even for sites that
don't offer it
Which is fine.
just because it's available for others, with the end
result that pages are being attributed to the wrong site.
Sounds like an assumption. Any rea
Just a personal preference, but i put an https version in front of all
sites(and redirect 80 to 443) and keep the certs up to date for free with
lets-encrypt/certbot (i have nothing to do with the company), with SNI,
one IP. This is simple as I keep the nginx configurations up to date with
a confi
> It seems that search engines are probing https: even for sites that
> don't offer it
Which is fine.
> just because it's available for others, with the end
> result that pages are being attributed to the wrong site.
Sounds like an assumption. Any real life experience and
evidence backing t
This is more a philosophical than technical question I suppose.
Is it necessary to purchase a SSL cert for all domains sharing an IP
address if one of them uses https?
It seems that search engines are probing https: even for sites that
don't offer it, just because it's available for others, w
16 matches
Mail list logo
