Showing results for 
Search instead for 
Did you mean: 
Cisco Secure Email Support Community

Product Support Talos Support Cisco Support Reference + Current Release
Gateway Reputation Lookup Open a support case Secure Email Guided Setup
Gateway: 14.0.0-698
Cloud Gateway Email Status Portal Support & Downloads
Email and Web Manager: 14.0.0-404
Email and Web Manager Web & Email Reputation Worldwide Contacts Product Naming Quick Reference
Reporting Plug-in:
Encryption Bug Search
Encryption Plug-in:
Cloud Mailbox Notification Service
Outlook Add-in(s): More info


Permissions on Postx Jar for CRES


When I try to read an incoming secure message (CRES Registered Envelope) using a browser, I get the following error regarding missing permissions on a Postx jar:


If I continue to run, I get the following second message. I cannot decrypted the message locally on my desktop.


I installed Java and the CRES toolkit (can't remember the exact name) some time ago as I was prompted to do so on my first attempt to read a registered envelope.

Any idea how to recover from this? Is there a newer version of the toolkit for CRES/PostX that may solve this problem?



Yes, as reported above, fixing this requires an envelope change, so there's a longer process to roll out fixes, and existing envelopes will continue to have the problem, so you'll have to use open online for those.

The garbled text is because the applet is sending big-endian data with a big-endian BOM and a charset of "UTF-16", which is all proper and should be fine (and works in all other browsers), but IE 11 is treating the data as little-endian, swapping every other byte. Sigh.

OK, thanks for clarification and confirmation.

Hello Brian

We have some customers that are facing the "garbled text" problem with the big-endian data in IE 11. Are you perhaps in a position to provide any feedback since the post on 09 December 2013 stating that the problem is being investigated?

I know it's being worked on (I've seen code  changes flow by), but I don't know when it will be done and deployed.  The bug it's being worked on under is CSCul88098.

Dear Brian,

Great to hear the IE11 is being worked on and the pointer you supplied for the bug case. But please keep in mind that the applet runs into different problems in other versions of IE. I assume in addition to the latest version, you intend to support at least the one prior to the latest?

FYI, I have tested IE 8 thru 10, in addition to IE11. On IE 8 thru 10, a different exception occuers:

ExitException[ 3]java.lang.SecurityException: Bad applet class name

               at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)

               at sun.plugin2.applet.Plugin2Manager$ Source)

               at Source)

The error is poped up only if you have turned on debugging in your Java Console, otherwise you don;t see it. BUT the tricky part of problems with pre-IE 11 versions is that following the exception, the applet quietly changes the default of the decyrption to online mode and the "OPEN" button changes to "OPEN Online". An unsuspected user who has not turned on the exception reporting (I suspect the majority), may as usually click the return and not recognizing that their sensitive document is sent to an online service for decryption.

Is there a fix underway for pre-IE 11 and other browsers (which their problems have been discussed earlier in this thread)? If so, could you please provide a pointer for those bugs as well?

The console log showing the exception for IE 10 is attached below.



Java Plug-in

Using JRE version 1.7.0_51-b13 Java HotSpot(TM) Client VM

User home directory = C:\Users\jsmith


c:   clear console window

f:   finalize objects on finalization queue

g:   garbage collect

h:   display this help message

l:   dump classloader list

m:   print memory usage

o:   trigger logging

q:   hide console

r:   reload policy configuration

s:   dump system and deployment properties

t:   dump thread list

v:   dump thread stack

x:   clear classloader cache

0-5: set trace level to


basic: Added progress listener: sun.plugin.util.ProgressMonitorAdapter@1ddd557

basic: exception: Bad applet class name.

ExitException[ 3]java.lang.SecurityException: Bad applet class name

               at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)

               at sun.plugin2.applet.Plugin2Manager$ Source)

               at Source)

Ignored exception: ExitException[ 3]java.lang.SecurityException: Bad applet class name

basic: Dialog type is not candidate for embedding

basic: Removed progress listener: sun.plugin.util.ProgressMonitorAdapter@1ddd557

security: Reset deny session certificate store

The "bad applet class name" bug is CSCul90399. However, that's not what's causing Open Online to be used instead of Open, that's due to Java not being enabled by default any more and the process used to prompt the user to enable it not being compatible with how applets are used by envelopes, and is covered by bug CSCum00414.


Thanks again for the explanation. Looks like Java compatibility (or lack thereof) is raising havoc...!!


Content for Community-Ad