If I get that right your solution would provide the client certificate to the backend server in the form of a header variable. Is that correct?
yes, that's correct
Therefor the client certificate would not be available as part of a normal, standard conform SSL handshake but be essentially be copied in the normal http data part. I would then need to change my backend server's code to look for the certificate at a different place?
exactly
Don't get me wrong, if my developers here tell me that they can change our application server in this way, I'd be more than happy to use that solution.. I just don't see how the server could validate the certificate in this scenario as he does not have access to the client but only to the reverse proxy.
the backend *code* has a access to the client certificate. is it your backend *webserver* or is it your backend *code* that is handling the validation of the client certificate ? what i don't understand at this point, is why you want the validating done at the backend at all, when you could have all this done at the frontend. is it really nesecary to do the webserver validation on the backend. is it actually possible to bypass the apache frontend and therefore access the backend directly (which sounds slightly insecurish) (the solution i described, we had https at the frontend and http at the backend)
Let me ask you this question: If I'd provide the client certificate to the backend application server during the normal SSL handshake between apache and application server - let's say I would copy it to the üplace where the apache certificate would normally be -, that surely would lead to a mismatch between the DN of the certificate and the hostname of the server presenting the certificate, would it not?
i don't know. but it does not sound possible. ./allan --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|