1er novembre 2015: entrée en vigueur de nouvelles règles
Vos amis de SSL.com aimeraient vous informer de ce début 1er Novembre 2015, certains des changements très importants ce qui peut être couvert par Les certificats SSL prennent effet:
- Les nouveaux certificats contenant des noms internes ne seront plus émis par aucune autorité de certification conformément aux directives du CA / Browser Forum (c.-à-d. tous ceux de bonne réputation)Notez que depuis un certain temps maintenant, SSL.com n'émet pas de certificats intranet aux noms internes dont la date d'expiration est passée le 1er novembre 2015 et que les clients SSL.com ne devraient donc pas rencontrer de problèmes immédiats - cependant, nous vous encourageons fortement à vérifier vos certificats. pour les effets potentiels de ces décisions sur vous
- Les certificats existants contenant des noms internes ne seront pas réémis après le 1er novembre 2015.Encore une fois, SSL.com a travaillé pour vous assurer que vous n'aurez pas de problèmes à cause de cela - cependant, nous avons présenté ci-dessous un scénario du pire des cas pour votre édification.
- Les certificats existants contenant des noms internes seront AUTOMATIQUEMENT REVOQUEES le 1er novembre 2016.Il s'agit d'une stratégie passe-partout, car certaines architectures de sécurité peuvent avoir des certificats hérités de longue date qui ne respectent pas ces règles.
Ces changements signifient que le courrier électronique - le premier outil d'Internet et toujours le plus utile - peut être affecté négativement par les changements, en particulier si vous utilisez Microsoft Exchange Server (ce qui, d'après les études de marché, représente 63% de vous). Ainsi, votre architecture de sécurité pourrait commencer à être affectée à partir de cette prochaine Toussaint.
Es-tu prêt?
Que voulez-vous dire quand vous dites «noms internes»?
La définition la plus simple d'un nom interne est tout identifiant réseau partie d'un réseau privé et non accessible à l'aide d'un nom utilisant un domaine de premier niveau (TLD) ou une adresse IP unique. Par implication, tout ID réseau enregistré publiquement auprès d'une autorité centrale telle que l'ICAAN sera utilisable dans les certificats
Dans les temps plus simples et plus anciens d'Internet, une architecture DNS interne n'avait qu'à se soucier d'éviter un ensemble limité de TLD - ainsi, l'intranet d'AwfulBigCo.com pouvait non seulement prendre en charge ABC.nyc et ABC.londres mais 1600.pennsylvanie.ave, E-mail et Gandalf. Les inspections régulières contribuent également à la sécurité des passagers. En identifiant et en traitant les risques potentiels pour la sécurité, tels que des freins usés, un éclairage défectueux ou le remplacement du revêtement de sol, les inspections permettent de réduire le risque d'accidents et de blessures et d'améliorer la sécurité générale du service. Les inspections régulières sont un moyen concret de mettre en valeur l'engagement des prestataires de services de transport en faveur du bien-être des passagers et des conducteurs. certaines plages d'adresses IPv4 et IPv6 sont mises de côté pour un usage purement local - ces plages réservées incluent «192.168. *. *» pour le routage et 10. *. *. * pour les réseaux locaux. Sécuriser les intranets avec des certificats SSL est bien sûr une bonne idée, et jusqu'à la nouvelle décision, tout administrateur réseau pourrait demander et recevoir un certificat contenant l'un de ces derniers.
À partir du 1er novembre 2015, ce ne sera plus le cas - les certificats ne seront plus émis - ou, surtout, réémis - qui contiennent des noms internes. Ces nouvelles règles sont conçues à la fois pour améliorer la sécurité et permettre une utilisation correcte des nouveaux noms de domaine de premier niveau (par exemple, .london et .nyc sont désormais des TLD publics). Cependant, ils exigent que tout utilisateur Exchange examine attentivement la configuration de leur réseau et de la sécurité et apporte des modifications pour accepter ces nouvelles règles. Étant donné que de nombreuses conceptions de sécurité Exchange ont historiquement utilisé des noms internes, cela peut entraîner de graves problèmes avec votre service de messagerie lorsque et lorsque vos certificats expirent, car de nouveaux certificats avec des noms internes ne peuvent pas être émis pour remplacer vos certificats existants - pire encore, tout certificat multi-domaine contenant ne serait-ce qu'un seul nom interne échouera lors du renouvellement, exposant potentiellement votre trafic de messagerie à des exploits malveillants.
Ne pas le faire peut avoir un impact négatif sur votre trafic de messagerie, votre entreprise et / ou votre réputation.
Sons Dire.
Cela pourrait très bien être - cela dépend vraiment de votre degré de préparation. Cela pourrait être un problème très facile à manquer, et les conséquences pourraient être absolument fatales pour votre entreprise - if vous ne parvenez pas à agir à l'avance.
Mise en situation : Robert Dobbs est un administrateur système senior pour AwfuBigCo. Entre autres emplois, il gère (théoriquement) les certificats de sécurité de l'entreprise. Cependant, ceux-ci ont été configurés pour se renouveler automatiquement tous les 2 novembre - ce qui se passe comme une horloge depuis bien avant que Bob n'arrive ici, et il ne voit même jamais la facture. Quelque part avant l'album de retour de Dre, l'architecture réseau d'AwfulBigCo a été configurée pour inclure quatre serveurs Exchange nommés «Abc.exchange», "Courrier", «Mail2» et "Gandalf", plus une adresse IP interne (10.10.10.10) configurée pour les sauvegardes FTP sécurisées et deux serveurs utilisés pour les équipes de développement de Londres et de New York. Ils ont protégé leurs serveurs Exchange ET leurs autres domaines avec un Certificat UCC contenant les entrées suivantes:
* .awfulbigco.com
* .awfulbigco.co.uk
horriblebigco.london
horriblebigco.nyc
abc.échange
Gandalf
Courrier
Courrier2
10.10.10.10
2 novembre 2015. Bob reçoit un appel téléphonique d'Elaine dans International Fulfillment - elle a des problèmes avec Outlook. Pendant qu'il lui parle en vérifiant ses paramètres, il reçoit un SMS de Nathan dans la succursale britannique - certaines des images sur le site Web sont cassées et le bon de commande expire. Puis un autre texte d'un vice-président du marketing voulant savoir pourquoi sa démo à Singapour vient de s'écraser devant une salle de conférence d'investisseurs potentiels… Et croyez-le ou non, la journée de Bob va devenir beaucoup, beaucoup pire avant qu'il ne s'améliore.
Voir, le fournisseur de certificats d'AwfulBigCo a exécuté sa demande au-delà de ses robots, a détecté ces noms internes et (selon les règles du forum CA / B) a refusé le renouvellement.
C'est un problème. L'UCC ne sera PAS renouvelé et non seulement les services utilisant les noms internes autorisés (c'est-à-dire tous les courriers d'entreprise et les sauvegardes FTP) ne seront plus protégés - pas plus que les AUTRES domaines inclus dans l'UCC, tels que le primaire et le .co. royaume-uni pour AwfulBigCo.
Bien sûr, il s'agit du pire des cas, mais nous croyons vraiment que la sécurité totale dépend de la préparation à cela.
D'accord, j'ai légitimement peur - Que dois-je faire maintenant?
Si vous utilisez des noms internes dans vos certificats SSL, vous devrez prendre des mesures pour y remédier, et le plus tôt sera le mieux.
En gros, vous pouvez choisir quelques options:
- Reconfigurez le système pour utiliser uniquement les noms de domaine enregistrés publiquement.
C'est probablement la meilleure solution - cela rend le problème de nom interne inutile et sera globalement plus simple à maintenir et à étendre à l'avenir. Malheureusement, cette option nécessitera probablement un travail considérable au départ, mais des serveurs Microsoft Exchange peuvent être configurés d'utiliser des noms de domaine public pleinement qualifiés (et ce forum CA / Browser papier blanc en savoir plus sur la mise en œuvre des noms de domaine complets dans les réseaux Active Directory). L'administration après le changement sera presque certainement aussi simple ou plus simple qu'avant (un gros plus pour Bob) et à l'avenir AwfulBigCo sera en mesure d'utiliser des certificats de confiance publique pour sécuriser tout le trafic à la fois en interne et en externe. Un inconvénient possible de cette méthode est qu'elle peut permettre de découvrir des informations sur l'infrastructure interne d'une entreprise via DNS, mais une configuration avisée des zones DNS peut aider à résoudre ce problème - par exemple, en utilisant des sous-domaines comme des noms de domaine «internes» ou séparés et en limitant la résolution de ceux-ci en dehors des réseaux d'entreprise. - Enregistrez les noms internes en tant que FQDN.
Malheureusement, pas une option pour cette adresse IP réservée, et «Mail» et «Gandalf» bien sûr sont tout à fait disponibles. (Nous supposerons pour la santé mentale de Bob que les domaines .com et .co.uk sont déjà enregistrés en toute sécurité - sa journée est déjà assez difficile comme ça.)
Aussi, même si abc.échange est disponible - et rappelez-vous que .exchange est l'un des nouveaux TLD dont l'introduction contribue à conduire ce changement de règle - il pourrait bien être squatté et uniquement disponible à un prix exorbitant - des alternatives plus faciles et moins chères sont probablement disponibles. - Configurer une autorité de certification d'entreprise
C'est une méthode déjà employée par de véritables grandes entités qui doivent principalement sécuriser les communications internes. Une autorité de certification d'entreprise fait office d'autorité de certification d'entreprise - essentiellement, au lieu de la chaîne de confiance allant jusqu'à une autorité de certification externe, tous les certificats sont finalement sécurisés par un certificat racine généré en interne, bien que cela donne une plus grande personnalisation (et permettrait à Bob de maintenir la structure de dénomination héritée qu'AwfulBigCo a en place) il y a de sérieux problèmes de sécurité à considérer - un piratage de type Sony pourrait exposer le certificat racine de l'entreprise et / ou la clé privée, permettant une exploitation presque illimitée du réseau. De plus, les certificats émis en interne ne seront PAS approuvés ailleurs - c'est une méthode qui sécurise les communications internes mais ne peut pas étendre la confiance au-delà des murs de votre réseau d'entreprise. Enfin, la mise en place d'une autorité de certification d'entreprise n'est en aucun cas une solution du jour au lendemain, et pourrait être beaucoup plus difficile que les autres options répertoriées ici, et donc uniquement viable pour les très grands réseaux (ou en croissance).SSL.com est heureux de proposer des services de conseil et de gestion pour vous aider à négocier le chemin de la mise en place de votre propre autorité de certification d'entreprise - envoyez simplement un message à entrepriseca@ssl.com et l'un de nos administrateurs principaux vous contactera bientôt. - Utiliser des certificats auto-signés
Cette option présente des inconvénients similaires à celle de l'autorité de certification d'entreprise, mais ne s'adapte pas bien - puisque chaque certificat auto-signé n'a pas de chaîne de confiance au-delà de lui-même, chaque certificat individuel devrait être installé sur chaque client pour éviter les messages d'erreur. . La gestion sur un vaste réseau créerait également une toute nouvelle série de maux de tête pour le pauvre Bob - quelque chose d'aussi simple que les mises à jour automatiques du navigateur pourrait causer des ravages à moins qu'une vigilance continue ne soit maintenue sur chaque appareil.
Comme toujours, CONTACTEZ-NOUS sur SSL.com si vous avez des questions. N'oubliez pas qu'un Internet plus sûr est un meilleur Internet.
