netstat dit 443 est ouverte, mais je ne peux pas vous y connecter avec telnet .. pourquoi?

Question

Je l'ai construit un serveur WCF auto hébergé, en utilisant wsHttpBinding. Je suis en cours d'exécution Win 2003 Server R2 SP2.

Si je configure à écouter sur http://localhost:443/MyService, tout fonctionne très bien. Je peux me connecter à http://localhost:443/MyService avec Internet Explorer, et je reçois le message standard "Bad Request"

Maintenant, si je tente de passer en HTTPS, je suis témoin d'un étrange phénomène.

Voici ce que je l'ai fait:

1. J'ai changé mon fichier de configuration WCF de http://localhost à https://localhost et de Security=None à Security=Transport (comme expliqué dans de nombreux tutoriels WCF)

2. Je suis inscrit mon port HTTP comme ceci:

   httpcfg delete ssl -i 0.0.0.0:443
   
   httpcfg set ssl -i 0.0.0.0:443 -h ea2e450ef9d4...
   

Notez que le certificat que je l'ai utilisé est un « vrai certificat » (à savoir émis par une autorité de certification, à savoir Comodo confiance). Le serveur répond à un ping sur les NS mentionnées dans le certificat.

Maintenant, le délai d'attente de volonté suivante:

Microsoft Telnet> open localhost 443

Voici la sortie de netstat (PID '4' est le processus 'Système'):

netstat -nao

  Proto  Local Adress         Remote Adress          State           Pid
  TCP    0.0.0.0:443          0.0.0.0:0              Listening       4

Et voici une capture d'écran de TCPView capturé quand je a rendu les commande d'ouverture en telnet:

texte alt http://img26.imageshack.us/img26/3376/tcpview2si6 .jpg

Je suis un peu perplexe. Pour moi, si netstat dit le serveur est à l'écoute sur 443, la connexion telnet à 443 ne doit pas délai d'attente, et je doit avoir au moins une invite blanche, me attendant de taper des trucs crypté:)

Jusqu'à présent, je l'ai essayé à:

1. Recréer toutes les étapes à partir de zéro en suivant exactement le tutoriel MSDN
2. port utilisé 10443 au lieu de 443
3. Désactiver le pare-feu
4. Utiliser un certificat auto-signé

Je ne sais pas quoi essayer après .. des idées?

Answer 1

Le client telnet ne va pas savoir envoyer une demande correctement construite pour lancer une poignée de main https, donc j'imagine que le serveur sécurisé ssl attend juste plus de données.

Le client telnet ne va certainement pas savoir quoi faire avec la réponse d'un serveur sécurisé ssl (il ne va certainement pas pour vous demander des données à envoyer le long). La communication ne peut se produire une fois que la poignée de main https est terminée.

Vous devez utiliser un client qui sait comment faire une poignée de main. Le binaire OpenSSL peut le faire hors de la boîte.

Answer 2

Telnet ne peut pas être utilisé pour communiquer avec des bandes encrited.

Commander ce Microsfot note. Il dit "NOTE: Cet exemple suppose que le serveur Web est configuré pour utiliser le port HTTP par défaut (TCP 80) Si le serveur Web est à l'écoute sur un port différent, remplacez ce numéro de port dans la première ligne de l'exemple. . en outre, cet exemple ne, parce que le client telnet fonctionne pas correctement sur une connexion HTTPS / SSL (TCP 443, par défaut) ne peut pas négocier le cryptage nécessaire des commandes pour établir la session SSL. Bien qu'une connexion initiale est possible sur le HTTPS / SSL port, aucune donnée n'est retourné lorsque vous émettez une requête GET. "

Mise à jour: checkout cette autre note COMMENT à: déterminer si SSL connectivité ne fonctionne pas sur le serveur Web ou sur un périphérique intermédiaire

Answer 3

Comme dit FerrariB, telnet ne fonctionne pas les négociations nécessaires pour ouvrir une connexion SSL. Telnet ne sait rien sur les certificats, ni cryptage. Ainsi, vous êtes assuré de ne pas être en mesure de communiquer avec le port HTTPS 443 via telnet. Vous devrez trouver une autre façon de faire ce que vous essayez de faire.

Consultez la page Wikipedia sur TLS par exemple, où il est dit directement:

  

Si l'une des étapes ci-dessus échoue, la poignée de main TLS   échoue, et la connexion ne se crée pas.

Ceci est précisément ce que vous voyez en essayant d'utiliser telnet pour communiquer avec un point de terminaison SSL.

Answer 4

1. dans l'invite de commande: netstat -nao |find "443" les dernières colonnes montrent un nombre: pic no.1

2. Maintenant, ouvrez la tâche numéro de résultat manager.find en 1ère section dans la colonne pid (si pid n'a pas été activé, sélectionnez-le dans l'onglet Vue) nom du programme montrer le programme qui utilise le port.

3. désactiver le programme qui utilise le port / dans mon cas je me suis arrêté à partir des services