ProcessWSSHeaders triggered when Security is not configured for the primary message unit

[IsaacN72]

When receiving a Receipt from a successful delivery, ProcessWSSHeaders is triggered when neither the P-Mode, outbound (original message) or receipt message contain security configurations. This results in a non-fatal error, but triggers the resend process (if configured in the PMode) even though the original message was successfully delivered.

(Log and SOAP records attached)

0aa580ad-9955-4a2a-aa29-6b07c899ba3f_holodeck.log 0aa580ad-9955-4a2a-aa29-6b07c899ba3f_SOAP_OUT.log 0aa580ad-9955-4a2a-aa29-6b07c899ba3f_SOAP_RECEIPT_IN.log

[sfieten]

The processing pipeline is the same for all messages, regardless whether they are (supposed to be) signed and/or encrypted. Therefore the ProcessWSSHeaders handler is executed for the unsigned response signal. The problem however is not that the message isn't signed, but a problem in the configuration of Holodeck B2B. As shown in the log there is a problem with accessing a key store. Please check that the passwords set in the HB2B configuration file (conf/holodeckb2b.xml, assuming you are using version 3.1.x) match to the actual passwords of the key stores.

[IsaacN72]

Hi, Thanks for the quick response. That was the first thing I checked based on the error message. The system is currently configured with the 'factory defaults' while testing. Actual 'real' certificates and keys are being used though:

~$ keytool -list -keystore /opt/holodeck-b2b-3.1.1/repository/certs/privatekeys.jks -storepass secrets Keystore type: jks Keystore provider: SUN

Your keystore contains 1 entry

test, 10/09/2018, PrivateKeyEntry, Certificate fingerprint (SHA1):....

keytool -list -keystore /opt/holodeck-b2b-3.1.1/repository/certs/publickeys.jks -storepass nosecrets Keystore type: jks Keystore provider: SUN

Your keystore contains 1 entry

recipient_test, 29/08/2018, trustedCertEntry, Certificate fingerprint (SHA1): ....

keytool -list -keystore /opt/holodeck-b2b-3.1.1/repository/certs/trustedcerts.jks -storepass trusted Keystore type: jks Keystore provider: SUN

Your keystore contains 2 entries

trusted1, 30/08/2018, trustedCertEntry, Certificate fingerprint (SHA1): ... trusted2, 30/08/2018, trustedCertEntry, Certificate fingerprint (SHA1): ...

The only other security context is that the the outbound message is using two way transport layer security:(runtime options -Djavax.net.ssl.keyStoreType=pkcs12 -Djavax.net.ssl.keyStore="alternative_keystore" -Djavax.net.ssl.keyStorePassword="alternative_keystore_password" -Djavax.net.ssl.trustStore="/opt/holodeck-b2b-3.1.1/repository/certs/trustedcerts.jks" -Djavax.net.ssl.trustStorePassword="trusted" \ -Djavax.net.ssl.PublicKeyStore="/opt/holodeck-b2b-3.1.1/repository/certs/publickeys.jks" -Djavax.net.ssl.PublicKeyStorePassword="nosecrets" \ ....

but I wouldn't expect the transport layer security to be impacting message layer, and the message layer is configured with defaults as shown above. The two way SSL configuration appears OK (original payload is delivered OK after handshakes, certificate checks etc.)

I can kind of understand why ProcessWSSHeaders handler is still executed, but it seems odd that it then needs to check the keystore when security is not configured for the primary message unit.

EDIT: After submitting the above, I changed the runtime SSL private keystore to be the Holodeck default keystore so that all keystores are the same at both transport and message layer, and obviously using the same passwords. Same result. During the sending phase the system skips over security configuration if no headers are present: ...CreateWSSHeaders - No security headers to add, skip processing

Couldn't we do something similar at the return leg for the receipt? e.g. No security headers found, skip processing...

[sfieten]

You're right about that the transport level security should not influence the message level security as it's handled by different components. Based on your comment above I am not sure whether the problem persists or whether you were able to resolve it. I tried to reproduce the issue using two clean installations of version 3.1.1 but couldn't reproduce this behavior. I however did not test together with the specific TLS settings, but as mentioned I would not expect this to affect the message processing. With regards to changing the processing. This could be done, but since this seems more like a configuration error I don't think it is useful.

[IsaacN72]

Hi, Not yet resolved. I can reproduce it in both Dev and Test environments. I'll install the latest version of Holodeck and see if that makes a difference.

[IsaacN72]

Hi Sander, To reproduce the problem you need to have the private keystore as something other than the default privatekeys.jks holodeck repository with the holodeck.xml private keystore parameter pointed to that 'external' keystore. I've been able to resolve this, by importing the external private keystore into Holodeck's default keystore and configuring the -Djavax.net.ssl.keyStore runtime parameter to point to that same keystore.

Java throws an interesting warning during the import process too: The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore /opt/holodeck-b2b-3.1.2/repository/certs/privatekeys.jks -destkeystore /opt/holodeck-b2b-3.1.2/repository/certs/privatekeys.jks -deststoretype pkcs12".

I'm wondering if Holodeck doesn't play nicely with different format keystores? That seems weird in itself though as it all boils down to Java in the end.

Anyway, I'm considering the resolution of this issue to be 'use the default options'. :-)

Closing the ticket with thanks for your time and consideration. 👍 Isaac