SitePoint Sponsor

User Tag List

Results 1 to 16 of 16
  1. #1
    SitePoint Member
    Join Date
    Jun 2007
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Exclamation htaccess to force domain.com to www.domain.com

    Hi,

    I want to utilize .htaccess to force both search engines and customers visiting my site to end up viewing my site urls at www.domain.com instead of domain.com. Currently the site is accessible through either or methods, but from a search engine perspective I don't want duplicate content.

    In addition to the above, I have a SSL certificate installed on www.domain.com and not the domain.com. I don't want customers viewing https://domain.com to get scared off because the message pops up warning them that the certificate is invalid, so I want htaccess to accomplish this as well.

    I've tried several methods found elsewhere on the net but haven't had any results.

    It's been quite a while since I've altered my htaccess file and I can't remember why I have what I have in there (I'm stupid).

    Anyways, here's what my existing htaccess looks like:

    Code:
    RewriteEngine on
    RewriteCond %{HTTPS} on
    RewriteRule ^robots\.txt$ robots-https.txt
    
    RewriteEngine On
    RewriteBase /
    RewriteCond %{HTTP_HOST} !^www.domain.com$ [NC]
    RewriteRule ^(.*)$ http://www.domain.com/$1 [L,R=301]
    
    Options +FollowSymLinks
    RewriteEngine On
    RewriteCond %{HTTP_HOST} ^domain.com
    RewriteRule (.*) http://www.domain.com/$1 [R=301,L]
    RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/ 
    RewriteRule ^index\.php$ http://domain.com [R=301,L]
    
    RewriteRule ^/(.*):SSL$   https://%{SERVER_NAME}/$1 [R,L]
    RewriteRule ^/(.*):NOSSL$ http://%{SERVER_NAME}/$1 [R,L]
    If someone could tell me what I need to do in order to implement my original question without losing whatever setup I previously had as shown in the above code...I'd appreciate it.

    Thanks!

  2. #2
    Certified Ethical Hacker silver trophybronze trophy dklynn's Avatar
    Join Date
    Feb 2002
    Location
    Auckland
    Posts
    14,645
    Mentioned
    19 Post(s)
    Tagged
    3 Thread(s)
    tde5,

    Look at the tutorial linked in my signature - there are several codes there dealing with secure servers.

    Regards,

    DK
    David K. Lynn - Data Koncepts is a long-time WebHostingBuzz (US/UK)
    Client and (unpaid) WHB Ambassador
    mod_rewrite Tutorial Article (setup, config, test & write
    mod_rewrite regex w/sample code) and Code Generator

  3. #3
    SitePoint Member
    Join Date
    Apr 2009
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I had the same problem.

    DKLynn, you tutorial worked perfect. Thanks for setting up that info!

    RewriteEngine on
    RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
    RewriteRule .? http://www.example.com%{REQUEST_URI} [R=301,L]

  4. #4
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Location
    College Station, TX
    Posts
    58
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My certificate is valid for www.mydomain.com, and it works fine for www's. But still, when I hit the site https against mydomain.com (no www), I get the message mydomain.com uses an invalid security certificate.

    vhost snippet:

    Code:
    <VirtualHost *:443>
      ...  
      RewriteEngine On
      RewriteCond %{HTTP_HOST} ^mydomain\.com$ [NC]
      RewriteRule .* http://www.mydomain.com/$1 [L,R=301]
      ...
    Effectively, the SSL negotiation is happening before the rewrite can occur. Why is that not happening in your examples? I tried moving SSLEngine On to the bottom, after this rewrite business.. no difference in outcome.
    ________________________________
    design.. code.. music.. life...

  5. #5
    Certified Ethical Hacker silver trophybronze trophy dklynn's Avatar
    Join Date
    Feb 2002
    Location
    Auckland
    Posts
    14,645
    Mentioned
    19 Post(s)
    Tagged
    3 Thread(s)
    WS,

    I believe it does that because of the redirection, not because of your code.

    On the other hand,
    Code:
    RewriteRule .* http://www.mydomain.com/$1 [L,R=301]
    does NOT create a $1 variable (no atom in the RewriteRule) so you ARE causing a problem if you're not trying to get to the DirectoryIndex file(s) - like css, jpg, gif, js, etc.

    Regards,

    DK
    David K. Lynn - Data Koncepts is a long-time WebHostingBuzz (US/UK)
    Client and (unpaid) WHB Ambassador
    mod_rewrite Tutorial Article (setup, config, test & write
    mod_rewrite regex w/sample code) and Code Generator

  6. #6
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Location
    College Station, TX
    Posts
    58
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's a good catch, DK. It must be remnant from permutations of the script.

    I agree with you that my issue is "because of the redirection," however SpaGuy, above, seems to have found that your redirect resolved his same issue.

    Is it possible to have a vhost for just mydomain.com:443 to handle requests and _not_ be ssl? Meaning, the browser first makes a request as https://, but due to failed negotiations of cypher (b/c ssl is not enabled in that vhost), the browser just does an http on 443 after all long enough to receive the 302 to https://www.mydomain.com which would be handled by a vhost for www.mydomain.com:443?
    ________________________________
    design.. code.. music.. life...

  7. #7
    Certified Ethical Hacker silver trophybronze trophy dklynn's Avatar
    Join Date
    Feb 2002
    Location
    Auckland
    Posts
    14,645
    Mentioned
    19 Post(s)
    Tagged
    3 Thread(s)
    Whatever happened to tde5?

    WS,

    Are you an Aggie? Sorry, just asking 'cause of the College Station.
    Quote Originally Posted by WS
    Is it possible to have a vhost for just mydomain.com:443 to handle requests and _not_ be ssl? Meaning, the browser first makes a request as https://, but due to failed negotiations of cypher (b/c ssl is not enabled in that vhost), the browser just does an http on 443 after all long enough to receive the 302 to https://www.mydomain.com which would be handled by a vhost for www.mydomain.com:443?
    BECAUSE port 443 is the normal port for {HTTPS}, I'd have to say (guess) that a request made to that port would be the same as making an https:// request. In fact, I believe that request would fail because you do not have port 443 setup for that domain (look at your httpd.conf/httpd-vhosts.conf to see IP:80 defined for that VirtualHost). Saying that, I don't believe that you'd be able to capture an {HTTPS} request to redirect it to http://.

    Oh, my! You DID specify a *.443 for your VirtualHost, didn't you!

    Okay, it WAS an Aggie question, wasn't it?

    Regards,

    DK
    David K. Lynn - Data Koncepts is a long-time WebHostingBuzz (US/UK)
    Client and (unpaid) WHB Ambassador
    mod_rewrite Tutorial Article (setup, config, test & write
    mod_rewrite regex w/sample code) and Code Generator

  8. #8
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Location
    College Station, TX
    Posts
    58
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    hey, hey, let's not go calling each other names here.. I can't claim Aggieness. Was born and raised in CS but studied elsewhere.

    I think I'll just have to try it out and see. The theory I'm leveraging here is that SSL provides an opportunity to negotiate strongest cryptography to use: if the server says, "I can't offer any crypo you recognize" it may just connect to :443 non-SSL, and it might provide that opportunity to Location: https:www's. I would bet against it, though.

    So are we agreeing that maybe the folks above who posted but aren't responding didn't actually get a work-around to the certificate is invalid issue?
    ________________________________
    design.. code.. music.. life...

  9. #9
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Location
    College Station, TX
    Posts
    58
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    btw, https://google.com somehow redirects to http://www.google.com without issue. Watching LiveHeaders in firefox doesn't reveal anything, b/c ssl negotiation happens before the request is handled and responded with..
    ________________________________
    design.. code.. music.. life...

  10. #10
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Location
    College Station, TX
    Posts
    58
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't know that this is considered exhaustive or conclusive research, but Verisign's certificate search indicates that there are (or were..) www.google.com certificates over the years but I didn't find the same for google.com....
    ________________________________
    design.. code.. music.. life...

  11. #11
    Certified Ethical Hacker silver trophybronze trophy dklynn's Avatar
    Join Date
    Feb 2002
    Location
    Auckland
    Posts
    14,645
    Mentioned
    19 Post(s)
    Tagged
    3 Thread(s)
    WS,

    Whew! I knew that I worked with three Aggies (2 Lt, Capt, L/C) at Randolph and LAAFS and came to realize that Aggie jokes are the same as "{fill-in the blank} jokes" but based on Aggie history. My condolences for living there and having to put up with them! Okay, I'm sure that this trio were exceptions but they were the "ring knocker" type and left a bad taste.

    I believe that you NEED to have SSL enabled (and signed by a recognized authority) in order to avoid the browser warnings (redirections will not be sufficient). As for Google, I'm sure they have enough $$$ that their secure server certificate(s) are not even a drop in the bucket.

    As for your "negotiate the strongest cryptography," that the function of the server and browser and it's automatic (I don't understand why you want to reinvent this).

    As for what I do, I have my files in a shared directory (i.e., http and https in the same DocumentRoot) and use mod_rewrite to force https for ONLY those scripts that need it and http for everything else. I just look for port 443/80 for that choice (because {HTTPS} is null - not "off" for http).

    Regards,

    DK
    David K. Lynn - Data Koncepts is a long-time WebHostingBuzz (US/UK)
    Client and (unpaid) WHB Ambassador
    mod_rewrite Tutorial Article (setup, config, test & write
    mod_rewrite regex w/sample code) and Code Generator

  12. #12
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Location
    College Station, TX
    Posts
    58
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok, we're doing the same thing. https where required.. So, is it safe to say that if someone were to hit https://yourdomain.com that it would not redirect to https://www.yourdomain.com but would in fact trigger an invalid certificate message?

    I think the least alarming, most least expensive route is to vhost :443 only www's and to let www's and no-subdomain get handled by :80 only. If someone were to hit https on the www's, then rather than a cert error, they would get a page cannot be displayed error.
    ________________________________
    design.. code.. music.. life...

  13. #13
    Certified Ethical Hacker silver trophybronze trophy dklynn's Avatar
    Join Date
    Feb 2002
    Location
    Auckland
    Posts
    14,645
    Mentioned
    19 Post(s)
    Tagged
    3 Thread(s)
    WS,

    Not really. A SIGNED secure server certificate is created for either the www or non-www'd version of a domain (I apparently switched at my last cert renewal and found that out the hard way). Therefore, I use:
    Code:
    # secure server is https://mydomain.com, NOT www. !!!
    RewriteCond &#37;{SERVER_PORT} ^443$
    RewriteCond %{HTTP_HOST} ^www\.mydomain\.com$ [NC]
    RewriteRule ^(.*)$ https://mydomain.com/$1 [R=301,L]
    THEN, my secure page (I share my cert with clients [addon domain] - in this case, his orders.php script) has the following code FIRST:
    PHP Code:
    if (80 == $_SERVER['SERVER_PORT']) header('Location: https://mydomain.com/client_domain/orders.php'); 
    This would not generate a 404 but serve the script at the highest negotiated security level.

    Good questions - I hope this clarifies things for you. The code I've shown has been online (successfully) for years.

    Regards,

    DK
    David K. Lynn - Data Koncepts is a long-time WebHostingBuzz (US/UK)
    Client and (unpaid) WHB Ambassador
    mod_rewrite Tutorial Article (setup, config, test & write
    mod_rewrite regex w/sample code) and Code Generator

  14. #14
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Location
    College Station, TX
    Posts
    58
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok I can see that-- it is exactly what I'm doing (but opposite on w's vs tld). So even in your case, were someone to hit https://www... they wouldn't get immediately redirected but would in fact get a bad certificate error. (I just tested it, it's true) But the key here is that any links and redirects that are in your (or your clients') control must go to the tld https, not the www's.

    I appreciate your taking the time to dialog.. Maybe now it's clear what my concern was, and maybe seeing that at least three folks are doing it this way that it's no major concern anyhow (the chance of "invalid certificate" is minute, b/c it is never linked nor redirected-to). And the url published is always http and never https.
    ________________________________
    design.. code.. music.. life...

  15. #15
    Certified Ethical Hacker silver trophybronze trophy dklynn's Avatar
    Join Date
    Feb 2002
    Location
    Auckland
    Posts
    14,645
    Mentioned
    19 Post(s)
    Tagged
    3 Thread(s)
    WS,
    Quote Originally Posted by BCSWebStudio View Post
    Ok I can see that-- it is exactly what I'm doing (but opposite on w's vs tld). So even in your case, were someone to hit https://www... they wouldn't get immediately redirected but would in fact get a bad certificate error. (I just tested it, it's true) But the key here is that any links and redirects that are in your (or your clients') control must go to the tld https, not the www's.

    I appreciate your taking the time to dialog.. Maybe now it's clear what my concern was, and maybe seeing that at least three folks are doing it this way that it's no major concern anyhow (the chance of "invalid certificate" is minute, b/c it is never linked nor redirected-to). And the url published is always http and never https.
    Bingo!

    Ultimately, you need to decide whether to go to extremes to "idiot proof" your website. For me, you can lead a horse to water (publish and link your URLs) but you can't make it drink. That 2% who might refuse to use the URLs/links aren't worth the effort.

    Regards,

    DK
    David K. Lynn - Data Koncepts is a long-time WebHostingBuzz (US/UK)
    Client and (unpaid) WHB Ambassador
    mod_rewrite Tutorial Article (setup, config, test & write
    mod_rewrite regex w/sample code) and Code Generator

  16. #16
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Location
    College Station, TX
    Posts
    58
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Agreed. Hey, come on-- I'm a computer scientist by training: I have to beat every discussion to a pulp before making the smart business decision. :|

    (and just to prove it's OK, I tested and verified that the large Compass Bank also does the same thing (online.compass passes, compass alone gives misleading "invalid certificate") )
    ________________________________
    design.. code.. music.. life...


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •