Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When using an HTTPS connection we are receiving the following warning:

"Your connection is encrypted with 128-bit encryption. However, this page includes other resources which are not secure."

PROBLEM: We narrowed down the issue to the images on the SSL page. If we paste an SSL URL into a browser, it redirects to a NON-SSL connection.

EX: We paste " " into a browser and it immediately redirects to " "

We're running the following server specs:

Server: Windows Server 2003 Web Edition

IIS Version: 6.0

We've checked the configuration settings and everything appears to be fine.

EDIT: We tried this same issue on a local server and the redirection does NOT occur. Using the "HttpFox" firefox plugin we have seen that we receive a 302 redirect from https to http on the production server. When we performed the same test on the local server, the 302 redirect does not happen. Checking the IIS 6 configurations on both servers shows no differences.

share|improve this question
Can you verify that the server is actually sending the redirect? If you send the request by hand, what's the output? – MikeyB Jul 29 '11 at 13:58
@MikeyB Using the "HttpFox" firefox plugin I see that the GET of the https image sends a 302 redirect to the http version. – Scott Vercuski Jul 29 '11 at 14:10
up vote 1 down vote accepted

More information needed, so it's probably time to break out the difference engine.

Grab the Web Deployment Tool (MSDEPLOY) from, and create a package from the working web server.

Then, do an msdeploy -verb:sync with -whatif to compare the package with the prod server, and reveal differences in configuration.

If there is no difference, they will perform identically. It's not, so there is one, it's just not where you've looked so far.

share|improve this answer

It turns out the issue was caused by an SSL module that we weren't aware we had. The module in question was named secureWebPages. We had to add the extra paths to the component to ensure that images, scripts and styles came across as https as well. We changed our configuration file from ...

<secureWebPages enabled="true" xdt:Transform="Insert">
  <directory path="/checkout" />

to ...

<secureWebPages enabled="true" xdt:Transform="Insert">
  <directory path="/images" ignore="true" />
  <directory path="/styles" ignore="true" />
  <directory path="/scripts" ignore="true" />
  <directory path="/checkout" />
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.