WinINet Error Message ERROR_INTERNET_SECURITY_CHANNEL_ERROR
Information/Programming :
2009. 6. 12. 13:43
Error messages in computer(or software) are important because they provide information about what is being done incorrectly. Think about the error messages you get in Microsoft Windows. Almost all the time, you have no idea what it means. In worse cases you only get the error code(simply a hex number). Such error messages fail to deliver adequate information to us for correcting our incorrect usage of the computer(or software). Sometimes, it's not even a bit better than having a error message at all. You're unable to interact with the computer... It's just like talking to a robot that says the same thing over and over.
If error messages fail to provide proper information to us for fixing a problem, how are we supposed to fix the problem??? We have to find the problem for ourselves in a Brute Force(sometimes worse and sometimes slightly better - because we may get clues from other problems) manner. This is a very time consuming and unpleasant task. In Korea we use the term "sap-jill" which literally means digging the ground(inefficient and maybe meaningless job) for such tasks. Anyway, thanks to the Internet and Google(and all the other search engines). If you are really lucky, somebody might have encountered your problem before you and might have posted a solution to your unknown problem.
Now to the main subject...
I was working with WinINet at work. And I was caught up in a problem where I get a ERROR_INTERNET_SECURITY_CHANNEL_ERROR whenever I make a request over SSL(which is now TLS). The explanation of the error in MSDN is as follows...
So??? I looked for solutions related to the error. Not much help. Most of the information related to that error message had something to do with SSL certificates. Therefore, I also thought that was my problem. After several days of "sap-jill", I had a weird feeling that I was looking at the wrong thing... But, still I had no clue what else to look about. And then... yesterday, I finally found a post suggesting that I use a program called fiddler2. It's a proxy that sits between your http(s) client and the http servers that logs every request and response. I used that to find out what my http client's problem was. As soon as I ran my program with fiddler2 running, fiddler2 gave me an error message that finally gave me an idea what my problem was. I don't exactly remember what the message was, but it had something to do with the host name. Some more observations led me to a conclusion that there was a problem in establishing a connection to the server. More specifically, using the wrong port number. As I was debugging my code, I found out that in the line where I call the WinINet function InternetConnect(), I pass a zero(0) as a parameter that indicates the port number I am using. Of course the zero was not hard coded, and it was retreiving the value from another object which abstracts the information of the URL. The funny thing is that if the port number is not specified in the URL explicitly, the method used to retreived the port number for the URL returns zero. While it is well known that certain protocols use predefined port numbers, I think this is a bad implementation. But, I discussed it with my boss, and he said that its behavior should kept the way it is now because it might cause other problems if we fix it(corporate secret--just being careful). Anyway, I had to make a conditional statement to check what kind of protocol it's using and pass the appropriate port number.
How was I supposed to know that from getting...
System Error 12157(0x2F7D): ERROR_INTERNET_SECURITY_CHANNEL_ERROR
So, to my conclusion... This is what I have been trying to tell all the people who run into the error message ERROR_INTERNET_SECURITY_CHANNEL_ERROR and nothing makes sense. You might want to check if the port number is correctly passed into the InternetConnect() function. Actually, I found nothing about SSL libraries related to this error.
If error messages fail to provide proper information to us for fixing a problem, how are we supposed to fix the problem??? We have to find the problem for ourselves in a Brute Force(sometimes worse and sometimes slightly better - because we may get clues from other problems) manner. This is a very time consuming and unpleasant task. In Korea we use the term "sap-jill" which literally means digging the ground(inefficient and maybe meaningless job) for such tasks. Anyway, thanks to the Internet and Google(and all the other search engines). If you are really lucky, somebody might have encountered your problem before you and might have posted a solution to your unknown problem.
Now to the main subject...
I was working with WinINet at work. And I was caught up in a problem where I get a ERROR_INTERNET_SECURITY_CHANNEL_ERROR whenever I make a request over SSL(which is now TLS). The explanation of the error in MSDN is as follows...
The application experienced an internal error loading the SSL libraries.
So??? I looked for solutions related to the error. Not much help. Most of the information related to that error message had something to do with SSL certificates. Therefore, I also thought that was my problem. After several days of "sap-jill", I had a weird feeling that I was looking at the wrong thing... But, still I had no clue what else to look about. And then... yesterday, I finally found a post suggesting that I use a program called fiddler2. It's a proxy that sits between your http(s) client and the http servers that logs every request and response. I used that to find out what my http client's problem was. As soon as I ran my program with fiddler2 running, fiddler2 gave me an error message that finally gave me an idea what my problem was. I don't exactly remember what the message was, but it had something to do with the host name. Some more observations led me to a conclusion that there was a problem in establishing a connection to the server. More specifically, using the wrong port number. As I was debugging my code, I found out that in the line where I call the WinINet function InternetConnect(), I pass a zero(0) as a parameter that indicates the port number I am using. Of course the zero was not hard coded, and it was retreiving the value from another object which abstracts the information of the URL. The funny thing is that if the port number is not specified in the URL explicitly, the method used to retreived the port number for the URL returns zero. While it is well known that certain protocols use predefined port numbers, I think this is a bad implementation. But, I discussed it with my boss, and he said that its behavior should kept the way it is now because it might cause other problems if we fix it(corporate secret--just being careful). Anyway, I had to make a conditional statement to check what kind of protocol it's using and pass the appropriate port number.
How was I supposed to know that from getting...
System Error 12157(0x2F7D): ERROR_INTERNET_SECURITY_CHANNEL_ERROR
with the description
"application experienced an internal error loading the SSL libraries."
Orz <- Do you see my frustration?
Orz <- Do you see my frustration?
So, to my conclusion... This is what I have been trying to tell all the people who run into the error message ERROR_INTERNET_SECURITY_CHANNEL_ERROR and nothing makes sense. You might want to check if the port number is correctly passed into the InternetConnect() function. Actually, I found nothing about SSL libraries related to this error.
How ABSURD !!!
'Information > Programming' 카테고리의 다른 글
The Mythical Man-Month Chapter 2 (1) | 2009.10.08 |
---|---|
심심해서 테트리스를 짜보다... (13) | 2009.09.17 |
The Mythical Man-Month Chapter 1 (2) | 2009.09.10 |
Something worth knowing about HttpEndRequest (0) | 2009.09.09 |
Using HttpSendRequestEx for large POST requests (3) | 2009.06.27 |
Basics of Compilers... (5) | 2009.02.12 |
Building curl 17.19.3 with OpenSSL and zlib on MSVC (2) | 2009.02.03 |
Building openSSL 0.9.8j on Windows (2) | 2009.02.02 |
Working with WebCore in Webkit... (4) | 2009.01.13 |
Making your code more portable by avoiding inlining??? (6) | 2008.11.23 |