Ma société a développé un service Web .NET et une DLL client qui utilise ce service Web. Le service Web est hébergé sur notre serveur via SSL et le certificat est fourni et signé par Godaddy. Nous avons des clients dans un environnement hébergé qui obtiennent le message d'erreur suivant de la DLL client lorsqu'il tente d'accéder à notre service Web.
system.net.webException La connexion sous-jacente a été fermée: Impossible d'établir une relation de confiance pour la chaîne sécurisée SSL / TLS.
Notre correctif a été de les ouvrir à IE sur le serveur, ce qui constitue un défi et en soi pour beaucoup de services hébergés et d'aller à l'URL WSDL. Ie les incite ensuite avec une boîte de dialogue d'alerte de sécurité. Il est indiqué que la date de certification est valide et un nom valide correspondant au nom de la page, mais a été émis par une entreprise que vous n'avez pas choisi de confiance. Lorsqu'ils cliquent sur Oui pour continuer, la DLL client peut ensuite se connecter avec succès au service Web et fonctionner comme normale.
Quelqu'un a-t-il une idée de la raison pour laquelle Godaddy n'aurait pas été dans la liste des éditeurs valides? Tous les serveurs que nous avons en cours d'exécution ont Godaddy comme une autorité valide. Je suppose que pour des raisons de sécurité, ils ont désinstallé l'autorité de GoDaddy, mais pas totalement convaincus qu'il n'y a pas d'autre problème sous-jacent.
Malheureusement, je n'ai pas eu beaucoup de chance d'essayer de recréer cela localement. Si je passe dans des options Internet et que vous supprimez les autorités de Godaddy et frappez notre service, SSL fonctionne tout simplement bien. Je retourne dans la liste des éditeurs et Godaddy se fait de retour dans. Donc, ma deuxième question est, comment diable as-tu débarrassé de GoDaddy afin que je puisse obtenir un avertissement de cert invalide?
D'accord, dernière question. Existe-t-il un moyen de dire au service Web d'ignorer les certificats invalides. J'ai vu des messages sur ce faisant de cela de manière programmable avec WCF mais pas les anciens services Web.
5 Réponses :
C'est vraiment plus une question Serverfault, mais j'ajouterai ce que je peux ici.
La liste des autorités de certification racine que Windows Machines est normalement fiduciaire est mise à jour régulièrement régulièrement. Cela revient comme une mise à jour de Windows sur IE. Vous pouvez voir MSDN pour plus d'informations .
Si vos clients n'ont pas de mise à jour Windows activé ou ignorent activement les mises à jour de Windows, qui est malheureusement très fréquente pour beaucoup de départements informatiques, il n'y a pas grand chose que vous puissiez faire autre chose que des fournisseurs SSL.
Fondamentalement, ils doivent obtenir les mises à jour de certificat ou vous devez passer à un fournisseur de certificats qui a une forte probabilité d'être déjà approuvée par les machines en question. Généralement, cela signifie VeriSign ou Thawte . La troisième alternative est la route que vous allez en panne: faites-les faire confiance manuellement à la racine ca.
À la fin de la journée, je déteste l'idée de changer une application de cette manière simplement parce que les départements informatiques en question sont des abrutis mais la vraie question se résume à la façon dont votre entreprise veut gérer cela.
Vous devrez peut-être installer sur vos serveurs les certificats intermédiaires utilisés pour signer vos certs SSL.
Les navigateurs tenteront de valider le certificat SSL en vérifiant la validation de la chaîne de certificats signé le certificat SSL. Si le serveur ne fournit pas la chaîne de certificat avec le certificat SSL, le navigateur peut rejeter le certificat SSL. (Plus d'un problème pour Firefox que IE). Le certificat racine doit toujours être installé sur la machine clientèle pour que l'une d'entre elles fonctionne.
Je ne dis pas que vous avez tort, mais il semble que le navigateur ne doit pas demander au serveur de sa liste de certificats root ... Cela semble être un énorme trou de sécurité. En outre, on dirait que les machines en question ne font pas confiance à GoDaddy en tant que ca. Cela signifie que le navigateur n'a pas de GoDaddy inscrit dans la liste des autorités racines de confiance. Le seul moyen d'y arriver est via une mise à jour de Microsoft ou la confiture manuelle.
@Chris: Un problème courant dans les installations SSL est que le serveur renvoie uniquement le certificat de nœud de feuille sans indication de la chaîne de certificats. IE Navigateur acceptera souvent de tels certs, mais Firefox ne le fera pas. La solution pour apaiser Firefox est de vous assurer que vos certificats intermédiaires sont disponibles sur le serveur. Vous avez probablement raison de la racine cert - j'ai édité la réponse.
Lorsque vous regardez le chemin de certification GO DADDY de ce certificat sur le serveur Web, voyez-vous Go Daddy Class XXX ou Starfield Class XXX?
et de votre client non hérité I.e Windows Vista vers le haut, quelle est l'affichage du chemin de certification Go Daddy? Go Daddy Class XXX ou Classe Starfield XXX?
et ces clients qui obtiennent l'avertissement, sont-ils des clients hérités? I.e WinXP et plus âgé?
Les mises à jour du certificat racine fonctionnent différemment à partir de Windows Vista.
http://support.microsoft.com/kb/931125
Les certificats root sur Windows Vista et sont ensuite distribués via le mécanisme automatique de mise à jour de racine - c'est-à-dire par certificat racine. Lorsqu'un utilisateur visite un site Web sécurisé (à l'aide de HTTPS SSL), lit un courrier électronique sécurisé (S / Mime) ou télécharge un contrôle ActiveX signé (signature de code) et rencontre un nouveau certificat racine, le logiciel de vérification de la chaîne de certificats Windows. Vérifie Microsoft Update pour le certificat racine. S'il le trouve, il télécharge la liste de fiducie de certificat actuelle (CTL) contenant la liste de tous les certificats racines de confiance du programme et vérifie que le certificat racine est répertorié. Il télécharge ensuite le certificat racine spécifié sur le système et l'installe dans le magasin des autorités de certification racine de la racine de Windows.
Vous constaterez probablement que votre chemin de certification Go Daddy sur le serveur Web pense qu'il est Starfield Class 2 au lieu de Go Daddy Class 2, vous avez donc installé le mauvais certificat racine. Cela m'a attrapé que lorsque vous affichez sur le serveur Web, il ne présente pas d'avertissement de certificat racine, téléchargez et installez le certificat racine de la classe 2 de DADDY et supprimez le Starfield One et votre problème devrait disparaître.
J'ai corrigé cette erreur en ajoutant cette ligne avant d'appeler la méthode Web:
System.Net.ServicePointManager.ServerCertificateValidationCallback = (senderX, certificate, chain, sslPolicyErrors) => { return true; };
Même si ce n'est pas la solution idéale, si vous utilisez un SSL non valide (qui pourrait être inévitable dans certains cas), cela pourrait être une solution acceptable, vous donner de même que vous comprenez ce que vous faites.
Cela ne peut pas être une solution à moins que vous ajoutez une logique personnalisée pour valider votre certificat. Vous ne pouvez pas simplement accepter aucun certificat dans Prod. Il ne sert à rien d'utiliser SSL / TLS si vous ignorez la validation du certificat et acceptez tout cert.
D'accord avec Maks Commenter de ne pas le faire dans Prod, mais cette solution m'a sauvé du temps pour un utilitaire d'utilisation interne que je travaille. Fais attention.
équivalent vb.net est
Votre DNS résonne-t-il exactement selon le certificat sécurisé? IE:
https: //wsdl.companydomain.local ou tout ce qui est spécifié dans le certificat SSL.Je le crois. J'ai validé notre cert ici, sslshopper.com/sssl-checker.html et tout vérifié bien.
Vous demandez trop de questions à la fois. La liste de certificats de racine de confiance sur la machine locale et sur la machine serveur est une ressource soigneusement surveillée et n'est pas mise à jour souvent. Tout le monde peut créer de nouveaux certificats racines. Godaddy peut avoir créé des certificats racines supplémentaires qui ne figurent pas dans la liste de distribution Microsoft et votre certificat SSL est signé par l'un d'entre eux. Il est également possible que le certificat racine utilisé pour signer votre certificat SSL a été compromis et placé sur une liste "Ne pas faire confiance", ce qui signifie que vos certificats SSL ne sont pas dignes de confiance.
Merci tout le monde. Nous avons décidé d'utiliser une autorité plus fiable. A également noté, je concentrerai mes questions et déplacerez des questions comme celle-ci à Serverfault.