Question: With Internet Explorer 7 we get authentication failure or connection failure errors when trying to access certain HTTPS sites. These sites worked fine before, does Internet Explorer 7 not work with HTTPS sites?

Answer: Internet Explorer 7 modified the default settings for HTTPS connections to remove default support for SSL v2 certificates. This change was made in order to help increase the overall security of HTTPS connections. SSL v2 certificates do not offer the same level of encryption as the current SSL v3 option, and therefore it is not recommended to use SSL v2 for an encryption mechanism.

Solution: Microsoft recognizes there are legacy applications which may use SSL v2 certificates, so support for SSL v2 was not removed from the product entirely. It was disabled by default. The recommended solution for this issue is to obtain new SSL v3 certificates for any older/legacy web servers and applications that use SSL v2. If that is not possible, you can enable support for SSL v2 in the Advanced tab of the Internet Options control panel:

There is no Group Policy Object setting to enable this feature. To enable it for your enterprise deployments you would need to either:

• Use the Internet Explorer Administration Kit (ieak) 7 to build a custom Internet Explorer 7 package, and then deploy that MSI package using your Software Management System (SMS) infrastructure (or similar software delivery system).
• Create a custom registry file to make this change and deploy it via login scripts. The registry key is located at:

  
  [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\InternetSettings\]
  

• Under that key you will need to create the SecureProtocols REG_DWORD entry with the flag options:

  
  "The
  SSLv2 flag is 8 (0x008).
  The SSLv3
  flag is 32 (0x020).
  The TLSv1
  flag is 128 (0x080)."
  

• Hence, if all protocols are enabled, the value is 0x0A8.  The IE 7 default is 0xA0.
• These changes can be made using Active Directory configuration changes or you can use login scripts to run a registry file file update for installations that do not have AD infrastructures. The registry file needs to contain both of the lines above and have a .reg extension for it to properly import to the system registry.

Question: Why do we see Certificate Errors: Navigation Blocked page for sites that used to work fine?

Answer: Internet Explorer 7 modified the default security settings for HTTPS connections to increase overall security in a number of instances. As a result of the new security default settings, IE 7 will block users (by presenting a red-colored information page) in any of the following instances when visiting an HTTPS site:

• Certificate was issued to a hostname other than the current URLs hostname
• Certificate was issued by an untrusted root
• Certificate is expired
• Certificate is revoked

Solution: Microsoft recognizes there are legacy applications which may utilize older or internally issued certificates that now trigger the new warning page. The intent of this change was to increase security and protect users from online threats. Microsoft recommends upgrading HTTPS sites to meet the newer level of security and validation checking. To accommodate for those scenarios where that is not practical, you are able to modify the default settings in your deployment. In addition, certain situations, such as allowing the use of expired or revoked certificate should never be over-ridden. Doing so is likely to create a reduction in user and system security. Microsoft also strongly advises against modifying the default settings regarding certificate address mismatch. Disabling this change may expose your users to improperly configured systems on the Internet, and may result in compromised security of the machine.

A frequent scenario is users being blocked by default by the use of internally issued certificates for intranet sites (untrusted root issue). To resolve that error you should use Group Policy to deploy the internal root certificate used by your organization. You can also use the Certificate Manager Tool (information at http://msdn2.microsoft.com/en-us/library/e78byta0(VS.80).aspx, but the tool is included in Visual Studio) to build a login script to manually install the custom root certificate. That certificate will be stored in the local machine certificate store, not as a part of Internet Explorer. More information on working with the certificate store, and how to add your own certificates, can be found at http://technet2.microsoft.com/windowsserver/en/library/2c03582f-00b2-43e5-ae1d-493894ad0fd71033.mspx?mfr=true.

Question: We have users locked-down as standard users. Before Internet Explorer 7 our support staff could use the Run As option to access Windows Explorer as an admin and perform necessary tasks (e.g. installing software). With Internet Explorer 7 we are no longer able to use that option. Is something wrong with our configuration?

Answer: No, this change was made to help increase the overall security of Internet Explorer and protect users against online threats. The issue is related to the process separation of Windows Explorer and Internet Explorer. Prior to the release of Internet Explorer 7, those two processes were linked and support staff/system administrators were able to use that link in order to open a Windows Explorer window (by entering a local file system location in the address bar) with administrative credentials. Now that we have separated those two processes, this option is no longer possible. Attempting to use the Run As option to launch Internet Explorer 7 will perform as expected and launch the process with administrative privileges. When the administrator enters a local file system location in the Internet Explorer 7 address bar, the separate Windows Explorer process is called and it launches with the logged in user credentials.

Solution: Since this change was made by design to increase security, there is no way to disable this setting or simple workaround. It was intended to create a barrier between the two processes and isolate Windows Explorer from potential external compromise. The only way to access the local file system with administrator level credentials would be to logon to the local machine directly to perform the necessary tasks. In the case of remote support, Microsoft recommends using Remote Desktop Connections in order to login with the proper credentials required to perform the required task.

Question: We're using Internet Explorer 7 and having issues on Windows Vista with some legacy applications that read and write to the local file system. Why cant it read and write the files properly? Is there something different about Internet Explorer 7 on Windows XP?

Answer: The main difference between Internet Explorer 7 on Windows XP and Windows Vista is that Windows Vista offers an additional security protection to help prevent unintentional system access by malicious software or other parties. This feature is known as Protected Mode, and helps protect users and systems by restricting the ability of the Internet Explorer process from reading and writing to critical areas of the file system. Protected Mode allows reading and writing from the user hive area of the file system, but prohibits activity to areas outside that perimeter. In making this change, some applications fail to work properly as they are attempting to read and write from restricted areas. Protected Mode does make an effort to assist improperly written applications by virtualizing data reads and writes from the file system, however this should not be used as a remediation option for Protected Mode issues.

Solution: To resolve issues with Protected Mode application compatibility problems, customers are encouraged to rewrite the application (or extensions) to be Protected Mode aware. Resource information about working with Protected Mode is available at http://msdn2.microsoft.com/en-us/library/bb250462.aspx. In addition, the document at http://msdn2.microsoft.com/en-us/library/bb250493(VS.85).aspx on security and compatibility issues in Internet Explorer 7 will provide information about how to use the Application Compatibility Toolkit to diagnose specific compatibility issues with Protected Mode problems.

Microsoft does not recommend disabling Protected Mode as a solution to application compatibility. Removing this security mechanism may expose users and computers to unnecessary system compromise, loss of resources or unwanted installation of software.