WebSphere Commerce FEP5 - Sterling Order Management 9.2 Integration: How to troubleshoot 403 Forbidden errors

Resolving The Problem

SECJ0056E: Authentication failed for reason No Client Certificate Available

Ensure the following steps have been followed on WESB side (Integrated Solutions Console):

- Security > SSL certificate and key management > Key stores and certificates > Your_Keystore > Personal certificates
Has a new self-signed certificate (e.g. esbservercert) created? Is the Issuer / Common Name the same as the integration user name on the Sterling server (e.g. CN=WCIntegrationUser)?
Has a new self-signed certificate (e.g. esbclientcert) created? Is the Issuer / Common Name the same as the integration user name on the Sterling server (e.g. CN=WCIntegrationUser)?


- Security > SSL certificate and key management > SSL configurations:
Has the SSL Configuration ESB_SC_SSLConfiguration (or the one of the same name as defined in your mediation module) been created?
Have the right key and trust stores been associated to this configuration? Do they hold the esbservercert and esbclientcert certificates?


If you have followed these steps, but nevertheless receive the No Client Certificate Available error on your Sterling WAS server, you can apply the following trace string on WESB side
to gather more diagnostic information about this problem:

*=info:com.ibm.ws.security.*=all:com.ibm.websphere.security.*=all:com.ibm.websphere.wim.*=all:com.ibm.wsspi.wim.*=all:com.ibm.ws.wim.*=all:com.ibm.ws.webcontainer*=all:com.ibm.wsspi.webcontainer*=all:HTTPChannel=all:GenericBNF=all:SSL=all.

You can also refer to the following MustGather document:
MustGather: Java Secure Socket Extension (JSSE), Secure Sockets Layer (SSL) or Java Cryptography Extensions (JCE) problems

For example, in a successful scenario, the trace would show some hints that WESB uses and sends its client certificate (snips):

1. ESB_SC_SSLConfiguration SSLConfig.toString() properties:
com.ibm.ssl.keyStoreClientAlias = esbclientcert
com.ibm.ssl.keyStoreServerAlias = esbservercert

2. WSX509KeyMana > getCertificateChain Entry
esbclientcert

If the trace does not show a hint or reason for the certificate not being passed, please contact IBM WebSphere Application Server Support with the log files gathered.



SECJ0056E: Authentication failed for reason <null>

Ensure the following steps have been followed on Sterling's WebSphere Application Server side:

- Has the Federated Repository Fix Pack been applied to WAS V7 FP19 / FP21 as described here:
Installing Fix Packs for use with Federated Repositories

- Alternatively, has Fix Pack 23 or higher been applied to WAS V7?

- Has client certificate login support been enabled for the file-based repository? Example:

<WAS_DIR>/profiles/Your_Profile/bin

wsadmin -conntype none
$AdminTask setIdMgrCustomProperty { -id InternalFileRepository -name certificateMapMode -value notSupported}
$AdminConfig save

There can be other certificateMapMode values as well. Please refer to the corresponding WebSphere Application Server documentation:
Enabling client certificate login support for a file-based repository in federated repositories


- Integrated Solutions Console > Users and Groups > Manage Users:
Has the integration user been defined here (e.g. WCIntegrationUser)?

- Integrated Solutions Console > Users and Groups > Manage Groups:
Has the integration group been defined (e.g. WCIntegrationGroup)?
Has the integration user been added to this group?

- Integrated Solutions Console > Enterprise Applications > Your_SterlingApplication > Security role to user/group mapping:
Has the integration user been mapped to the security role?
Has the integration group been mapped?

- Integrated Solutions Console > SSL certificate and key management > SSL configurations > Your_SSLSettings > Quality of protection (QoP) settings:
Has Client authentication been set to Supported?

- Also check if you correctly extended Sterling's web.xml file in INSTALL_DIR/repository/eardata/smcfs/extn. It must include the sections about bypass URI and CLIENT-CERT as described in Configuring the AuthorizationOnlyApiServlet


To get a better idea about this error, review the FFDC log files being generated during the failure in <WAS_DIR>/profiles/Your_Profile/logs/ffdc. For example, the error logged there can look as follows:

FFDC Exception:com.ibm.websphere.security.CustomRegistryException SourceId:com.ibm.UserMappingImpl.mapCertificateToName ProbeId:92 Reporter:com.ibm.ws.security.core.UserMappingImpl@2d812d81
com.ibm.websphere.wim.exception.PasswordCheckFailedException: CWWIM4537E No principal is found from the 'null' principal name.
at com.ibm.ws.wim.ProfileManager.loginImpl(ProfileManager.java:3699)
[...]


The CustomRegistryException points to an issue with the local file-based repository. In such a case, once you suspect a problem with the Federated Repository, enable the following trace
to gather more diagnostic information:

*=info: com.ibm.ws.wim.*=all: com.ibm.wsspi.wim.*=all


In the example above, "No principal is found from the 'null' principal name", the trace showed the root cause:

FileAdapter 2 com.ibm.ws.wim.adapter.file.was.FileAdapter WIM_SPI mapCertificate principal DN, CN=WCIntegrationUser, not found in InternalFileRepository
com.ibm.websphere.wim.exception.EntityNotFoundException: CWWIM4001E The 'CN=WCIntegrationUser' entity was not found.
at com.ibm.ws.wim.adapter.file.was.FileData.getByDN(FileData.java:935)

Here, clientCertificateMapMode had been set to exactDNMode, but the exact DN of CN=WCIntegrationUser has not been found in the list of users, either because the user was not created,
or was created with another distinguished name like uid=WCIntegrationUser.