httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "TAYLOR, TIM \(CONTRACTOR\)" <TIM.TAY...@DFAS.MIL>
Subject RE: [users@httpd] method POST not allowed when using SSL client certs
Date Tue, 23 Nov 2004 16:27:12 GMT
Duane,
  SSLv3/TLS behavior is specified such that if the server is configured with the SSLClientVerify
optional or required, the server shall issue a CertificateRequest message to the browser during
handshake. That CertficateRequest message not only specifies the type of certificates (e.g.
RSA-signing) but also can specify the CAs that are acceptable. If the client has no certificate
that meets the criteria of the CertificateRequest it is supposed to respond with "no_certificate"
alert. 

In other words, if they have no certificate meeting criteria of CertificateRequest they should
not have to hit cancel. 

I am guessing that you have been trying to test the situation of a user with no certificate
while actually having one available to your browser. If your users do have certificates but
not of the CA you request and trust, the situation is the same (no_certificate).

Use the following directive to control the CertificateRequest (and define trust):
SSLCACertificatPath /pathTo/hash-named/symlinksTo/acceptableCAs

regards,
tt

-----Original Message-----
From: dwinner-lists@att.net [mailto:dwinner-lists@att.net]
Sent: Monday, November 22, 2004 9:33 AM
To: users@httpd.apache.org
Subject: [users@httpd] method POST not allowed when using SSL client
certs


Hello,

My problem:
Internet Explorer cannot POST with a client certificate unless I turn on "SSLVerifyClient
optional" in the virtual server container, which is not acceptable, because then ALL users
get prompted for a cert, and not all users will have one. (apache 2.0.52)

I have an SSL virtual server with multiple containers (per Location and per Directory).
All of them require Basic SSL Authentication using username & password from my htpasswd
file.

But one of the Locations we require a user certifcate for authentication, and I am using FakeBasicAuth.

So far, so good, everything seemed to be working great. I tested this freebsd (firefox and
mozilla) and XP (firefox and IE) clients. When they all went to the main ssl page:

https://www.mydomain.com

The would be prompted for username and password and get in.

Then I tried:

https://www.mydomain.com/supersecret

which is the <Location /supersecret> that requires a client certificate and uses fakebasicauth.

Still good, I could get in from every client, and cruise around.

The I tried the final thing. One area of /supersecret allows for posting of files and documents.
I tried to post something using firefox on my freebsd laptop. No problem. I tried posting
something from firefox on XP. No problem. Then I tried posting something from IE on XP. Argh!
I got this:

Method Not Allowed
The request method POST is not allowed for the URL /supersecret/servlet/supersecretServlet

In my logfile, I see this:

SSL Re-negotiation in conjunction with POST method not supported!\nhint: try SSLOptions +OptRenegotiate


The ONLY workaround I've been able to find to resolve this reliably on all platforms is to
add a "SSLVerifyClient optional" outside of my Location directives and right in the Virtual
Server container. But then here's the problem for me: by doing that, ALL users will first
get prompted for a cert as soon as they go to the main site: https://www.mydomain.com. That's
not acceptable, because only a select number of people will have certs. I don't want non-cert
users to get prompted for a cert. They will have to know to hit 'cancel' so the username/password
dialog will come up next.


I tried adding SSLVerifyClient inside the <Location /supersecret> container, and it
did nothing. I tried to add "SSLOptions +OptRenegotiate", but that didn't do much either.
Note that in this snipet, 'SSLVerifyClient optional' is commented out in the VirtualHost context.
That's when it breaks posting from IE. But if uncomment it, then I can post from IE, but then
everybody get's prompted for a cert, even if they only want to go to the main page.

Here is a snip of my ssl.conf file:
<VirtualHost 192.168.0.14:443>
DocumentRoot "/home/myweb/"
ServerName www.mydomain.com:443
ServerAdmin me@here.com
ErrorLog /var/log/httpd-error.log
LogLevel warn
TransferLog /var/log/httpd-access.log
#SSLVerifyClient optional

<Location /supersecret>
SSLVerifyClient optional
SSLVerifyClient require
SSLVerifyDepth 10
SSLOptions +FakeBasicAuth +OptRenegotiate
AuthName MYDOMAIN-SUPERSECRET
AuthType Basic
AuthUserFile /usr/local/etc/apache2/supersecretusers
require valid-user
Order allow,deny
Allow from all
</Location>

<Location /notsosecret>
SSLVerifyClient none
AuthType Basic
AuthUserFile /usr/local/etc/apache2/httpd.passwd
AuthName MYDOMAIN
require valid-user
</Location>



I am running:
FreeBSD 4.9-RELEASE-p12
apache-2.0.52_3
mod_jk2-apache2-2.0.2
jakarta-tomcat-5.0.29

The /supersecret area with the post is actualy java servlets, being process by Tomcat via
mod_jk2, but I really don't think the Tomcat servlets have anything to do with this at all,
but if you can prove me wrong, I'm all ears.

I'm ready to put my head through a wall over this....I'm so close but no cigar yet.

Thanks for any info, advice, wisdom, etc., etc.

Duane
dwinner-lists@att.net

---------------------------------------------------------------------
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@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


---------------------------------------------------------------------
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@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message