Article delegate-en/197 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
search
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
[Reference:<_A196@delegate-en.ML_>]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: Still not able to get working the client authorization in SSL proxy
03 Jan 1999 08:51:27 GMT ysato@etl.go.jp (Yutaka Sato)


On 01/03/99(16:48) you Horia Georgescu <pyqaabdyi-rn3efjo2yhtr.ml@ml.delegate.org> wrote
in <_A196@delegate-en.ML_>
 |Based on the previously exchanged messages, I've been able to achieve 
 |so far:
 |- compile delegated on a Linux PC and test it as a regular http proxy
 |- compile SSLeay and sslway, generate the server certificates based on
 |http://wall.etl.go.jp/mail-lists/delegate-en/44, run delegated as a
 |SSL proxy and establish an non authenticated SSL connection between
 |my browser (MSIE) and delegated

You mean you ran it with "FCL=sslway -ac" without "-client_auth" to
be connected with the client successfully?

 |- running "delegated -ac -client_auth" my browser's request was rejected
 |not having the appropriate certificate

And something wrong occurred when added "-client_auth"?

 |What I was unable to achieve was to add a client certificate to my
 |browser generated by using only SSLeay (actually using CA.sh, a shell
 |wrapper for ssleay, included in the distribution)
 |I've only been able to get those browser certificates installed in both 
 |MSIE and NS by using the information provided in the following
 |documents:
 |http://www.drh-consultancy.demon.co.uk/pkcs12faq.html 
 |http://www.drh-consultancy.demon.co.uk/ca-fix.html
 |Which documents basically say that there is something wrong with the 
 |way SSLeay creates the certificates and provide a fix which works.

Sorry but I don't know anything about how to attach client's side
certificate to MSIE nor NS.
What I can test is running one more DeleGate which are a gateway
from HTTP client to HTTPS server with its own client certificate,
forwarding its request to another DeleGate of gateway from HTTPS
to HTTP, like this:

  #{server,client}-{key,cert}.pem is current directory.

  % delegated -P8080 -v              MOUNT="/* https://localhost:8443/*"
                                     FSV="sslway"
  % delegated -P8443 -v SERVER=https MOUNT="/* http://www/*"
                                     FCL="sslway -client_auth"

The HTTPS/HTTP-gw-DeleGate on the port 8080 produces a log like
...
01/03 17:40:09.61 [17793] 1+0: #### execFilter[FCL] sslway -client_auth
## SSLway[17795](localhost) start
## SSLway[17795](localhost) accepted
## SSLway[17795](localhost) client's cert. = **subject<</C=JP/ST=Ibaraki/L=Tsukuba/O=Electrotechnical Laboratory/OU=Computer Science Division/CN=Yutaka Sato/Email=ysato@etl.go.jp>> **issuer<</C=JP/ST=Ibaraki/L=Tsukuba/O=Electrotechnical Laboratory/OU=Computer Science Division/CN=Yutaka Sato/Email=ysato@etl.go.jp>>
...

and the HTTP/HTTPS-gw-DeleGate on the port 8443 produces

01/03 17:40:09.70 [17794] 1+1: #### execFilter[FSV] sslway
01/03 17:40:09.71 [17791] 1+1: HTTP => (localhost:8443) GET / HTTP/1.0^M
## SSLway[17796](delegate-rips.etl.go.jp) start
## SSLway[17796](delegate-rips.etl.go.jp) connected
## SSLway[17796](delegate-rips.etl.go.jp) server's cert. = **subject<</C=JP/ST=Ibaraki/L=Tsukuba/O=Electrotechnical Laboratory/OU=Computer Science Division/CN=Yutaka Sato/Email=ysato@etl.go.jp>> **issuer<</C=JP/ST=Ibaraki/L=Tsukuba/O=Electrotechnical Laboratory/OU=Computer Science Division/CN=Yutaka Sato/Email=ysato@etl.go.jp>>


 |Getting back to delegated and using my newly generated cacert.pem and
 |cakey.pem certificates I'm unable to get the authentication working
 |and I'm back to the original behavior, when each time the client
 |initiates a request, on the proxy side I'm prompted for a password
 |(presumably because the cakey.pem is not understood properly).

Possibly your problem has something to do with the allowed key-length
(?  I'm not sure) of SSL.  What is allowed in the US and Canada is
longer than that in other countries...

Cheers,
Yutaka
--
Yutaka Sato <ysato@etl.go.jp> http://www.etl.go.jp/~ysato/   @ @ 
Computer Science Division, Electrotechnical Laboratory      ( - )
1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan            _<   >_

  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
@_@V