[openssl-users] Hardware client certificates moving to Centos 7

[Robert Moskowitz]

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 at myphones.com> 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 at fedict.be> 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