0

In the process of trying to determine how SoapUI creates the WS-Security header, and then duplicate that in openssl, I have found that the Windows version of openssl digest does not match what we are seeing in SoapUI and the openssl port that is on our HP Nonstop.

Win64 openssl digest value (OpenSSL 1.1.0h 27 Mar 2018)

openssl dgst -binary -sha1 OutReqIncl.xml | openssl enc -base64
Pz8/Dlt7P1o/P10/Fz8pSjkQPz8NCg==

HP Nonstop openssl digest value (OpenSSL 1.0.2o 27 Mar 2018)

openssl dgst -binary -sha1 OutReqIncl.xml | openssl enc -base64
mLSHDlt7/1qTy13iF/0pSjkQ1dc=

This is what we see in SoapUI - I have no idea what they use:

<ds:DigestValue>mLSHDlt7/1qTy13iF/0pSjkQ1dc=</ds:DigestValue>

In order to ensure nothing changed in the file in transit to the HPNS, I compared a hex dump of the file as it resides on both systems and it came up an identical match. Plus the SoapUI digest matches what see on the HP Nonstop openssl.

Any idea why the Win64 version doesn't match?

SRSeedBurners
  • 1
  • 1
  • 3
  • If you use an intermediate file on Windows to hold the output of the digest and then encode the file you get a different result to the piping operation (tested on 1.0.2o, 1.1.0h). I suspect that the piping on the NonStop is doing something similar to using a temporary file. ` ./openssl dgst -binary -sha1 -out temp .\DoxygenLayout.xml ./openssl enc -base64 -in temp ` I tested with the Guardian version of openssl and using the intermediate file approach, I see the same result as I do on Windows without piping. – Andy Simpson Jun 28 '18 at 00:20
  • Apologies for formatting - by the time I had learnt the markdown, my 5 minute edit window was up. Hopefully you get what I'm saying. – Andy Simpson Jun 28 '18 at 00:27
  • I tried testing your theory by sending the output of both commands (Win64 vs HPNS) directly to a temporary file and comparing the binary output. Test.file contains the text "This is a test file" on both systems. openssl dgst -binary -sha1 Test.file > tmp Win64 openssl FF FE 61 25 6D 00 B0 00 C6 03 53 00 65 00 7F 20 ED 00 41 00 FF 00 18 00 AC 00 38 00 4B 00 FA 00 61 25 C4 03 75 00 60 00 47 00 0D 00 0A 00 NSK openssl B5 6D F8 ED 53 65 FC A1 41 98 18 AA 38 4B A3 B5 – SRSeedBurners Jun 28 '18 at 12:36
  • Ok, I ran into the same 5m editing issue and that last comment is useless. I was trying to show the binary output on both systems is different, removing the pipe from the equation. The Win64 also puts a FFFE byte order mark in the output from the dgst command. – SRSeedBurners Jun 28 '18 at 12:43

0 Answers0