Validating Signed payload in APIGEE using java cal...

ummaniapigee

I am using below Java Callout to validate consumer signed payload .https://github.com/DinoChiesa/ApigeeEdge-Java-WsSec-Signature-2).

I tried signing the payload & validating same signed payload in same proxy using above Java callout and it getting validated (working as expected)

But when i use same signed payload and validate ( in other proxy which has only validate callout ) its failing with (wssec_error :signature did not verify).

even its same error when consumers signed request content trying to verify (wssec_error :signature did not verify)

here i am attaching Consumer request and Verify callout configuration .

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<JavaCallout continueOnError="false" enabled="true" name="JC-Verify-Action">
<DisplayName>JC-Verify-Action</DisplayName>
<Properties>
<Property name="debug">true</Property>
<Property name="source">message.content</Property>
<Property name="required-signed-elements">u:Timestamp,a:To</Property>
<Property name="soap-version">soap1.2</Property>
<Property name="accept-thumbprints">{SHA-1 thumbprint}</Property>
</Properties>
<ClassName>com.google.apigee.callouts.wssecdsig.Validate</ClassName>
<ResourceURL>java://apigee-wssecdsig-20230721.jar</ResourceURL>
</JavaCallout>

kpapigee

Dino-at-Google,

Request Content:

<s:Envelope
    xmlns:s="http://www.w3.org/2003/05/soap-envelope"
    xmlns:a="http://www.w3.org/2005/08/addressing"
    xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://services.lighthouse1.com/autopaybalanceinquiry/servicecontract/v1.0/AutoPayBalanceInquiryServ...</a:Action>
    <a:MessageID>urn:uuid:cd45fd24-bea7-470b-ae10-5d1f0d4fc77d</a:MessageID>
    <a:ReplyTo>
      <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
    </a:ReplyTo>
    <a:To s:mustUnderstand="1" u:Id="_1">https://apiservice-bus-qa3.kp.org/service/health_admn/care_admn/Evolution1/AutoPayBalanceInquiry/v1</a:To>
    <o:Security s:mustUnderstand="1"
                xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <u:Timestamp u:Id="_0">
        <u:Created>2024-04-23T06:26:18.833Z</u:Created>
        <u:Expires>2024-04-23T06:31:18.833Z</u:Expires>
      </u:Timestamp>
      <o:BinarySecurityToken u:Id="uuid-e8840b9f-517f-47b2-9d76-fb419dcddec8-8" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">MIIcjjCCG3agAwIBAgIRAOH7njJgG1TFE3B1qTdi5a8wDQYJKoZIhvcNAQELBQAwgZUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE9MDsGA1UEAxM0U2VjdGlnbyBSU0EgT3JnYW5pemF0aW9uIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBDQTAeFw0yNDA0MDgwMDAwMDBaFw0yNTA1MDgyMzU5NTlaMHIxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMSwwKgYDVQQKEyNLYWlzZXIgRm91bmRhdGlvbiBIZWFsdGggUGxhbiwgSW5jLjEgMB4GA1UEAxMXa3BoYy1pYy1kZXYuYXBwbC5rcC5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCZRiDdHV9POBYYsi1RNt6DIYQCbRkICkdiLNLThx0rVDXeRo3yBxJYT2w3HEbFAQnjxS1L2+8zW41G6xbtCGkNIitPZ5GtqdKilT9JGqdp8UYGByD164sq4Lx13WOwfL44amozcgBShG2F5xx5T7qW3Vgjln4dbztCC4RXlRifX0TbdanIAWKrB4tJjUef+9ULni2Q6c4JMAqh9fu/z/F2D1uyYBXDdobCVhjXJRwl5pQSjYlbLANqppNfOAiAvRWh/8WiH4e8KjjkAKD8ypGEGuIqHYWMmI9e6GvYxJcGR2onQABbcXNMj58oixuBHWReZA3crakGMNYmG9QltROtAgMBAAGjghj5MIIY9TAfBgNVHSMEGDAWgBQX2dYlJ2f5McJJQ9kwNkSMbKlP6zAdBgNVHQ4EFgQUbxIQqGLWm2zpsMWUBtVhekH6rwIwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMEoGA1UdIARDMEEwNQYMKwYBBAGyMQECAQMEMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2VjdGlnby5jb20vQ1BTMAgGBmeBDAECAjBaBgNVHR8EUzBRME+gTaBLhklodHRwOi8vY3JsLnNlY3RpZ28uY29tL1NlY3RpZ29SU0FPcmdhbml6YXRpb25WYWxpZGF0aW9uU2VjdXJlU2VydmVyQ0EuY3JsMIGKBggrBgEFBQcBAQR+MHwwVQYIKwYBBQUHMAKGSWh0dHA6Ly9jcnQuc2VjdGlnby5jb20vU2VjdGlnb1JTQU9yZ2FuaXphdGlvblZhbGlkYXRpb25TZWN1cmVTZXJ2ZXJDQS5jcnQwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLnNlY3RpZ28uY29tMIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWgAdgDPEVbu1S58r/OHW9lpLpvpGnFnSrAX7KwB0lt3zsw7CAAAAY6+tUhmAAAEAwBHMEUCIHey2gLK6pKF/EXpiVDAk7dGUlSgUCr5tuiq0jQjTYaEAiEAvSKaJRBxs5l13H6+wiEadOzBUtHNUub9MGADTo93h+YAdgCi4wrkRe+9rZt+OO1HZ3dT14JbhJTXK14bLMS5UKRH5wAAAY6+tUg+AAAEAwBHMEUCIQDQG+2ltqxvCWPlsYGmNnOyGouFXpVSfeaQokHsCnOpcAIgFyfL5U+C2SSaqr2OtC4cP1zLN52tsLSfDE5KUwDQw6cAdgBOdaMnXJoQwzhbbNTfP1LrHfDgjhuNacCx+mSxYpo53wAAAY6+tUgHAAAEAwBHMEUCIQCMscX2aYU1mp4zkqvc0z5Q2ihZq0JuLAPbwBIHdpvj8wIgY9RzM+9b9EuueUhLYEejty6xESWSHw5Y38RjPxZkEvowghW9BgNVHREEghW0MIIVsIIXa3BoYy1pYy1kZXYuYXBwbC5rcC5vcmeCE2ljLWNvZTEuYXBwbC5rcC5vcmeCE2ljLWNvZTIuYXBwbC5rcC5vcmeCE2ljLWNvZTMuYXBwbC5rcC5vcmeCGGtwaGMtaWMtZGV2MS5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXYxMC5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxMDAuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTAxLmFwcGwua3Aub3JnghprcGhjLWljLWRldjEwMi5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxMDMuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTA0LmFwcGwua3Aub3JnghprcGhjLWljLWRldjEwNS5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxMDYuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTA3LmFwcGwua3Aub3JnghprcGhjLWljLWRldjEwOC5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxMDkuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2MTEuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTEwLmFwcGwua3Aub3JnghprcGhjLWljLWRldjExMS5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxMTIuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTEzLmFwcGwua3Aub3JnghprcGhjLWljLWRldjExNC5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxMTUuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTE2LmFwcGwua3Aub3JnghprcGhjLWljLWRldjExNy5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxMTguYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTE5LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjEyLmFwcGwua3Aub3JnghprcGhjLWljLWRldjEyMC5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxMjEuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTIyLmFwcGwua3Aub3JnghprcGhjLWljLWRldjEyMy5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxMjQuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTI1LmFwcGwua3Aub3JnghprcGhjLWljLWRldjEyNi5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxMjcuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTI4LmFwcGwua3Aub3JnghprcGhjLWljLWRldjEyOS5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXYxMy5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxMzAuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTMxLmFwcGwua3Aub3JnghprcGhjLWljLWRldjEzMi5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxMzMuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTM0LmFwcGwua3Aub3JnghprcGhjLWljLWRldjEzNS5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxMzYuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTM3LmFwcGwua3Aub3JnghprcGhjLWljLWRldjEzOC5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxMzkuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2MTQuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTQwLmFwcGwua3Aub3JnghprcGhjLWljLWRldjE0MS5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxNDIuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTQzLmFwcGwua3Aub3JnghprcGhjLWljLWRldjE0NC5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxNDUuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTQ2LmFwcGwua3Aub3JnghprcGhjLWljLWRldjE0Ny5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxNDguYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTQ5LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjE1LmFwcGwua3Aub3JnghprcGhjLWljLWRldjE1MC5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxNTEuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTUyLmFwcGwua3Aub3JnghprcGhjLWljLWRldjE1My5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxNTQuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTU1LmFwcGwua3Aub3JnghprcGhjLWljLWRldjE1Ni5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxNTcuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTU4LmFwcGwua3Aub3JnghprcGhjLWljLWRldjE1OS5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXYxNi5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxNjAuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTYxLmFwcGwua3Aub3JnghprcGhjLWljLWRldjE2Mi5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxNjMuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTY0LmFwcGwua3Aub3JnghprcGhjLWljLWRldjE2NS5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxNjYuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTY3LmFwcGwua3Aub3JnghprcGhjLWljLWRldjE2OC5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxNjkuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2MTcuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTcwLmFwcGwua3Aub3JnghprcGhjLWljLWRldjE3MS5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxNzIuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTczLmFwcGwua3Aub3JnghprcGhjLWljLWRldjE3NC5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxNzUuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTc2LmFwcGwua3Aub3JnghprcGhjLWljLWRldjE3Ny5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxNzguYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTc5LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjE4LmFwcGwua3Aub3JnghprcGhjLWljLWRldjE4MC5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxODEuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTgyLmFwcGwua3Aub3JnghprcGhjLWljLWRldjE4My5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxODQuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTg1LmFwcGwua3Aub3JnghprcGhjLWljLWRldjE4Ni5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxODcuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTg4LmFwcGwua3Aub3JnghprcGhjLWljLWRldjE4OS5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXYxOS5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxOTAuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTkxLmFwcGwua3Aub3JnghprcGhjLWljLWRldjE5Mi5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxOTMuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTk0LmFwcGwua3Aub3JnghprcGhjLWljLWRldjE5NS5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxOTYuYXBwbC5rcC5vcmeCGmtwaGMtaWMtZGV2MTk3LmFwcGwua3Aub3JnghprcGhjLWljLWRldjE5OC5hcHBsLmtwLm9yZ4Iaa3BoYy1pYy1kZXYxOTkuYXBwbC5rcC5vcmeCGGtwaGMtaWMtZGV2Mi5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXYyMC5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXYyMS5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXYyMi5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXYyMy5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXYyNC5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXYyNS5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXYyNi5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXYyNy5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXYyOC5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXYyOS5hcHBsLmtwLm9yZ4IYa3BoYy1pYy1kZXYzLmFwcGwua3Aub3JnghlrcGhjLWljLWRldjMwLmFwcGwua3Aub3JnghlrcGhjLWljLWRldjMxLmFwcGwua3Aub3JnghlrcGhjLWljLWRldjMyLmFwcGwua3Aub3JnghlrcGhjLWljLWRldjMzLmFwcGwua3Aub3JnghlrcGhjLWljLWRldjM0LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjM1LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjM2LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjM3LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjM4LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjM5LmFwcGwua3Aub3JnghhrcGhjLWljLWRldjQuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NDAuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NDEuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NDIuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NDMuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NDQuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NDUuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NDYuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NDcuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NDguYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NDkuYXBwbC5rcC5vcmeCGGtwaGMtaWMtZGV2NS5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY1MC5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY1MS5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY1Mi5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY1My5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY1NC5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY1NS5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY1Ni5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY1Ny5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY1OC5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY1OS5hcHBsLmtwLm9yZ4IYa3BoYy1pYy1kZXY2LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjYwLmFwcGwua3Aub3JnghlrcGhjLWljLWRldjYxLmFwcGwua3Aub3JnghlrcGhjLWljLWRldjYyLmFwcGwua3Aub3JnghlrcGhjLWljLWRldjYzLmFwcGwua3Aub3JnghlrcGhjLWljLWRldjY0LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjY1LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjY2LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjY3LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjY4LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjY5LmFwcGwua3Aub3JnghhrcGhjLWljLWRldjcuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NzAuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NzEuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NzIuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NzMuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NzQuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NzUuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NzYuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NzcuYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NzguYXBwbC5rcC5vcmeCGWtwaGMtaWMtZGV2NzkuYXBwbC5rcC5vcmeCGGtwaGMtaWMtZGV2OC5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY4MC5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY4MS5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY4Mi5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY4My5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY4NC5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY4NS5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY4Ni5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY4Ny5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY4OC5hcHBsLmtwLm9yZ4IZa3BoYy1pYy1kZXY4OS5hcHBsLmtwLm9yZ4IYa3BoYy1pYy1kZXY5LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjkwLmFwcGwua3Aub3JnghlrcGhjLWljLWRldjkxLmFwcGwua3Aub3JnghlrcGhjLWljLWRldjkyLmFwcGwua3Aub3JnghlrcGhjLWljLWRldjkzLmFwcGwua3Aub3JnghlrcGhjLWljLWRldjk0LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjk1LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjk2LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjk3LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjk4LmFwcGwua3Aub3JnghlrcGhjLWljLWRldjk5LmFwcGwua3Aub3JnMA0GCSqGSIb3DQEBCwUAA4IBAQAthkYzjVHEMrI36mH+wSnTLXwwSJM0mZgCu1zfPcxNVA1IBpJZsDa97e0OYg5C32557f+QQtdmpmi8YEnbAnrTlbmyVLumKR4bI+NoV9kG/r8yOOKjAGZfSV7gEanEXx7SK5Sr5B/k7R71xdoj0iyejYp7CNqfVdjlDqC0gfx1o3bV9B+rOpYFs44Du4Q0g79Pc+evCfTsjKj32lPqEPM0kc/NZFFmS4vAnKNpL1AxyZz7X3hxE4x/V2ts4bpvudWkYsX+mZyEVkC09x86Sjjyn/+vQSluTYfGSft1LYRRAFjHGOIJvg78/Qk66dKx7GNzf+65EIccVoA7GLvLwUmE</o:BinarySecurityToken>
      <Signature
          xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
          <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
          <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
          <Reference URI="#_0">
            <Transforms>
              <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <DigestValue>Ef6qlvb5D3IGljJnKwNCvslwX8Y=</DigestValue>
          </Reference>
          <Reference URI="#_1">
            <Transforms>
              <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <DigestValue>9bOHp0wKJjmMHYbuON/QROJHLe8=</DigestValue>
          </Reference>
        </SignedInfo>
        <SignatureValue>ZQVt0AS9HnRDTRehocdVAz1S2eCmZSlOAwli4Vce6Bmt3eNgSg+IBIYoW4DiIqKXXkM/TBT0M4uami8fIqtxYKrhBED2BarzhtvtYy0gLHFdJLnZqO1lsiRlh6GlLHihtoc/9hWKtEUNIztRCPS8BBxIx5KUe3mhRUPCkqXK0tWZEVaLqh8+E5mZdC+FlbCOlsRzu6kVRmj8JlLwVpHMIvO0uVSVsefrbwOZ5S9o5yLv9FZDvUl2DHqH1vlWxZakWdOFqSVcKr4VXEqAJ1a2+IClagmipgMrFhH1RHejuBtTbTHkLpi25Pun9OW++60J6CCE1uu8Lby0KL+RbtGeJA==</SignatureValue>
        <KeyInfo>
          <o:SecurityTokenReference>
            <o:Reference ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" URI="#uuid-e8840b9f-517f-47b2-9d76-fb419dcddec8-8"/>
          </o:SecurityTokenReference>
        </KeyInfo>
      </Signature>
    </o:Security>
  </s:Header>
  <s:Body>
    <GetEligibleBalance
        xmlns="http://services.lighthouse1.com/autopaybalanceinquiry/servicecontract/v1.0">
      <request>
        <d:MessageId
            xmlns:d="http://services.lighthouse1.com/autopaybalanceinquiry/datacontract/v1.0">123</d:MessageId>
        <d:RecordID
            xmlns:d="http://services.lighthouse1.com/autopaybalanceinquiry/datacontract/v1.0">123</d:RecordID>
        <d:ConsumerDOB
            xmlns:d="http://services.lighthouse1.com/autopaybalanceinquiry/datacontract/v1.0">123</d:ConsumerDOB>
      </request>
    </GetEligibleBalance>
  </s:Body>
</s:Envelope>

dchiesa1

ok thanks for that.

The namespace prefixes are actually a and u, so that will be just fine. And the signed elements really are just the a:To element and the u:Timestamp element.

I tried the verification on my end. Because the whitespace in the signed document is obviously changed from when the digital signature was applied, before attempting to validate the signature I had to manually edit the document to collapse whitespace - to remove spaces and newlines. After doing that I was able to validate the signature on the modified document successfully. The modified document looks like this:

In other words, the Security header is all on one line; there are no spaces or newlines between any XML "begin element" and "end element".

And my Validate policy looks like this:

<JavaCallout name='Java-WSSEC-Validate-2'>
  <Properties>
    <Property name='source'>message.content</Property>
    <Property name='require-expiry'>true</Property>
    <Property name="required-signed-elements">wsu:Timestamp,wsa:To</Property>
    <Property name='accept-thumbprints'>1bc61c4afb916551cc806089c81ea3f90e4318e3</Property>
    <Property name="soap-version">soap1.2</Property>
    <Property name='digest-method'>sha1</Property>
    <Property name='signing-method'>rsa-sha1</Property>
    <Property name='ignore-expiry'>true</Property>
  </Properties>
  <ClassName>com.google.apigee.callouts.wssecdsig.Validate</ClassName>
  <ResourceURL>java://apigee-wssecdsig-20240426.jar</ResourceURL>
</JavaCallout>

I had to set "ignore-expiry" because the ExpiresAt moment in the document was 175 hours ago!

With that caveat, signature validation works for me.

Does this help?

dchiesa1

when i use same signed payload and validate ( in other proxy which has only validate callout ) its failing with (wssec_error :signature did not verify).

"Signature did not verify" can result if the content is modified in any way between producing the signed version, and verifying the signature on the signed version. As one example, if you "pretty print" the XML that is produced by a "sign" process, the resulting XML will have different whitespace, and the signature on the modified XML payload will not verify. The XML digital signature protocol considers whitespace to be significant.

I would like to understand what you mean by

when i use same signed payload and validate

Are you saying that a signed payload that you produced in ONE proxy, will not validate if the validation is performed in a different proxy?, but it does validate if the validation is performed in the SAME proxy? If that is the case, I would check that the key+cert being used in the signing proxy match the key+cert (and thumbprint) in the validating proxy.

dchiesa1

I just tried this myself, and found that it works for me. I can invoke one API proxy to produce a signed document in output. and then invoke a second API Proxy with the output of that request, to validate that signed document.

This isn't surprising to me, this is how I would expect it to work.

Find a quick screencast showing this here: https://youtu.be/JuUtXenrTvo

In my experience, It is always a challenge to diagnose problems with digital signatures. There is no shortcut; you need to methodically check that every parameter used in the signing process, matches or aligns with the requisite parameters in the Validation process.

One thing I noticed in your configuration:

<Property name="required-signed-elements">u:Timestamp,a:To</Property>

This will work, if and only if

the signed document includes references to at least the Timestamp and To elements in the signature. You didn't show the configuration for the Signing callout, so I cannot tell if the signer is configured to do this.
the XML namespace prefixes in your signed XML document, for http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd and http://www.w3.org/2005/08/addressing are u and a, respectively.

By convention the prefixes are often wsu and wsa. Those conventional prefixes are by no means required. But in this version of the Java validation callout, the prefixes you use in the policy configuration must match the prefixes in the actual document. So if your document uses something like
```
    xmlns:a="http://www.w3.org/2005/08/addressing"
    xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
```
...then your configuration will work as intended. But if your document uses the wsu and wsa prefixes, your configuration will not work.

Also: with this configuration of the validate callout, you tell the callout to check only for signature on the Timestamp and To elements. This means that an attacker could modify the Body element of a valid message, and the validator would still treat the modified message as valid. This would not cause a "signature did not verify" error as you have reported. In fact the validator would accept the signature on the modified document, and that would be a big problem. I would think you would want to ALWAYS minimally validate the Timestamp and Body. It would be very strange to not validate the soap Body.

ummaniapigee

Thanks @dchiesa1 for your detailed explanation. its still failing for me ,looks when i am copying request content signature getting corrupted(as i am copying consumer request content from splunk for testing) . will try to validate directly with consumers and update you

dchiesa1

@ummaniapigee wrote:

,looks when i am copying request content signature getting corrupted(as i am copying consumer request content from splunk for testing)

YES - this would cause the problem. Any modification of whitespace within the wssec:Security element inside the soap Header will cause the signature validation to fail. If, after you copy it from your Splunk system, you can manually modify the document to remove all spaces and newlines in that Security element, you might be able to get a subsequent signature validation on the modified document to succeed. It worked for me.

ummaniapigee

@dchiesa1

Hi Dino .here is the use case

APIGEE proxy Signing the payload and sending to Provider to validate .

Same proxy revision was deployed in 2 environments (Default -1 way SSL , Secure 2 way ssl ) between APIGEE and consumer .

Proxy deployed in Secure working as expected -- Providers successfully validate signed payload

Proxy deployed in default Not working -- Providers not able to validate signed payload .(looks signature modifying ) .no clue why its behaving differently in default environments .

Any pointers?

Thanks,

RaviKumar Ummani

dchiesa1

OK, so the behavior is dependent upon the environment into which it's deployed. Why would that occur?

First question: Where do you get your signing keys? Are they retrieved from a KVM, and is the KVM environment-scoped? That could be a difference that would result in the signature being different. Are the keys retrieved from a properties file? Or some other environment-scoped place? If so, verify that you are using the same keys , and the same certificate! in both environments. The private key is used to produce the signature, but the CERT is also important, because the contents of the cert is embedded into the signed document, during the signing process.

And maybe, the keys should be different. The upstream system is probably not the same. In most cases, the dev env is completely separate from stage and prod, so ... the upstream endpoints would be different, have different keys, and so on. In that case, on the Apigee side you'd need to verify, not that the keys were the same, but that they were correct.

@ummaniapigee wrote:

Providers not able to validate signed payload

2nd question: Do you have any insight into the failure, beyond "cannot validate"? Does the upstream system provide any insight into why? In the validation process, there are a bunch of checks - are the algorithms acceptable? are the signed elements sufficient? (I noted that your payload did not sign the Body element, and that's unusual. Maybe the upstream suystem in the prod environment is insisting that the Body must also be signed). Is it simply a "failed to validate signature", which indicates a key mismatch? Is the upstream saying the provided certificate is unacceptable? If the upstream provides more information, it might help you.

As for your observation that the signature looks different...every time you sign the document it will result in a different signature because the callout will inject a Timestamp of "now" into the Created/Expires elements. And that timestamp will be different each time, so the signature will be different each time. Currently, there is no way to override "now" in the signing logic. If this was possible in the callout, you'd be able to run tests with a specific timestamp, which would then produce a _stable_ signature each time you sign a document. I can take that as a feature request, but I think it probably won't be of much help to you, in this particular case. In any event, "signature looks different" - that should be true for any valid scenario. If the STRUCTURE of the signed document looks different, that would be more concerning. But that's not what I'm hearing from you.

ummaniapigee

@dchiesa1

1) Proxy Retrieving Keys from KVM which is in ORG level,

2) Providers are expecting to sign only TO element (which we are doing)

3) Providers confirmed that Payload which is coming in Both cases are identically same

4) Error which we are receiving from Provider in failure scenario is below

<s:Reason>

<s:Text xml:lang="en-US">At least one security token in the message could not be validated.</s:Text>

</s:Reason>

5) Same error i got when i tired to validate with direct endpoint using(payload from successfully validated request traces ) ,that could be because of signature alignment changes due to copy paste.

i am suspecting thats what happening when request transferring in default environments but not in Secure environments

dchiesa1

ahh, I see. The message you get from the upstream is a generic one. Not much information there.

I guess you will want to double-check all your keys and so on. Does the secure system (mTLS?) expect a different key than is used in the default system? Does the mTLS system expect the key+ cert that is used for WS-Sec signing, is the same as the key+cert that is used in TLS negotiation? Or is there some sort of relationship enforced on the upstream (mTLS) system that stipulates that different key+cert pairs should be used in Ws-Sec, depending on the key+cert used in TLS negotiation?

If you have a "known good" message that works with the mTLS endpoint, can you share it with me? If I modify the signing callout to allow injection or mock of the "now" value, we should be able to verify that the Apigee callout can produce and validate the known good signed payload.

Validating Signed payload in APIGEE using java calllout