On 09/26/2017 08:04 PM, Kyle Hamilton wrote:
openssl x509 -noout -text -in clientcertificate.pem
You may need to extract the client certificate from wireshark, but you
could also get it from openssl s_server.
Specifically, that error message is suggesting that there's a message
digest encoded into the certificate which is unknown to the trust
path.
Chances are, it's probably MD5. MD5 was broken a long time ago, and
is no longer trustworthy. (SHA1 is also a possibility, but it was
made unacceptable a lot more recently.)
If it IS a 802.1AR RSA cert (the original drivers for 802.1AR was
protecting VoIP phones), 802.1AR-2009 says:
6.3.5.1 RSA Signing
If the key is an RSA key, then this operation shall generate a PKCS1
signature as defined in RFC 3447 with
the signature algorithm of RSASSA-PKCS1-v1_5, for maximum interoperability.
The currentEncoding specifies the current encoding of the data. The
dataOctets are partially encoded for
RFC 3447 signing prior to calling this DevID module interface. A value
of PKCS1HASH_SHA256
indicates that the dataOctets are a SHA256 hash of the original data as
specified by RFC 3447 id-sha256.
The DevID Module will continue encoding the data, starting at RFC 3447
Section 9.2 step 2, by building
and padding the DigestInfo ASN.1 value and then building the full PKCS1
signature.
A currentEncoding value of PKCS1DIGESTINFO_OPAQUE indicates that the
dataOctets are already
encoded into the equivalent of the RFC 3447 Section 9.2 step 2 specified
DigestInfo. The DevID Module
will continue encoding the data, starting at RFC 3447 Section 9.2 step
3, by padding the dataOctet as
specified for the DigestInfo ASN.1 value, and then building the full
PKCS1 signature.
NOTE—Some uses of PKCS1 specify an alternative to the RFC 3447
DigestInfo structure. For example TLS 1.1 RFC4346 specifies “a 36-byte
structure of two hashes (one SHA and one MD5).” The use of
PKCS1DIGESTINFO_OPAQUE provides support for this type of construct. It
also provides a mechanism for
components leveraging the DeviceID Module to obtain PCKS1 signatures
using legacy hash algorithms such as SHA-1 or MD5.
And:
7.3.1 RSASSA-PKCS1-v1.5
The RSASSA-PKCS1-v1.5 signature method is defined in RFC 3447. The
algorithm shall be either
sha1WithRSAEncryption or sha256WithRSAEncryption. The algorithm
identifiers are:
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840)
rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840)
rsadsi(113549) pkcs(1) pkcs-1(1) 11 }
Support for sha1WithRSAEncryption is included for maximum
interoperability but is not recommended.
When the sha1WithRSAEncryption or sha256WithRSAEncryption algorithm
identifiers appear in the
algorithm field as an AlgorithmIdentifier, the encoding must omit the
parameters field. That is, the
AlgorithmIdentifier shall be a SEQUENCE of one component, the object
identifier
sha1WithRSAEncryption or sha256WithRSAEncryption.
-Kyle H
On Tue, Sep 26, 2017 at 8:56 AM, Stuart Marsden <stuart@xxxxxxxxxxxx> wrote:
Sorry how can I tell ?
I can run a wireshark if necessary
thanks
On 26 Sep 2017, at 16:36, Wouter Verhelst <wouter.verhelst@xxxxxxxxx> wrote:
On 26-09-17 17:26, Stuart Marsden wrote:
[ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm
So which message digest algorithm is the client trying to use?
--
Wouter Verhelst
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
