At Wed, 19 May 2010 15:29:51 -0600 CentOS mailing list <centos at centos.org> wrote: > > On Wed, May 19, 2010 at 3:02 PM, Zack Colgan > <security-watch-zack at clearbearing.com> wrote: > > On 05/19/2010 04:08 PM, Ski Dawg wrote: > >> The problem I am running into is if they go to https://domainname.com > >> (straight to the secure site), I am not able to find a solution that > >> will redirect them to https://www.domainname.com, so that the ssl > >> certificate matches and they won't get the "This connection is > >> untrusted" warning. > > > > The problem you are running into is that SSL sessions are negotiated > > prior to the browser sending the virtual host name, so there is no > > opportunity to redirect the client to the www URL before it's too late. > > Â Aside from purchasing a second SSL certificate for the plain domain > > name or getting a wildcard certificate to cover both, I would just make > > sure the links on your web site to the secure version of the domain > > specify the www in the URL. > > Zack, > > Thanks for the reply. > > All of our links use the correct syntax (with the www), we were just > trying to catch the corner cases where if someone tries to go directly > to https://domainname.com instead of https://www.domainname.com then > it would not give them the error. Is there any *legitimate* reason why someone would want to *type* https://domainname.com in the location/address bar? There really should not be a reason to do that. If people are doing this, then that means there is some reason for it (maybe the https://www.domtainname.com/... link is too deeply burried in the regular site?). > > I was hoping to be able to do this without another certificate, since > this is just some corner cases, but I will investigate that as well. > Thanks. -- Robert Heller -- Get the Deepwoods Software FireFox Toolbar! Deepwoods Software -- Linux Installation and Administration http://www.deepsoft.com/ -- Web Hosting, with CGI and Database heller at deepsoft.com -- Contract Programming: C/C++, Tcl/Tk