Yes. You are right. The procedure works. That was wrong is that I did
no make the server host name and the client host name match in the
certs and in the tomcat-user.xml file. Also I edited the ca.pem file a
litte bit and changed it to ca.crt and imported this file into the
browser's trusted root certificate. This is not shown in your
procedure. A couple of openssl commands have modified because of the
newer revision of openssl.
I have made all commands into BATCH file and I also added the subj
parameter into the command.
Now when you double click the BATCH file name, you do not need to key
in the domain name, you can edit in the BATCH file instead. This avoids
type error. Now I can make all of the commands finish in a shot as
long as the hostnames and the passwords and the keystore files name and
locations are defined. This may contribute to Tomcat community.
It is working with both newest Netcape and IE.
I will work on the Linux the same job and change the BATCH file into
bash script file.
Thank you !
Frank Peng.
-----Original Message-----
From: Gaël Lams <[EMAIL PROTECTED]>
To: Tomcat Users List <users@tomcat.apache.org>
Sent: Mon, 19 Jun 2006 11:01:49 +0200
Subject: Re: Tomcat SSL, after clientAuth="false" worked, how to set up
to "true"?
> The problem is that Microsoft Internet Explore and Netscape now are
serious about the Root > Trust Authorities. ...
I'm not sure what you mean by "serious about the Root Trust
Authorities" but I tested the ssl client authentication on several
computers, both inside and outside our LAN with both Internet Explorer
6 and Firefox 1.0.x and it works for me. If you don't use a trusted
certificate, the "only practical" issue (see my PS for a security
issue) is that the user trying to connect to that web site will be
prompted by a message saying that the certificate does not come from a
trusted root, and asking you whether you want to have a look at the
information provided with the certificate and whether you want to
accept it.
Regards,
Gaël
PS: when you use self-signed certificates, there is also a security
risk, i.e the risk of what it called a man-in-the-middle attack : an
attacker could send the client his own self-signed certificate which
has the same name as that in the server's self-signed certificate. The
attacker then connects to the real server himself. When the client
sends data to the server the attacker reads it and then sends it along
to the real server.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
