Summary: | Wrong HTTP code for failed CLIENT-CERT authentication | ||
---|---|---|---|
Product: | Tomcat 5 | Reporter: | Markus <axianx> |
Component: | Connector:Coyote | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 5.0.28 | ||
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | other |
Description
Markus
2006-02-07 16:54:17 UTC
I understand your point, and have located the relevant code: org.apache.catalina.authenticator.SSLAuthenticator line 139. However, I'm not convinced the behavior you're asking for is correct: does the RFC say 401 (instead of 400, or more generally 4xx) is *required* for the case where a request has no certificates at all? If you could point out the relevant spec part that makes this clear, we can change the code. A request that has no certificitates at all is not necessarily a bad request. When establishing a ssl connection, the server sends its certificate to the client. This includes the certificates of the CAs which are trusted by the server. The client only answers with certificates that are signed by one of the trusted CAs (directly or chained). When the client sends no certificate, it means that he has no matching certificate. This is an authentication issue and has nothing to do with the request syntax. RFC 2616 says for 400 Bad Request: "The request could not be understood by the server due to malformed syntax." As I stated before, a request that has no certificates attached (because there were none in the browser keystore) is not malformed. This behavior is specified in the SSL RFC 2264 "7.4.6. Client certificate (...) If no suitable certificate is available, the client should send a certificate message containing no certificates. (...)" Point taken. I have fixed this in trunk and proposed it for 6.0.x and 5.5.x This has been fixed in 6.0.x and will be included in 6.0.19 onwards. This has been fixed in 5.5.x and will be included in 5.5.28 onwards. |