After reviewing the JavaScript sourcecode for Dijit, I thought it was likely the error results from an "insecure" refrence to a dynamically generated IFRAME. Note there are two versions of the script file, the uncompressed represents the original source (dijit.js.uncompressed.js) and the standard (dijit.js) has been compressed for optimal transfer time.
Since the uncompressed version is the most readable, I will describe my solution based on that. At line #1023, an IFRAME is rendered in JavaScript:
if(dojo.isIE){
var html="<iframe src='javascript:\"\"'"
+ " style='position: absolute; left: 0px; top: 0px;"
+ "z-index: -1; filter:Alpha(Opacity=\"0\");'>";
iframe = dojo.doc.createElement(html);
}else{...
What's the problem? IE doesn't know if the src for the IFRAME is "secure" - so I replaced it with the following:
if(dojo.isIE){
var html="<iframe src='javascript:void(0);'"
+ " style='position: absolute; left: 0px; top: 0px;"
+ "z-index: -1; filter:Alpha(Opacity=\"0\");'>";
iframe = dojo.doc.createElement(html);
}else{...
This is the most common problem with JavaScript toolkits and SSL in IE. Since IFRAME's are used as shims due to poor overlay support for DIV's, this problem is extremely prevalent.
My first 5-10 page reloads are fine, but then the security error starts popping up again. How is this possible? The same page is "secure" for 5 reloads and then it is selected by IE as "insecure" when loaded the 6th time.
As it turns out, there is also a background image being set in the onload event for dijit.wai (line #1325). This reads something like this;
div.style.cssText = 'border: 1px solid;'
+ 'border-color:red green;'
+ 'position: absolute;'
+ 'height: 5px;'
+ 'top: -999px;'
+ 'background-image: url("' + dojo.moduleUrl("dojo", "resources/blank.gif") + '");';
This won't work because the background-image tag doesn't include HTTPs. Despite the fact that the location is relative, IE7 doesn't know if it's secure so the warning is posed.
In this particular instance, this CSS is used to test for Accessibility (A11y) in Dojo. Since this is not something my application will support and since there are other general buggy issues with this method, I opted to remove everything in the onload() for dijit.wai.
All is good! No sporadic security problems with the page loads.
Yes, you need to make sure that scripts and images are referenced via HTTPS, if the page is referenced by HTTPS.
Alternatively, try using relative URLs, so that your page can be either HTTP or HTTPS without requiring the html to change.
Best Solution
Then the browser is right — that isn't secure.
With AdSense and most other ad networks you are given a link to JavaScript. When you refer to any external <script>, you are giving complete trust over the contents of your page to the external script provider. You need to trust them to do only what they say they're going to do (show an ad), and not something nefarious like take over the login form from the page it's on and steal values you type into it, or, if the “ad” script were included on your bank account page, automatically empty out all your money.
So external scripts are a trust problem, but if you are using a vendor that provides an HTTPS interface to their ads, then at least it's only one known party you have to trust. If the ad provider only has an HTTP interface, then you're sending out your trust to anyone who can grab control with a man-in-the-middle or similar attack. You are effectively reducing the trust level of your entire page to that of plain unencrypted HTTP, so the browser is quite correct to complain that the page isn't actually any more secure than any old HTTP site.