Java Not Working In Internet Explorer 11

Recently I spent a few days creating and compiling a Java Deployment Rule Set and signing it with an Active Directory certificate.  After much stress it worked like a charm on my development machine.

I tested some of my rules by using the Java verify page, whereby it displayed the version of Java that the browser was currently using.

However in the Live environment the Java verify page just wouln’t render the Java applet.  I added Java.com to the trusted sites zone, and then I got a grey box in place of the applet.

In the Java control panel I navigated to the Advanced tab and made sure to select ‘Show console’.  The next time I launched a new session of the Java verify page in Internet Explorer I could see what was happening:

Proxy Direct

 

 

 

 

 

 

 

 

 

 

I could see that the proxy was returning as: “proxy=DIRECT”.  This should not have been the case since we were using the default LAN Settings which was configured to use an Auto Config PAC file (a JavaScript file that says “if you’re navigating to this URL, use that proxy etc.).  So it should have been returning a valid proxy from the PAC file.

I changed my LAN setting to use a static proxy/port and re-ran the Java Verify page.  This time it worked and the console showed that it was returning a proxy address!

Since we’d deduced it wouldn’t work with the PAC file, one potential solution was to use Java network settings (Java control panel > General tab > Network settings) to point to a proxy, and leave the LAN settings as the auto config PAC file for all browing in Internet Explorer.  However when I tested this, once again I saw “proxy=DIRECT”!

Upon further testing I noticed that several versions of Java 7 ignore the Java Network Settings! These are:

Java 7u60
Java 7u67
Java 7u71
Java 7u72
Java 7u75

Finally these three versions honour the Network Settings, and the proxy was correctly used:

Java 7u76
Java 7u79
Java 7u80

But you’ll notice I did say that this was a ‘potential’ solution.  It still wasn’t an ideal solution.  Why wasn’t the auto config PAC file returning a valid proxy?  Well, I debugged our corporate PAC file and lo and behold, I noticed a missing semi-colon!

somevariable = “DIRECT”

should have been

somevariable = “DIRECT”;

So Internet Explorer parsed the PAC file ok, and ‘understood’ that there was a missing semi-colon and carried on routing users correctly when they were browsing the internet.  However Java’s parsing of the PAC file was obviously more strict, noticed a semi-colon was missing and consequently failed and reverted to a ‘DIRECT’ connection!  Once I fixed this issue Java in Internet Explorer burst in to life!

Code Signing Certificates, Expiry Dates and Timestamping

When I set about signing a Java deployment rule set with a code signing certificate, I noticed that my certificate had an expiry date of 1 year from the current date.  My initial thoughts were that I didn’t want all these Java applications to suddenly stop working in a years time because my code signing certificate had expired!  But I needn’t have worried.

Why Do Code Signing Certificates Expire

When a code signing certificate expires, you can no longer sign any content with it.  The reason they expire is for security purposes.  If they didn’t ever expire and the certificate fell into the wrong hands, anybody could impersonate your company forever!

Will Signed Content Stop Working When My Certificate Expires?

If you haven’t added a timestamp during the signing process, the signed content will check the certificate expiration date against the current date and fail if the certificate has expired.

However adding a timestamp during the signing process provides verification that the signing took place when the certificate was valid, and your signed content will be valid indefinitely.  Timestamping is a mechanism that ensures your digital signature remains trusted long after your Code Signing certificate has expired.

AppSense Regular Expression for Microsoft Office

I needed to add a new rule to AppSense recently on process start.  I wanted the rule to only run when a Microsoft Office application was run.

Now I usually eat regular expressions for breakfast (with some ketchup on top for good measure).  However I noticed that my regular expression wasn’t working in AppSense and it turned out to be the flavour of Regular Expression that it uses.

You see, I tend to use JavaScript regular expressions or .Net regular expressions.  But AppSense was presumably written in C++ and uses the CAtlRegExp regular expression of the ATL class which is…..lame.  Grouping syntax is different, and so is character matching syntax.

To test my regular expressions, rather than update the AppSense policy and wait for it to deploy to the machine, I just downloaded the regular expression tester from here.

So this was my first attempt – the MfcRegex tool said it was a successful match!  So I plonked it into AppSense:

But wait!  AppSense tries to be clever and escapes the brackets with preceding backslashes (I noticed this in the client debug logs), so this RegEx was failing because AppSense was evaluating it to this:

So by this point I was close to throwing my computer out of the window, until finally I used this syntax which works like a charm:

Notice that I have changed the brackets and slightly altered the syntax.  If you wanted to limit it to a specific version of Office (2010 in my case) you can use a regular expression similar to this:

 

 

Create a Code Signing Certificate using Active Directory Certificate Services

Ok, this post is shameless plagiarism from this post.  But I couldn’t risk losing sight of good content.  Thanks (and apologies) go to David Barrett!

Enable the Code Signing Certificate Template

  1. On the appropriate server (e.g. the CA root), open Certificate Services Manager.
  2. In the left pane, select Certificate Templates.
  3. Check for a Code Signing template – by default, this isn’t available.  If it isn’t, add it:
    1. From Action menu, select New -> Certificate Template to Issue.
    2. Select Code Signing, then click OK.

 Grant Permissions for User(s) to Create Code Signing Certificates

  1. From the Certificate Services Manager, right click Certificate Templates and select Manage.
  2. From the list of templates, right-click Code Signing and select Properties.
  3. Select the Security tab.
  4. Any users that should be allowed to create code signing certificates need to be granted Read and Enroll permissions, so add users and permissions as necessary.
  5. Apply changes.

Create a Code Signing Certificate

  1. On the development machine (logged in as a user who has been granted permissions to create a code signing certificate), open Microsoft Management Console.
  2. From File menu, select Add/Remove Snap-in…
  3. From Available snap-ins, select Certificates and then click Add.
  4. Select My user account, and then click Finish.
  5. OK out of the Add/Remove snap-in window.
  6. You will now see Certificates listed in the console view on the left.  Right-click Personal, select All Tasks, then Request New Certificate.
  7. Click Next on the first screen (Before You Begin).
  8. Click Next on the Select Certificate Enrolment Policy screen (Active Directory Enrolment Policy will be applied).
  9. In the Request Certificates screen, tick Code Signing, and then click Enrol.  A certificate will be created and placed in the user’s Personal store.

Browsium Ion and Authentication

I set up a Browsium rule recently to render a SharePoint 2010 site in IE8 Standards mode.

Without the Browsium rule in place the site loaded fine but one of the Web Parts didn’t work.  However when the Browsium rule was enabled, the Web Part worked fine but the user was prompted for authentication when the site initially loaded!  It was as if Browsium wasn’t passing the Windows authenticated credentials during the request.

Specifying AutoAuth

To resolve the authentication issue we can specify an ION profile flag under Advanced Profile Set which details what credentials are sent to the upstream server when automatically replying to an authentication challenge.

Browsium AutoAuth

Browsium Ion, HTTPS and Proxy Authentication

I’ve been playing around with Browsium Ion recently and I was testing a HTTPS URL, trying to force the default ‘Edge’ emulation mode to run in ‘IE8’ emulation mode instead.  For HTTP URLs it worked fine.  However with HTTPS URLS, when a new instance of iexplore.exe launched (presumably after being intercepted and spawned by Browsium Ion) the user was prompted for proxy authentication.  Even upon entering correct credentials it still didn’t authenticate.  After clicking ‘cancel’ dozens of times, the authentication prompt eventually went away and we saw the page rendering successfully in IE8 Emulation mode.

Specifying a Proxy Host and Port

To resolve the authentication issue we can specifically provide a proxy host and port (one that authenticates for the user) by adding the following to Advanced Profile Set for the profile in question:

Browsium Proxy

Disable ‘Managed Mode’ in Mcafee

I was testing an app on a Virtual Machine (a P2V of the client build) and I had a feel McAfee was preventing something from functioning.  To test this I needed to disable ‘Managed Mode’ in Mcafee.  This is how I did it:

Step 1: Login in as an admin user

Step 2: Run: c:\Program Files (x86)\McAfee\Common Framework\x86\FrmInst.exe /forceuninstall

Step 3: Reboot into safe mode

Step 4: Open Regedit and delete:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\McAfee\ePolicy Orchestrator\Application Plugins\VIRUSCAN8800

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Network Associates\ePolicy Orchestrator\Application Plugins\VIRUSCAN8800

In

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\McAfee\DesktopProtection

set

UIP to blank

UIPMode to 0

Step 5: Reboot

We can now log back in as an administrator and ‘disable’ McAfee via the VirusScan console (Right-Click ‘Access Protection’, click Disable).

Add a Right-click Context Sub Menu

I’ve been creating a few tools recently for a client – scripted tools which perform specific tasks on MSI (Windows Installer) files. Because we’re likely to create multiple tools and I don’t want the context menu to get too long and too ugly, so I decided to add a right-click context sub menu.  Here’s what it produces:

context

And here’s the registry that made it happen:

If you look closely, you should see that this context menu will only show for MSI files because we use the Msi.Package progid.  You’ll also note that when we export registry into a .reg file like above, all quotes in the registry values are escaped by a preceeding backslash as indeed are all backslashes!  So a quote would be \” and a backslash would be \\!  As an example (taken from above) the value:

mshta.exe \”\\\\server\\pathtotools\\mycustomtool.hta\” \”%1\”

when imported will resolve to:

mshta.exe “\\server\pathtotools\mycustomtool.hta” “%1”