Hi all. I have an intranet site with a core area that is public access, but the rest of the site is SSL secured. I have a PostReadRequest handler checking the port, and if it's 443 returning OK, but if not it checks to see if the requested page is in the list of nonsecure areas and exceptions. Anything not clearly specified as unsecured is sent an external redirect to the same page on the secure socket. This works great for most things, but there are a few consequences that I just can't think around. Specifically, other intranet sites link directly to relevant data locations on our server. This is fine under normal circumstances, but today I got a nastygram from a user for "changing" my access. Her certificate had expired (along with several others in her office who had all installed on the same day), and suddenly it was effectively a dead link. Even once they had installed new certs, several of them were still getting "certificate expired" because they had told their browsers to use the old one by default. I have pages on the site to explain all this and provide solutions, but these aren't exactly sophisticated users; someone helps them get it all installed and then they remember the certificate password, and go from there. When it expires, it never occurs to them to see if the server root is still accessible, or if it does, to take the "s" out of the protocol, which would let them get to the site (on virtually every page of which we have a header link to "Digital Certificate Info"). The best suggestion I could come up with was to ask the linking site to add a link to a nonsecure page, like our comment form. Anyone have anything better? __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ______________________________________________________________________ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
