Choisir le domaine à sécuriser

Nous avons un site Web qui est servi à la fois www.example.comet juste example.com- nous n'avons jamais fait aucune sorte de forcer les utilisateurs d'un domaine à l'autre, donc s'ils atterrissent, example.comc'est là qu'ils restent, et je suppose que ceux de ces qui signent nos pages, il s'agit d'une répartition 50/50 (il y a eu un problème plus tôt où certains de nos documents ont omis le WWW et des années plus tard, nous remarquons toujours une répartition du trafic).

Nous ajoutons maintenant SSL. Nous ne forçons pas SSL jusqu'à ce que l'utilisateur accède à la page de connexion ou d'enregistrement. Sur quel domaine devrions-nous exécuter notre SSL?

www.example.com
example.com
secure.example.com
Autre chose?

J'ai déjà fait beaucoup de sites SSL auparavant, mais ils ont toujours été conçus avec SSL à l'esprit, et nous avons toujours forcé le sous-domaine www.

Y a-t-il des avantages et des inconvénients à le faire de l'une de ces façons? Ma principale préoccupation concerne la reconnaissance des cookies, mais étant donné que nous forçons SSL à la connexion, le cookie de session sera de toute façon écrit sur le domaine SSL. Ma principale préoccupation est pour les personnes qui pourraient aller https://example.comlorsque nous exécutons le site https://www.example.com, etc.

_{Une autre question serait: "Dois-je réécrire ceux qui atterrissent sur le site non www sur le site WWW?}

— Mark Henderson
source

Selon qui vous achetez votre certificat, ils peuvent vous donner gratuitement le domaine nu comme autre nom de sujet. Donc, si vous achetez, www.example.comvous pouvez obtenir un certificat couvrant à la fois www.example.comet example.com.

— Michael Hampton

Réponses:

J'y vais habituellement secure.domain.comcar cela me donne plus de flexibilité en matière d'administration. Par exemple, je peux mettre ce sous-domaine sur un autre serveur, derrière un meilleur équipement IDS / IPS et éventuellement le connecter à un réseau privé que je ne veux pas que les serveurs Web touchent.

C'est un bon endroit pour garer des objets polyvalents, tels que:

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

... etc.

— Tim Post
source

Avez-vous déjà eu des problèmes avec les cookies? Par exemple, si un cookie est créé sur www.example.com, pouvez-vous le lire sur secure.example.com?

— Mark Henderson

@Farseeker: Vous pouvez définir le cookie pour .example.com(ou example.com, qui est le même), et cela fonctionnera à la fois pour www.example.com et secure.example.com (avec l'inconvénient, il sera toujours envoyé aux deux sous-domaines) . Voici ma page préférée sur ce sujet: code.google.com/p/browsersec/wiki/…

— Chris Lercher

@ Farseeker - Oui, les cookies se propagent aux sous-domaines, mais si vous êtes le moins malin, ce n'est pas un problème. Par exemple, cookie-> connected_in / connection-> ssl, etc. Ce n'est pas comme un CDN où leur absence est bénéfique, il suffit de les planifier et de les gérer.

— Tim Post

@ Chris, je ne savais pas que vous pouvez définir un cookie pour example.compartir www.example.com- Je vais devoir examiner cette question . Merci.

— Mark Henderson

Avec cette solution, vous pouvez également refuser secure.example.com dans votre robots.txt. Donc +1. :-)

— fwaechter

Personnellement, j'utilise simplement le certificat SSL Plus de DigiCert avec does avec example.com et www.example.com. Comme dans votre autre question, j'enverrais tout le monde à www.example.com car cela rend la vie plus facile plus tard. Faire cela maintenant vous donnera également la possibilité d'utiliser quelque chose comme secure.example.com plus tard.

J'ajoute généralement du code pour détecter si les utilisateurs exécutent HTTP alors qu'ils devraient exécuter HTTPS et les rediriger. Je trouve que cela ne se produit généralement que lors de la connexion, mais selon le site, cela peut également se produire à d'autres moments.

— Darryl Hein
source