-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
