Re: IE 6 and apache+mod_ssl+mod_jk+tomcat HTTPS problem: "Navigation Canceled"
> On some frames of web pages we have the message: "Navigation Canceled" = > and IE says that the page has secured and unsecured elements. > > This pages are JSP pages from an front Apache Linux server that forward = > requests with AJP (mod_jk, AJP 1.3) to another TOMCAT (4.0.3) Linux = > server. > > In simple HTTP protocol there is no problem, Apache+AJP+Tomcat works = > fine. This sounds to me like someone is redirecting HTTPS to HTTP, instead of maintaining the 'over SSL' status of the URL... Strange that you describe it as intermittent, though. Maybe a caching-related issue? Sorry this isn't more helpful... -- Harald Koch <[EMAIL PROTECTED]> "It takes a child to raze a village." -Michael T. Fry __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Is anyone doing this!?!
> Does anyone have any experiences of which client/server combinatipons this will work >with? I've used subjectAltName with IE 5.0, 5.5, and 6.0; and several recent Mozilla versions. I vaguely remember it working with earlier Netscape browsers, but I don't remember which versions. -- Harald Koch <[EMAIL PROTECTED]> "It takes a child to raze a village." -Michael T. Fry __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Is anyone doing this!?!
Of all the gin joints in all the towns in all the world, "Chris Allen" had to walk into mine and say: > > Is this something that mod_ssl needs or is this a apache(etc) related > problem? Is there ever going to be a way to do name based virtual hosting > with apache and mod_ssl? It's an HTTP over SSL problem. The normal HTTP transaction looks something like: - connect to server - issue GET request, with Host: header - web server serves virtual host information based on Host: header The normal HTTPS transaction looks something like: - connect (TCP) to server - perform SSL handshake; server sends server SSL certificate - perform server certificate verification - issue get request, with Host: header Notice the order of operations is backwards; the server issues the SSL certificate *before* the server receives the Host: header, so it can't send out *different* SSL certificates. There are several solutions to this problem: 1) use IP address based virtual hosting. In this case, the SSL server knows the IP address before sending the SSL request. This is the most common solution, because it is easy and can be extended to new virtual hosts easily. The downside is that you need a separate address per virtual host. 2) use SSL over HTTP (not very well supported at this time). 3) Configure the SSL server to use a single SSL certificate. Put *all* of the names and addresses of the server into the "subjectAltName" extension field of the certificate. Note that this only works well if your set of virtual hosts is small and unchanging (like mine), or if you have your own CA. This is because you need to reissue the certificate every time you add (or remove :-) a virtual host. -- Harald Koch <[EMAIL PROTECTED]> "It takes a child to raze a village." -Michael T. Fry __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Is anyone doing this!?!
Of all the gin joints in all the towns in all the world, Tim Tassonis had to walk into mine and say: > > If you are talking about Name Based Virtual Hosts (same ip:port, but > different names) you are out of luck. You can't present different > certificates with Name Based Virtual Hosts, because the Hostname is not > known by the server at the time it should present the certificate. SubjectAltName? -- Harald Koch <[EMAIL PROTECTED]> "It takes a child to raze a village." -Michael T. Fry __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: certificate + network ACL + passwords problem?
I was once rumoured to have written:
> SSLRequire ( %{SSL_CIPHER_USEKEYSIZE} >= 128 and %{SSL_CLIENT_VERIFY} eq
>"SUCCESS" )
>
> # Allow any of certs, network access or basic auth
> Satisfy any
>
> # Network Access Control
> Order deny,allow
> Denyfrom all
> Allow from 127.0.0.1
> Allow from 199.85.99.0/24
FWIW, I just figured out that if I move the network access control into
the SSLRequire line, then I get my desired behaviour:
SSLRequire (( %{SSL_CIPHER_USEKEYSIZE} >= 128 \
and %{SSL_CLIENT_VERIFY} eq "SUCCESS" ) \
or ( %{REMOTE_ADDR} =~ m/^127\.0\.0\.1|199\.85\.99\.[0-9]+$/ ))
It's better than nothing, I guess :-)
--
Harald Koch <[EMAIL PROTECTED]>
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]
Re: IE6 & SSL problems
> All of my users run IE 5.5, 5.5sp2, 6, or 6sp1 as they are all Windows 2000. > When attempting to access the secure area on my webserver, they recieve a 'page > cannot be displayed' error. Upon refresh, 70% of the page will properly appear. > Another refresh and the rest may appear OR the error will come up again. > Another refresh and the same thing OR it will come up fine. Cool. I've never seen this one, and I use IE (various versions) to access apache (various versions, various OSes) zillions of pages on my servers everyday. > [Tue Sep 24 00:30:00 2002] [notice] child pid 3713 exit signal Segmentation > fault (11) > [Tue Sep 24 00:30:03 2002] [notice] child pid 4234 exit signal Segmentation > fault (11) > [Tue Sep 24 00:30:08 2002] [notice] child pid 3711 exit signal Segmentation > fault (11) This is a bad sign... have you got any unusual modules loaded? I know of one vendor that has an Apache module that conflicts with libssl if they are loaded the right way. > Server config is as follows: > > Red Hat 6.2, Apache 1.3.26, PHP 4.12, mod_ssl 2.8.10, OpenSSL 0.9.5a. 0.9.5a is ancient... It looks like you're building apache and mod_ssl from source; I'd build openssl (0.9.6g) from source too and use that instead of the RH6.2 distributed openssl libraries. -- Harald Koch <[EMAIL PROTECTED]> "It takes a child to raze a village." -Michael T. Fry __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: certificate + network ACL + passwords problem?
> I think it's just the way you use allow, deny. I would have put this myself: > > Order deny,allow > Denyfrom all > Allow from 127.0.0.1, 199.85.99. Same behaviour, alas. -- Harald Koch <[EMAIL PROTECTED]> "It takes a child to raze a village." -Michael T. Fry __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
certificate + network ACL + passwords problem?
I've tried this both with the stock (fully patched) RedHat 7.2, and with
a fresh-built Apache 1.3.26 + modssl-2.8.10-1.3.26 + openssl-0.9.6g.
With the attached config snippet for a "private" directory, based on the
samples from the documentation, the webserver first asks me for my
certificate, successfully validates it, and *then* asks me for a
username/password. I know the certificate is successfully authenticated,
as I've modified my CustomLog entry to log the values of
SSL_CLIENT_S_DN, SSL_CLIENT_VERIFY, and SSL_CIPHER_USEKEYSIZE.
If I comment out the four lines for network-based access control:
#Order deny,allow
#Denyfrom all
#Allow from 127.0.0.1
#Allow from 199.85.99.0/24
Then I get my expected behaviour, which is:
- if I give a certificate, I get access
- if I don't give a certificate, I am asked for username/password
Am I being dense about combining access control methods, or is there a
bug somewhere?
Thanks in advance,
--
Harald Koch <[EMAIL PROTECTED]>
"It takes a child to raze a village."
-Michael T. Fry
# any "intranet' access is allowed
# but from the Internet only HTTPS + Strong-Cipher + Password
# or the alternative HTTPS + Strong-Cipher + Client-Certificate
# If HTTPS is used, make sure a strong cipher is used.
# Additionally, allow client certs as an alternative to basic auth.
SSLRequireSSL
SSLVerifyClient optional
SSLVerifyDepth 2
SSLOptions -StrictRequire +OptRenegotiate +StdEnvVars
SSLRequire ( %{SSL_CIPHER_USEKEYSIZE} >= 128 and %{SSL_CLIENT_VERIFY} eq "SUCCESS"
)
# Allow any of certs, network access or basic auth
Satisfy any
# Network Access Control
Order deny,allow
Denyfrom all
Allow from 127.0.0.1
Allow from 199.85.99.0/24
# HTTP Basic Authentication
AuthTypeBasic
AuthName"CFRQ users"
AuthUserFile/etc/httpd/conf/passwd
Require valid-user
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]
