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
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
