Thursday Dec 11, 2014

e-Signing a Workflow Notification fails on Internet Explorer on Windows 7

With the launch of Windows 7 Operating system, Microsoft has ceased to support CAPICOM DLL. CAPICOM is an ActiveX control used to digitally sign data, display certificates from browser and to encrypt and decrypt data. In Oracle Workflow Notification System, CAPICOM has been used to digitally sign Notification data in Workflow Notifications. This is only used when signing a workflow notification from Internet Explorer. Now that this DLL is not included in Windows 7 and further versions of Windows OS, the signing process of a Workflow Notification, requiring certificate based signature, errors out with the following message:

"Verification of signature has failed"

Oracle Workflow provides a solution to this issue. The patch numbers for obtaining this solution on the following code-lines are as follows:

  • Release - 18921580
  • Release 12.1.3 - 18921687:R12.OWF.B
  • Release 12.2.3 - 19410235:R12.OWF.C

Due to the removal of dependency on an ActiveX control, there are certain subliminal changes in the user interface for signing a workflow notification. The following are two changes:

1. Change in the look of Certificate Selection window. The list of certificates to be selected are now loaded in an Applet. This is as shown below:

2. A small time lag after clicking on Sign button. A informative message conveying the same is displayed. The screenshot of the same is as shown below.Please wait for the applet to be loaded after clicking on "Sign". There would be an applet loaded as shown in earlier image a user can select certificate for signing the notification data.

Apart from these negligible changes, the whole signing experience is in parity with that which existed before Windows 7 plus Internet Explorer as browser.

Thursday Oct 09, 2014

'The signing operation has failed' - common error with Password Based Signatures in Workflow Notifications


Oracle Workflow Notifications can be digitally signed in two ways.

  1. Password Based Signature
  2. X.509 Certificate Based Signature.

Following are the authentication mechanisms categorized based on whether or not a user subscribes to Single Sign-On (SSO).


  1. Pure E-Business Suite User (Otherwise called FND User)
  2. Pure SSO user
  3. Hybrid Mechanism (Both E-Business Suite and SSO)

Issues and Reasons

Time and again we have encountered a problem with Password Based signatures failing with the error: 'The signing operation has failed'. This happens when the notification is signed using SSO credentials i.e., the logged in user is an SSO user. The profile option APPS_SSO_LOCAL_LOGIN, controls the type of authentication mechanism to be used for a user at the time of user-creation. More information about SSO can be found here

The possible values of this profile option are:

  • LOCAL - Login is only allowed via Oracle E-Business Suite local login.
  • SSO - Login is only allowed through Single Sign-On. The password is set to ‘EXTERNAL’ after a single sign-on account and an application account are linked.
  • BOTH - Login can be through both Single Sign-On and Oracle E-Business Suite. (Please note this is only a separate authentication mechanism but not a different class of users created for it)

Now based on the type of login/authentication mechanism, the signing differs.


  • For a FND User, the validation utility validates the credentials by fetching password from FND_USER table from ENCRYPTED_USER_PASSWORD column.
  • For a pure SSO user, the ENCRYPTED_USER_PASSWORD column is set to 'EXTERNAL' in FND_USER table and the Validation utility fetches the password from OID to validate it.
  • For a user using both types of authentication mechanisms, the Validation utility validates it as it does in the case of a FND User i.e., comparing the ENCRYPTED_USER_PASSWORD from FND_USER table. This implies that when the user uses authentication mechanism for both FND User and SSO user then the password for FND User is used for validation.

Also, it is to be noted that the password for SSO user is case sensitive and the password for FND user depends upon a profile option SIGNON_PASSWORD_CASE. In short:


  • An SSO user password is case-sensitive.
  • An FND User password is by default case insensitive. It depends upon the value of profile option 'SIGNON_PASSWORD_CASE' to have it case sensitive or case insensitive.
  • For a user which uses both authentication mechanisms, the password for FND user is used for signing. It would be good if these passwords are maintained in sync.
Hence, when one encounters the error mentioned here, the starting point to investigate is to see what type of user it is. Mostly it would be user using authentication mechanism for both FND User and SSO User. In that case the FND User password should be used and not the SSO password. Also the case of the password should be heeded to as that can well be the cause of the issue. 





« July 2016