Y a-t-il une raison de sécurité de ne pas utiliser un certificat générique autre que la gestion et l'exploitation s'il est utilisé sur plusieurs serveurs?

J'ai un conseiller en sécurité qui me dit que nous ne pouvons pas utiliser de certificats SSL génériques pour des raisons de sécurité. Pour être clair, je préfère de loin utiliser des certificats uniques ou des certificats multi-domaines (SAN). Cependant, nous avons besoin du serveur (plesk) pour serveur 100s de sous-domaines.

Sur la base de mes recherches, la principale raison pour laquelle les gens ne utilisent pas de caractères génériques est la suivante, qui semble provenir de Verisign:

• Sécurité: si un serveur ou un sous-domaine est compromis, tous les sous-domaines peuvent être compromis.
• Gestion: si le certificat générique doit être révoqué, tous les sous-domaines auront besoin d'un nouveau certificat.
• Compatibilité: les certificats génériques peuvent ne pas fonctionner de manière transparente avec les
  anciennes configurations serveur-client.
• Protection: les certificats SSL VeriSign Wildcard ne sont pas protégés par la garantie prolongée NetSure.

Étant donné que la clé privée, le certificat et le sous-domaine existeront tous sur le même serveur ... le remplacement serait aussi simple que de remplacer ce certificat et affectera le même nombre d'utilisateurs. Par conséquent, y a-t-il une autre raison de ne pas utiliser de certificat générique?

Le seul autre problème que je connaisse est que les certificats de validation étendue ne peuvent pas être émis avec un caractère générique , donc ce n'est pas une option si vous optez pour un certificat EV.

En termes de sécurité, vous avez mis le doigt sur la tête - une seule clé privée protège tous les domaines qui sont sous le caractère générique. Ainsi, par exemple, si vous disposiez d'un certificat SAN multi-domaine couvert www.example.comet something.example.comcompromis, seuls ces deux domaines risquent d'être attaqués avec la clé compromise.

Cependant, si ce même système exécutait à la place un *.example.comcertificat pour gérer le trafic SSL wwwet les somethingsous - domaines et était compromis, alors tout ce qui est couvert par ce caractère générique est potentiellement à risque, même les services non hébergés directement sur ce serveur, par exemple webmail.example.com.

Sécurité: si un serveur ou un sous-domaine est compromis, tous les sous-domaines peuvent être compromis.

Si vous utilisez un seul serveur Web pour vos centaines d'hôtes virtuels, toutes les clés privées doivent être lisibles par ce processus de serveur Web. Si une personne peut compromettre le système à un point où elle peut lire une clé / un certificat, elle a probablement déjà compromis le système à un point où elle peut récupérer toutes les clés / certificats privés utilisés par ce serveur Web.

Les clés sont généralement stockées sur le système de fichiers avec des privilèges qui ne permettront qu'à root d'y accéder. Donc, si votre système est enraciné, vous avez probablement tout perdu. Peu importe si vous avez un seul certificat ou plusieurs.

Gestion: si le certificat générique doit être révoqué, tous les sous-domaines auront besoin d'un nouveau certificat.

Si vous utilisez un caractère générique pour * .example.org, il vous suffit de remplacer un seul certificat. Si vous avez un certificat pour one.example.org, two.example.org et three.example.org, vous devez remplacer 3 certificats. Le certificat générique représente donc moins de travail. Alors oui, ce certificat serait révoqué et remplacé, mais comme vous n'avez qu'à en remplacer un au lieu de centaines, cela devrait être très facile.

Compatibilité: les certificats génériques peuvent ne pas fonctionner de manière transparente avec les anciennes configurations serveur-client.

Ces systèmes doivent presque certainement être mis à jour. Ils présentent presque certainement de nombreuses autres vulnérabilités.