---- oh...@cox.net wrote: > > ---- oh...@cox.net wrote: > > Hi, > > > > I want to preface this by first saying that I know that this question is > > probably pretty broad, but I'm hoping that someon on this list might be > > able to help. > > > > We are working with web services our SOAP messages have SAML assertions > > that are digitally signed. > > > > So, on the web service "client" side, we have a private key and a > > corresponding certificate, and on the web service "server" side, we have > > the certificate which is used for the validation of the digital signature. > > > > We've been in development and testing for awhile, using certs from an > > in-house CA, but now we're moving to a new environment, where the certs > > have to be issued by a 3rd party CA, but since doing that, we have > > encountered a problem where, on the server side, we are getting "failed to > > validate signature". > > > > We have a couple of different configurations, one where the web service end > > is hosted on WebLogic, and another where the web service end is on an XML > > appliance, and we are having similar "failed to validate signature" > > problems with both. > > > > Also, on the XML appliance, we can configure it to do just the signature > > validation without verifying the certificate chain, so we're pretty sure > > that the problem is not a chaining problem. > > > > We're not 100% sure, but we've eliminate almost every other possibility, > > and appears that the problem may be that, for some reason, the certs that > > we got are not suitable for validating digital signatures. > > > > The 3rd party CA can issue "SSL Server certificates" or "SSL Client > > certificates", and, right now, the certs that we have been trying to use > > are "SSL Server certificates" (as designated by the CA). We've looked at > > the certificates using various tools, including "keytool", "openssl x509", > > and they look "ok". > > > > The certs have Key Usage of: > > > > Digital Signature > > Key Encipherment > > Key Agreement > > > > they also have a "Netscape type" of "SSL Server Authentication". > > > > Finally, they have to extension OIDs: > > > > 2.16.840.1.101.2.1.11.7 > > 2.16.840.1.101.2.1.11.8 > > > > Finally, I have to again say that we're still not 100% sure if the problem > > is the certs, but we've eliminated everything else that we can think of, so > > I was hoping that maybe someone might have some experience that might tell > > us what might possibly be going on with these certs that might prevent them > > from being used for digital signature validation? > > > > Thanks in advance. > > > > Jim > > > > > > Hi, > > I did some additional testing, and it appears that those enhanced usage > extension OIDs may be making the certificate unuseable for signature > validation: > > 1) I put a sniffer on the line, to capture the SOAP message with the signed > assertion. I have a small Java app that I wrote awhile ago, that takes a > SOAP message with a signed assertion, and attempts to validate the assertion > signature. When I ran that on the SOAP message that I captured from the > sniffer, the signature validation was SUCCESSFUL! So, I thought that this > implied that there was something about the certificate that was preventing it > being used for signature validation. > > 2) I then created a new SSL server certificate that was exactly the same as > the original certificate, but I did not include the two extensions/OIDs. I > then installed this new cert into my test configuration and tested, and I no > longer got the signature validation error!! > > So, I'm concluding that those two extensions/OIDs in the certificate are > causing the signature validation to fail. > > Does anyone have any idea WHY those two extensions/OIDs might be preventing > the cert from being used for signature validation? > > Thanks, > Jim
Hi, For the record, we were able to figure out this problem today, and it was not the OIDs. Also, in a way, it turned out to be a problem (mostly) on the signing side, rather than on the validation side. The problem was that the cert and the key that was used for the signing were not "matched". We were able to determine this using the procedure with openssl at: http://kb.wisc.edu/middleware/page.php?id=4064 Jim ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
