I assume you're using .htaccess in your "home page" directory, and that both SSL and non-SSL requests are 'pointed' to the same directory-structure, and therefore will both execute the same .htaccess code. This is not necessarily the case, so check it before continuing.
If so, the problem may be that you are redirecting *all* requests to https, including those for non-secure pages. Further, it is possible that your HTML source is referring to included objects in an inconsistent way.
Here's a "standard" set-up to take care of SSL-to-non-SSL, non-SSL-to-SSL and non-canonical hostname request redirects:
# Redirect secure pages to HTTPS if requested using HTTP
RewriteCond %{SERVER_PORT} !=443
RewriteRule ^(checkout\.php|login\.asp|showcart\.html)$ https://www.example.com/$1 [R=301,L]
#
# Redirect non-secure pages to HTTP if requested using HTTPS
RewriteCond %{SERVER_PORT} =443
RewriteCond $1 !^(checkout\.php|login\.asp|showcart\.html)$
RewriteRule ^(.+\.(php|asp|html?))$ http://www.example.com/$1 [R=301,L]
#
# Redirect requests using non-blank non-canonical hostname
# to canonical hostname, preserving HTTP/HTTPS protocol
RewriteCond %{HTTP_HOST} !^(www\.example\.com)?$
RewriteCond %{SERVER_PORT}s ^(443(s)|[0-9]+s)$
RewriteRule ^(.*)$ http%2://www.example.com/$1 [R=301,L]
Note that only "page" URLs are redirected by the first two rules. Requests for included objects such as images, CSS, or external JavaScript files will not be affected. Therefore, these objects should be linked-to using page-relative <img src=
"images/logo.gif"> or server-relative <img src=
"/images/logo.gif"> URL-paths, or using absolute URLs
appropriate to the the page in which the object is included -- i.e. if you wish to use an absolute link to an image from within a secure page, then specify the https protocol in the link, and if you wish to use an absolute link to an image from within a non-secure page, then specify the http protocol in that link.
This code is meant as an example. It is freshly-typed and not tested. Further, you can see that I 'invented' several URL-paths to demonstrate redirecting multiple pages.
Do not rely on the first two rules to correct linking errors within your own site. Although "it will work," it will likely result in poor page-load times and possibly in further trouble with SSL security warnings. Instead, rely on these two redirects only to correct bad links from other sites, incorrect search engine listings, and incorrect type-in URLs.
If you still have problems, the "Live HTTP Headers" add-on (or similar) for Firefox/Mozilla-based browsers can be used to inspect the HTTP request and response headers passed between your browser and your server. Careful examination of the URLs requested by the client and the resulting server responses can be quite revealing and useful in cases like this.
A common problem is the inclusion within a secure page of external scripts (such as Google Analytics, page 'hit' counters, etc.) with are not secure. The choices in that case are to find/obtain a secure link URL for the included object, or failing that, to remove the insecure object from the page.
Jim
