tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse
Date Thu, 17 Apr 2003 23:55:59 GMT
Bill Barker wrote:

>> >   I'm strongly -1 on passing untrusted-certs through.  It is easy
>> >   enough to add the CA to the keystore, and it is a major security hole
>> >   to
> except
>> >   forged certs.
>> "Easy enough" ??? Maybe if you compare with getting a signed certificate.
>> IMO validating the cert and accepting it is the job of whoever uses it.
>> Tomcat should just pass the cert. If cert-based auth is used, or if some
>> app just uses the cert to extract user info - this code can validate it.
>> And it should be able to validate it with it's own rules ( TrustManager
>> ).
> The most important code that uses it is Tomcat.  At the very least
> RealmBase
> and/or SSLAuthenticator would need to see that the CA is trusted. 
> Otherwise
> CLIENT-CERT authentication is useless.  In this case, I'd be only -0.

Bill - supporting unsinged certs is not very easy, so probably won't happen 
very soon, there are more important things to do :-)

SSLAuthenticator certainly needs to verify the certificate. 

>> The common case is people generating self-signed certs and connecting to
>> tomcat. Having them to also import the cert in the JVM castore is not
>> that easy - and hard to automate ( the JVM is most likely owned by root,
>> tomcat probably runs as a different user, and code to do this at runtime
>> is not trivial AFAIK ).
> I can't see that this should be that common of a use-case, since the
> application shouldn't trust a self-signed cert.  I would think that you'd
> setup you're own CA, and trust it.

Application don't have to "trust" the cert. Even a signed cert doesn't mean 
too much - it only means that you paid some money and someone eventually 
verified your identity. There are dozens of CAs in the default trust store,
and millions of certificates ( unforunately very few personal certs - since
the whole thing is so difficult ).

Application can use the info in the self-signed cert - to get info about the
user for example. It doesn't need to trust this more than what the user
would type in a form ( unless the cert is signed ), but it can be more

There are other schemes - like the PGP keys we use to sign the releases -
that don't rely on a certificate signed by a CA. Apps may use other means
to validate the cert.

>> The major security hole is using non-secure channels because SSL certs
>> are so difficult. It's bad enough that you can't connect easily do a SSL
>> connection to tomcat from java without either a FakeTrustManager and
>> hacks or a signed cert or importing the server cert on each client.
> It sort of defeats the purpose of using SSL if you're going to trust every
> server :).

SSL can provide an encrypted channel. With a normal browser you can connect
to servers using self-signed certs, I see no reason why you shouldn't be
able to do it in java. 
An intranet is a good example, where you may still want to use encription
but not to get 100s of signed certs every year.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message