Escolhendo qual domínio proteger

Temos um site que é veiculado em ambos www.example.come apenas example.com- nunca fizemos nenhum tipo de forçar os usuários de um domínio para o outro; portanto, se eles pousarem example.com, é aí que ficam, e eu acho que esses quem marcar as nossas páginas como favoritos, teria uma divisão 50/50 (houve um problema anterior em que parte do nosso material omitiu a WWW e, anos depois, ainda estamos percebendo uma divisão do tráfego).

Agora estamos adicionando SSL. Não forçaremos o SSL até que o usuário acesse a página de login ou registro. Em qual domínio devemos executar nosso SSL?

www.example.com
example.com
secure.example.com
Algo mais?

Já fiz muitos sites SSL antes, mas eles sempre foram projetados com o SSL em mente e sempre forçamos o subdomínio www.

Existem prós e contras de fazê-lo de alguma maneira? Minha principal preocupação é com o reconhecimento de cookies, mas, como estamos forçando o SSL no logon, o cookie da sessão será gravado no domínio SSL. Minha principal preocupação é com as pessoas que podem acessar https://example.comquando estamos executando o site https://www.example.com, etc.

_{Outra pergunta seria: "Devo reescrever aqueles que acessam o site não www no site da WWW?}

— Mark Henderson
fonte

Dependendo de quem você compra o seu certificado, eles podem fornecer o domínio nu como um nome alternativo de assunto gratuitamente. Portanto, se você comprar, www.example.compoderá obter um certificado que cubra ambos www.example.come example.com.

— Michael Hampton

Respostas:

Eu costumo ir secure.domain.comporque me dá mais flexibilidade na administração. Por exemplo, eu posso colocar esse subdomínio em outro servidor, por trás de um equipamento IDS / IPS melhor e, possivelmente, conectá-lo a uma rede privada na qual não quero que os servidores da Web estejam tocando.

É um bom lugar para estacionar coisas polivalentes, como:

secure.domain.com/checkout/
secure.domain.com/portal/
secure.domain.com/support/

... etc.

— Tim Post
fonte

Você já teve problemas com cookies? Por exemplo, se um cookie é criado em www.example.com, você pode lê-lo em secure.example.com?

— Mark Henderson

@ Farseeker: você pode definir o cookie para .example.com(ou example.com, que é o mesmo) e funcionará para www.example.com e secure.example.com (com a desvantagem de que ele sempre será enviado aos dois subdomínios) . Aqui está minha página favorita sobre este tópico: code.google.com/p/browsersec/wiki/…

— Chris Lercher

@ Farseeker - Sim, os cookies se propagam para subdomínios, no entanto, se você é o menos inteligente, isso não é problema. Por exemplo, cookie-> log_in / connection-> ssl, etc. Não é como um CDN onde sua ausência é benéfica, eles apenas precisam ser planejados e gerenciados.

— Tim Post

@ Chris, eu não sabia que você poderia definir um cookie para example.compartir www.example.com- eu vou ter que olhar para isso. Obrigado.

— Mark Henderson

Com esta solução, você também pode negar secure.example.com no seu robots.txt. Então, +1. :-)

— fwaechter 01/08/19

Pessoalmente, apenas uso o certificado SSL Plus do DigiCert com o exemplo.com e www.exemplo.com. Como em sua outra pergunta, eu ainda enviava todo mundo para www.example.com, porque facilita a vida mais tarde. Ao fazer isso agora, você também terá a oportunidade de usar algo como secure.example.com posteriormente.

Normalmente, adiciono código para detectar se os usuários estão executando HTTP quando deveriam estar executando HTTPS e redirecioná-los. Acho que isso geralmente acontece apenas durante o login, mas, dependendo do site, também pode acontecer outras vezes.

— Darryl Hein
fonte