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