Mistery of TLS with CA file (Error: operation not supported on socket)

[Alexandru]

Hi,

if I want my Tcl application to communicate with my server through TLS (much like a web browser), I only need to give the -cafile option and ignore the -certfile option.

So I issue:

package require http
package require tls
::http::register https 443 [list ::tls::socket -request 1 -require 1 -ssl2 0 -ssl3 0 -tls1 1 -cafile VeriSignClass3SecureServerCA-G3.crt]

where VeriSignClass3SecureServerCA-G3.crt is the same certificate I copied from my browser.

This certificate is used by the web browser to establish the TLS connection to my web page.

Then if I do:

::http::geturl https://www.domain.de

I get the eror:

error reading "sock560": operation not supported on socket

If I deactivate the -require option, same code works!

This is where I get stuck: I'm using the same certificate as my browser to communicate with the same server as my browser. Why is this happening?

Thank you!

[pal...@yahoo.com]

What platform? And how exactly did you copy the certificate from the browser? Speculating, two possibilities come to mind - the format of the .crt is not understood by the tls package, or the server cert is signed by a intermediary and the entire chain is not included in the file (actually, I don't know how tls will treat that case).

Is the server publicly accessible?

/Ashok

[Alexandru]

Am Donnerstag, 2. Juli 2015 06:24:15 UTC+2 schrieb pal...@yahoo.com:
> What platform? And how exactly did you copy the certificate from the browser? Speculating, two possibilities come to mind - the format of the .crt is not understood by the tls package, or the server cert is signed by a intermediary and the entire chain is not included in the file (actually, I don't know how tls will treat that case).
>
> Is the server publicly accessible?
>
> /Ashok

Hi Ashok,

The platform is Windows but I would like to have the implementation platform independent.

The server needs indeed an intermediary certificate, which is placed in another file.

In Firefox, I click on the small lock icon on the left of the URL (yes, the server is public) and then show details of the certificate. I can then select one of the certificates in the Chain and export it (save to disk)

The format of the cert is PEM.

[Harald Oehlmann]

What Alex wants to acheve is to avoid a man in the middle attack and be sure that the right certificate is used.

Isn't it possible to check this on other means, e.g. read out the certificate properties (CNAME etc) and check them ?

In the TWAPI interface, I have seen those possibilities.
Isn't this possible with the TLS package too ?

-Harald

[Alexandru]

I did another test with www.google.de:

::http::register https 443 [list ::tls::socket -request 1 -require 1 -ssl2 0 -ssl3 0 -tls1 1 -cafile GoogleInternetAuthorityG2.crt]

::http::geturl https://www.google.de

Same error: error reading "sock560": operation not supported on socket

Actually it does not matter, what CA file I specify. I can even omit the cafile option. I still get the same error.

Somehow it cannot be! This should be simple!

What does this error mean anyway? Error reading, operation not supported? So reading is not supported?

[pal...@yahoo.com]

Two things you might want to look at -

- first, GoogleInternetAuthority G2 is not a root CA. It is an intermediate CA whose certificate is signed by GeoTrust (I think) so the GeoTrust root certificate needs to be provided in the cafile as well.

- second, I'm not sure what format you have saved the .crt file and the encoding. Make sure it is what tls/openssl expects. A quick look at the docs didn't help and I don't know openssl well enough to know so you'll have to dig a bit.

Also, to eliminate Tcl and TLS from the picture, try using the openssl command line client with the same -cafile option. It will print out debug information that might help.

/Ashok

[pal...@yahoo.com]

OK, here's what you need to do. Download the current root certs from http://curl.haxx.se/ca/cacert.pem and save it (to cacert.pem or whatever)
and specify that as your -cafile.

Verified with tls 1.6.6:

% ::http::register https 443 [list ::tls::socket -request 1 -require 1 -ssl2 0 -ssl3 0 -tls1 1 -cafile cacert.pem]
443 {::tls::socket -request 1 -require 1 -ssl2 0 -ssl3 0 -tls1 1 -cafile cacert.pem}
% set tok [http::geturl https://www.google.de]
::http::4
% http::status $tok
ok
% http::cleanup $tok

/Ashok

[Will Duquette]

On Thursday, July 2, 2015 at 9:35:04 AM UTC-7, pal...@yahoo.com wrote:
> OK, here's what you need to do. Download the current root certs from http://curl.haxx.se/ca/cacert.pem and save it (to cacert.pem or whatever)
> and specify that as your -cafile.
>
> Verified with tls 1.6.6:
>
> % ::http::register https 443 [list ::tls::socket -request 1 -require 1 -ssl2 0 -ssl3 0 -tls1 1 -cafile cacert.pem]
> 443 {::tls::socket -request 1 -require 1 -ssl2 0 -ssl3 0 -tls1 1 -cafile cacert.pem}
> % set tok [http::geturl https://www.google.de]
> ::http::4
> % http::status $tok
> ok
> % http::cleanup $tok
>
> /Ashok
>

I have a related question, because in this area I am an Utter Newbie. I gather that to connect to a TclHTTPD server using TLS, the server needs to specify a certificate in some way. I see -cafile and -certfile options. What's the difference between a -cafile and -certfile?

I'm guessing that I need a -certfile on the server. How does one create a self-signed certificate? Easily?

Thanks!

[Will Duquette]

Or, can I simply do the above?

[JMar...@comcast.net]

Ashok,

Thanks for the example. I ran this using tls 1.6.4 on Windows 7 using Tcl 8.6.04 32 bit and it failed. I updated tls to 1.6.6 and it worked!

[HeadsU...@yahoo.com]

To generate a self-signed certificate for TclHttpd.

If on Linux change directory to the where the "certs" directory for TclHttpd is and then type the following:

openssl req -new -x509 -days 365 -nodes -out server.pem -keyout skey.pem

If on Windows download Openssl package from:

http://gnuwin32.sourceforge.net/packages/openssl.htm

and in the "certs directory type

C:\"Program Files (x86)"\GnuWin32\bin\openssl.exe req -config "C:\Program Files (x86)\GnuWin32\share\openssl.cnf" -new -x509 -days 365 -nodes -out server.pem -keyout skey.pem

From the FAQ in the WebSockitme Starkit. http://headsup.webs.com

Kind Regards

Jeff

[pal...@yahoo.com]

The above is for the client side.

To create a self-signed cert, see https://www.madboa.com/geek/openssl/#cert-self or http://www.zytrax.com/tech/survival/ssl.html#self or for very detailed examples https://pki-tutorial.readthedocs.org/en/latest/index.html

THe -certfile is needed on the server side and should contain the server's certificate. In your scenario, (self-signed cert) I *think* it should suffice to provide the same certificate (minus the private key) as -cafile on the client side. Note that downloading the trusted roots file from curl.hax.se will not help since your self-signed cert is not signed by one of those trusted roots.

/Ashok

[Alexandru]

Am Donnerstag, 2. Juli 2015 18:35:04 UTC+2 schrieb pal...@yahoo.com:
> OK, here's what you need to do. Download the current root certs from http://curl.haxx.se/ca/cacert.pem and save it (to cacert.pem or whatever)
> and specify that as your -cafile.
>
> Verified with tls 1.6.6:
>
> % ::http::register https 443 [list ::tls::socket -request 1 -require 1 -ssl2 0 -ssl3 0 -tls1 1 -cafile cacert.pem]
> 443 {::tls::socket -request 1 -require 1 -ssl2 0 -ssl3 0 -tls1 1 -cafile cacert.pem}
> % set tok [http::geturl https://www.google.de]
> ::http::4
> % http::status $tok
> ok
> % http::cleanup $tok
>
> /Ashok

Problem solved!

At first I have saved the CA file provided by Ashok and connected successfully to google.de.

Then I tried to connect to my server and didn't worked (same error: operation not supported).

Then I followed Ashok's advice and tried to connect through openssl instead of Tcl's tls package:

openssl s_client -connect www.mydomain.de:443 -CAfile CA.crt

That helped a lot, because openssl has much more details in the output. The output was:

CONNECTED(000001B0)
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=DE/ST=Baden-W\xC3\xBCrttemberg/L=Stuttgart/...
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

The verify error:num=20:unable to get local issuer certificate is issued when a certificate in the chain is missing. So I have searched the CA file and identified the missing certificate, which I could copy from FireFox and paste into the CA file.

Then the connection through Tcl TLS package also worked like a charm:

::http::register https 443 [list ::tls::socket -request 1 -require 1 -ssl2 0 -ssl3 0 -tls1 1 -cafile CA.crt]
::http::geturl https://www.mydomain.de

Thank you very much for your help!

[Harald Oehlmann]

Alexandru,

I would appreciate, if you could put all this information on the wiki.
I always try to kepp the magic opened by Ashok there so it is not lost.

Thank you,
Harald

[Alexandru]

Following Harald's advice, I have summarized the information in the wiki:

http://wiki.tcl.tk/2630 (scroll down to "Use of CA certificates")

[Will Duquette]

Thanks!