On Tue, Mar 31, 2009 at 10:19 AM, Alessandro Fantuzzi <fantuzzi@xxxxxxxxx> wrote: > > First of all thanks for your advice. > > I will check if we can serve all of the contents both in SSL and non SSL. > I didnt consider that solution, in fact I was concerned about putting the > conversation between client and server back to http when the user requires a > page which needs no protection. > After all the most important thing should be to ensure that some pages are > served only in https and forget about the rest. In fact once the client has > established a secure connection, the conversation should go on that way > regardless of the pages requested, with no need to get back to http. > > Anyway I fear our client will not accept this solution, because it is not > what they requested. > > The ideal solution should be to force the user to visit protected pages in > https and get back to http for all the rest of the contents. > > Is there a way to accomplish this ? > > Do the protected pages need to be on a separate path or it is not necessary > ? > > As regards the number of bits I was referring to 128 bit Verisign > certificates. > > Bye Should be pretty easy to do what you want: Set up your SSL enabled virtual host to listen on 443. You can use the same DocumentRoot, and all the same Alias and RewriteRules so that both vhosts serve up the same content. For pages that require protection, you can use RequireSSL directive to prevent the page from being accessed over an insecure connection: if someone tries to access it over http, it should give a 403 forbidden error. You can also use a RewriteRule with the [R] flag in the non-secure vhost so that accesses to the pages that require secure connections get redirected to the secure connection. Something like: RewriteRule ^/securepage.html https://myhost/securepage.html [R] You can do the same thing if you want to prevent non-secure pages from being served up by the SSL vhost, just use a RewriteRule to redirect them to non-secure connection, but unless your client thinks they know what they're doing but actually don't, then this shouldn't be required. Links in the secure-page content can always be absolute and specify non-secure destinations, so it's not like they'll automatically just stay on secure HTTP once they get there. Is that what you're looking for? Regarding the size of the key: sorry, I've been working with PGP a lot lately where 1024+ bits are the norm. I guess 128bit is pretty standard for SSL. -Brian -- Feel free to contact me using PGP Encryption: Key Id: 0x3AA70848 Available from: http://pgp.mit.edu/ --------------------------------------------------------------------- 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
|