For future reference, 'openssl x509 -noout -text -in [certfilename]'
will give a full list of everything in the certificate, in a text
format suitable for human comprehension without additional tools.
As a later message from you suggests you discovered, "failed to
validate signature" means one of two things: that the signature is
wrong on at least one of the certificates, or that the signature
generated by the remote side is wrong when checked against the public
key in the certificate that was presented. It is almost impossible to
get the "wrong" signature on a certificate from a 3rd-party CA -- they
take the public key in the request, add whatever they want to the
TBSCertificate structure, and then generate the hash of it and encrypt
that hash with their private key. (TBSCertificate is the content of
the certificate, without the signature. A certificate is a tuple of {
TBSCertificate, signatureAlgorithm, signatureData }. Once the
signature stuff is appended, any change to the TBSCertificate part
invalidates that signature*.)
It is possible for any party to present an incorrect certificate from
a 3rd-party CA. This can happen when that party's software loses
track of the private key that goes with the public key in the
certificate, and doesn't verify with a simple encryption/decryption on
load that the keys it has been provided actually go together. In my
experience, this symptom primarily occurs when a keypair is generated
and a certification request submitted, the certificate is received,
and is put in place without updating the file that contains the
private key.
And, for reference: 2.16.840.1.101.2.1 refers to the Department of
Defense infosec OID arc (ref: http://oid-info.com/2.16.840.1.101.2.1
). .11 is not documented at oid-info.com, which suggests to me that
those two might actually be policy OIDs. (I would be curious to see
the output of the aforementioned 'x509 -noout -text -in [filename]'
command on one of those certificates, if only because I'm curious
where those OIDs occur in the certificate. If you want, you can blank
out the Subject: and anything else that you think might provide too
much information.)
*: Recently, a weakness was discovered in the PKI, demonstrated with
mD5+RSA signatures. An MD5 collision attack was mounted against a
sub-CA of a public 3rd party CA, allowing a forged TBSCertificate
structure to have the same hash as the real sub-CA, without the main
CA necessarily knowing that its sub-CA signature has been compromised.
At this point, (almost?) all of the public 3rd party CAs have stopped
using MD5 for any offline-verifiable certifications they make.
Instead, they're using SHA-1... which will likely have the same class
of attacks applied to it in the next decade, since some attacks have
already made it equivalent to 71 bits of protection (from its nominal
160). Unfortunately, it's also the only other signature algorithm
which can be expected to exist almost everywhere. If you want
references, I'll look 'em up, but the one about 71 bits of protection
by SHA-1 is actually from the CSRC at NIST in (I believe) its latest
cryptography guidance for federal agencies. The MD5 collision attack
was demonstrated and is explained at
http://www.win.tue.nl/hashclash/rogue-ca/ .
(And, for what it's worth: if you've got DoD OIDs embedded in your
certificate, you're not going to be using MD5 or even likely SHA-1,
you're probably going to be using at least SHA-256. This strengthens
the lifetime of the PKI, but the design flaw that led to it needs to
be addressed -- the CCITT/ITU placed all their faith in "hash
algorithms that cannot practically be predicted for any input", not
realizing that prediction would thus become one of the field's largest
research interests.)
-Kyle H
On Fri, Oct 2, 2009 at 4:18 PM, <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
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-us...@openssl.org
> Automated List Manager majord...@openssl.org
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
