tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Арсений Зинченко <setev...@gmail.com>
Subject Re: Tomcat && SSL: two issues
Date Fri, 31 Jan 2014 15:40:27 GMT
Hi, Chris.

So - 5.5 yes, very old - but we still use it. I hope - will update some
day...

> I can see that you have clientAuth="want"... what happens if the client
declines to send a certificate? // if it's connection not to restricted
area - Tomcat will open it, if to /some/page - will decline with
"handshake_error" or something like it, I don't remeber all error from last
few days :D

> top-level certificate that is used to sign the individual client
certificates. That way, you don't have to bother storing all of the
individual client certificates

Yes, thanks - I know, and we have one "top-level cert" for server. But here
some difficults in our... "organisation" - so we decide for users use
self-signed cert.

> That looks like a LDAP username. Does LDAP have anything to do with this?

No - this is just usual "username" which taken from user's cert and
compared with entry in database.

And at least - about Firefox issue. TThe problem was due to different
(yes... I don't know it till today) keystore types. Only my own cert was
created as PCKS12. Other used .JKS then convert it .p12 and something like
this...
After we re-generate cert exactly in .p12 - problem was solved.

So for now only with Chrome browser.

P.S. Sorry for errors\typos and thanks for tips :-)



2014-01-31 Christopher Schultz <chris@christopherschultz.net>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Арсений,
>
> On 1/31/14, 5:15 AM, Арсений Зинченко wrote:
> > We have Tomcat with two factor authentication when access to
> > /some/pagerequested.
> >
> > Auth configured with JDBCRealm & Oracle database:
> >
> > <Realm  className="org.apache.catalina.realm.JDBCRealm"
> > driverName="oracle.jdbc.driver.OracleDriver" ...
> >
> > SSL-connector:
> >
> > <Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150"
> > minSpareThreads="25" maxSpareThreads="75" enableLookups="false"
> > disableUploadTimeout="true" acceptCount="100" scheme="https"
> > secure="true" clientAuth="want" sslProtocol="TLS"
> > keystoreFile="/home/keystore.jks" keyAlias="keystore"
> > keystorePass="password" truststoreFile="/home/trustcacerts.jks"
> > truststorePass="password" />
>
> It's nice when people say "two-factor authentication" and actually use
> two different factors. Yay, you!
>
> (I can see that you have clientAuth="want"... what happens if the
> client declines to send a certificate?)
>
> > Auth requring via web.xml:
> >
> > <security-constraint> <web-resource-collection>
> > <web-resource-name>*</web-resource-name>
> > <url-pattern>/some/*</url-pattern> </web-resource-collection>
> > <auth-constraint> <role-name>cert</role-name> </auth-constraint>
> > <user-data-constraint>
> > <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> > </user-data-constraint> </security-constraint> <login-config>
> > <auth-method>CLIENT-CERT</auth-method> </login-config>
> > <security-role> <role-name>cert</role-name> </security-role>
>
> Aah, okay: Tomcat will refuse the request if it is for a protected
> web-resource-collection.
>
> > Client's cert created with keytool:
> >
> > $ keytool -genkey -alias somealias -keystore somekey.p12 -storetype
> > PKCS12 $ keytool -export -alias somealias -file somefile.cer
> > -keystore somekey.p12 -storetype PKCS12
> >
> > somefile.cer - imported to Tomcat's trustcacerts.jks and
> > somekey.p12 - to client's browsers.
>
> Ok. Note that if you want to do 2-factor properly, you should have
> everyone sharing the second factor (the client certificate).
>
> Also, this is typically done by generating a top-level certificate
> that is used to sign the individual client certificates. That way, you
> don't have to bother storing all of the individual client
> certificates... you just store the parent cert and validate all
> clients against that one. It makes management much easier.
>
> > User's present in trustcacerts.jks like:
> >
> > somealias, 30-Jan-2014, trustedCertEntry, Certificate fingerprint
> > (MD5): 60:A1:CE:35:2D:5E:01:22:65:A7:26:19:9E:D6:F3:74
> >
> > And present in Oracle database, like:
> >
> > USER_NAME: CN=someuser, OU=Unknown, O=Unknown, L=Unknown, ST=Kiev,
> > C=UA
> >
> > ROLE_NAME: cert
>
> That looks like a LDAP username. Does LDAP have anything to do with this?
>
> > (not exactly same - but about it)
> >
> > Tomcat 5.5.23, running on SuSE 10. Users - on Windows7, Firefox
> > 26.0 and Chrome 32.0.1700.76 m.
>
> You need to upgrade. Tomcat 5.5 is no longer supported.
>
> > So - we have two issues.
> >
> > 1) Some (!) of users when connecting with Chrome got error:
> >
> > Error code: ERR_SSL_PROTOCOL_ERROR
> >
> > In Catalina-' log:
> >
> > WARNING: Exception getting SSL attributes
> > javax.net.ssl.SSLHandshakeException: renegotiation is not allowed
> >
> > Attempts add lines allowUnsafeLegacyRenegotiation="true" and
> > allowLegacyHelloMessages="true" doesn't give results (was added to
> > Connector or -D(option) to CATALINA_OPTS).
> >
> > What else can be done? All googled tips says only about this two
> > parameters.
>
> Hmm.
>
> > 2) Using Firefox - from some machines give error 403, from others
> > - normal auth. It's look like (from Tomcat auth-log):
> >
> > 10.***.**.132 - CN=someuser, OU=**, O=company, L=Kiev, ST=Ukraine,
> > C=UA [30/Jan/2014:16:50:29 +0000] "GET /some/page HTTP/1.1" 403
> > 1108 // Got auth failed;
>
> What about the client certificate that was presented by the browser?
> You are only showing the "Oracle" username in the above, right?
>
> > 10.***.***.132 - CN=someanotheruser, OU=**, O=company, L=Kiev,
> > ST=Unknown, C=UA [30/Jan/2014:16:17:29 +0000] "GET /some/page
> > HTTP/1.1" 200 81 // Normal result.
> >
> > I only think about may be some difference in browser's configs...
> > But which exactly? Or - something another?
>
> Do you know that there are any differences in browser configuration,
> or are you just speculating? We certainly can't tell you what those
> differences might be... have you tried to identify what they are?
>
> > Unfortunatelly - we haven't access to tcpdump and ssldump now, so
> > I can't check for details.
>
> Hm. Your browser ought to tell you which client certificate was
> presented to the server. You can also instrument the server to have it
> print debug logs for what certificate has been sent, what username is
> being used, etc.
>
> Just to be sure: is Oracle being used *at all* here? All I saw was
> configuration for client-certificates, using the truststore as the
> authentication data-store.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJS676IAAoJEBzwKT+lPKRYMdYP/0BORzeU8DjxT1gC4SvyTUhG
> KHQHZEay+waUpkJgeaexPtlWS0dvJMBJOyA6RnAlpQWR4SE91pmIQBYHKhoh0Gkg
> Im6RTfuKopS83ik8awcxV6GsDtdOKRi4tDFqcKRYy6ILspkqZxyNmcB0HL5FRVX/
> v8cVrHVZldZ5/2FhEWRXhMMQan0f0SgmvBpTuIjFk5pxXeLoYAzk5zT3o1aiYq/+
> T9kW2JWs10lp1tul7hURWrETSgzLaslMsoXpnhate8Vx6fATN9W2k50qCzy4K41L
> IH1+I99RQoq9m6D1HZ7/4b1+elDOcfohObdnLPbb/j9jLXCxJvEnUZKr71CDRg+l
> oKIDQmxGMl9QIr5BuoaknAj7kRDKLSW2u4R8B0qCuLL9VBdsc5GdpAVufy21S8qE
> 4r7NGIajtVjkBa3tBues+EEd92lqY3Yvy9FkUP/dnw/Rs2OiWNYZDlobEljcmSWu
> DrYyt61yg6vmurBoEoCcyHkfpsgwPNULf2R9zf9p+ejiOyoL0rq1unQEEZQ71Vty
> t081LHqCNU+2Se9spiAR4QI6kciA7mFmUXLUTx8XxAM0Nnr5bBzYbWp2s7n4Esad
> D4c6MCN1C8aIYSL1/P0iCYzCVtoBodCTVjCvt3bMFbkVAcDDR4GH8bmrQjkqTYnB
> btBlZ40QjhUg910MkhDd
> =zFOC
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message