netstat says 443 is open, but I cannot connect to it with telnet .. why?

Question

I've built a self hosted wcf server, using wsHttpBinding. I'm running Win 2003 server R2 SP2.

If I configure it to listen on http://localhost:443/MyService, everything works fine. I can connect to http://localhost:443/MyService with Internet Explorer, and I get the standard "Bad Request" message

Now, if I try to switch to HTTPS, I'm witnessing a strange phenomenon.

Here's what I've done :

1. I've changed my wcf config file from http://localhost to https://localhost and from Security=None to Security=Transport (as explained in numerous wcf tutorials)

2. I've registered my HTTP port like this :

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

Note that the certificate I've used is a "real certificate" (i.e. issued by a trusted CA, namely Comodo). The server responds to ping on the NS mentioned in the certificate.

Now, the following will timeout :

Microsoft Telnet> open localhost 443

Here's the output from netstat (The Pid '4' is the 'System' process):

netstat -nao

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

And here's a screenshot from TCPView captured when I issued the open command in telnet :

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

I'm a bit puzzled. To me, if netstat says the server is listening on 443, the telnet connection to 443 shouldn't timeout, and I should have at least a blank prompt, expecting me to type some encrypted stuff :)

So far I've tried to :

1. Redo all the steps from scratch following exactly the MSDN tutorial
2. Used port 10443 instead of 443
3. Disable the firewall
4. Use a self signed certificate

I don't know what to try next .. any ideas?

Answer 1

The telnet client is not going to know to send a properly constructed request to initiate an https handshake, so I imagine the ssl secured server is just waiting for more data.

The telnet client is certainly not going to know what to do with the response from a ssl secured server (it's certainly not going to prompt you for data to send along). Communication can only happen once the https handshake has completed.

You need to use a client that knows how to do a handshake. The openssl binary can do this out of the box.