0

We have a port of openssl on an HP Nonstop and have a requirement to send a SOAP request with the same security header which SoapUI is generating. Thus far, we have been able to get a match of the digest value (3 long days). Now I am throughly stuck trying to generate the same signature in openssl that we see in SoapUI.

I have two inputs: one file containing a binary digest value and another containing a base64 digest value.

I have the same .pfx keystore which is loaded in SoapUI on the HP NSK but I had to convert it to a .pem file (openssl pkcs12 -in pfx -out pem -nodes).

I have found three separate openssl commands that will generate a signature but none of them match the SoapUI signature from an identical digest value:

openssl dgst -sha1 -rand randfile -sign pem dgst.txt | openssl enc -base64 > sig

openssl rsautl -sign -inkey pem -in dgst.txt | openssl enc -base64 > sig

openssl pkeyutl -inkey pem -in dgst.txt | openssl enc -base64 > sig

A couple of the openssl commands will allow you to specify '-sha', '-sha1' etc. There are eleven of those, I've tried everyone. No match on the signature.

Any help on this? Going on day 3 here and I thought this was the easy part.

Here is the security header generated by SoapUI. I have removed the signature for brevity and any customer identifiable information. I mainly show this to indicate which algorithms are being specified etc.

    <wsse:Security xmlns:wsse="redacted" xmlns:wsu="redacted">
<ds:Signature Id="SIG-7175F72748C072A4761529013840614108" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
            <ec:InclusiveNamespaces PrefixList="soapenv v1 v11 v2" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        </ds:CanonicalizationMethod>
        <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
        <ds:Reference URI="#id-CE0A4571D7DB69D8CE152339585717529">
            <ds:Transforms>
                <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                    <ec:InclusiveNamespaces PrefixList="v1 v11 v2" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                </ds:Transform>
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>redacted</ds:DigestValue>
        </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>removed for brevity</ds:SignatureValue>
    <ds:KeyInfo Id="redacted">
        <wsse:SecurityTokenReference wsu:Id="redacted">
            <ds:X509Data>
                <ds:X509IssuerSerial>
                    <ds:X509IssuerName>CN=Symantec Class 3 Secure Server CA - G4,OU=Symantec Trust Network,O=Symantec Corporation,C=US</ds:X509IssuerName>
                    <ds:X509SerialNumber>redacted</ds:X509SerialNumber>
                </ds:X509IssuerSerial>
            </ds:X509Data>
        </wsse:SecurityTokenReference>
    </ds:KeyInfo>
</ds:Signature>

SRSeedBurners
  • 1
  • 1
  • 3
  • When you create signature with openssl manually are you sure you are taking canonicalized data? – Pras Jun 18 '18 at 03:29
  • As Pras says, the data needs to be canonicalized. – Andy Simpson Jun 18 '18 at 23:13
  • The payload is being canonicalized. I move the canonicalized and siblings to the NSK box and I get an identical digest value from openssl. That's what I meant in the thread that took us three days - trying to get the correct canonicalization. Now we're stuck at the signature. – SRSeedBurners Jun 19 '18 at 03:19

0 Answers0