Microsoft Technologies based on the .NET software framework. Miscellaneous topics that do not fit into specific categories.
Thank you, I have read it and I have tried it out, but you can't modify the security headers in this way. Only elements in de body of the message.
But I know now that my problem doesn't seem to be caused by the namespace prefix. I have been testing something with SoapUI. The receiver enabled the policy that requires a timestamp but disabled the policy that the timestamp must be signed. When I sent a message with SoapUI and I manually added a timestamp (not signed) to the message, I got an OK response back. I tried this both with a u: prefix and with a wsu: prefix in the timestamp and I got an OK response back in both cases. So the namespace prefix doesn't seem to make any difference.
When I send a message with a signed timestamp and a signed body and the receiver enables the require signed timestamp policy, the receiver get's the message "No signed timestamp present in Request". That's strange because when I look in the XML, I see that the timestamp is present and I see that there are two references in the Signature element: one for the timestamp and one for the body. When I validate the signature of this message with SignedXml, I get a valid result back. So the signature seems to be valid. When I modify one character in the timestamp or when I modify one character in the body, then the validation of the signature fails. So the signature really seems to be based on the body and the timestamp.
I actually have no idea what could be wrong. We use transport security and message security, all based on three certificates: one for the transport security, one for the message security encryption and one for the message security signature. The transport security is working fine. The encryption and decryption is also working fine. There is only a problem with the signature of the timestamp, but as I said, when I validate the signature with SignedXml, I get a valid result back.