Hardware client certificates moving to Centos 7

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Hardware client certificates moving to Centos 7

Stuart Marsden
Hi

I have Centos/Apache servers for securely provisioning IP phones using hardware client certificates embedded in the phones.

for this test I have allowed all protocols and ciphers

on Centos 6 this works fine, the rpms are:

openssl098e-0.9.8e-20.el6.centos.1.x86_64
openssl-1.0.1e-57.el6.x86_64
openssl-devel-1.0.1e-57.el6.x86_64

on centos 7 the rpms are:

openssl098e-0.9.8e-29.el7.centos.3.x86_64
openssl-1.0.2k-8.el7.x86_64
openssl-libs-1.0.2k-8.el7.x86_64
xmlsec1-openssl-1.2.20-7.el7_4.x86_64
openssl-devel-1.0.2k-8.el7.x86_64

on Centos 7 the logging with "Loglevel debug"  in the apache config file is a lot less than Centos 6


The SSL fails to establish with the error below:


ssl_engine_kernel.c(1890): [client XX.XX.31.200:47576] AH02043: SSL virtual host for servername xxxxxxxx found

ssl_engine_kernel.c(1360): [client XX.XX.31.200:47576] AH02275: Certificate Verification, depth 1, CRL checking mode: none [subject: emailAddress=[hidden email],CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: emailAddress=[hidden email],CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: E17F3D266C47321E / notbefore: Nov  7 12:45:52 2013 GMT / notafter: Nov  7 12:45:52 2033 GMT]

ssl_engine_kernel.c(1360): [client xx.xx.31.200:47576] AH02275: Certificate Verification, depth 0, CRL checking mode: none [subject: emailAddress=[hidden email],CN=001565c8be6f,OU=Yealink Equipment,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: emailAddress=[hidden email],CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: 303031353635633862653666 / notbefore: Mar  1 00:00:00 2014 GMT / notafter: Feb 24 00:00:00 2034 GMT]

[ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH02276: Certificate Verification: Error (7): certificate signature failure [subject: emailAddress=[hidden email],CN=001565c8be6f,OU=Yealink Equipment,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: emailAddress=[hidden email],CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: 303031353635633862653666 / notbefore: Mar  1 00:00:00 2014 GMT / notafter: Feb 24 00:00:00 2034 GMT]

[ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH02008: SSL library error 1 in handshake (server xxx.xxx.xxx.xxx:443)
[ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm
[ssl:info] [pid 1611] SSL Library Error: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed
[ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH01998: Connection closed to child 3 with abortive shutdown


It fails across several phone vendors.

Any suggestions greatly received, thanks in advance

Stuart


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Hardware client certificates moving to Centos 7

Verhelst Wouter (Consultant)
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
Reply | Threaded
Open this post in threaded view
|

Re: Hardware client certificates moving to Centos 7

Stuart Marsden
Sorry how can I tell ?

I can run a wireshark if necessary

thanks


> On 26 Sep 2017, at 16:36, Wouter Verhelst <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Hardware client certificates moving to Centos 7

Robert Moskowitz
In reply to this post by Stuart Marsden


On 09/26/2017 11:26 AM, Stuart Marsden wrote:

> Hi
>
> I have Centos/Apache servers for securely provisioning IP phones using hardware client certificates embedded in the phones.
>
> for this test I have allowed all protocols and ciphers
>
> on Centos 6 this works fine, the rpms are:
>
> openssl098e-0.9.8e-20.el6.centos.1.x86_64
> openssl-1.0.1e-57.el6.x86_64
> openssl-devel-1.0.1e-57.el6.x86_64
>
> on centos 7 the rpms are:
>
> openssl098e-0.9.8e-29.el7.centos.3.x86_64
> openssl-1.0.2k-8.el7.x86_64
> openssl-libs-1.0.2k-8.el7.x86_64
> xmlsec1-openssl-1.2.20-7.el7_4.x86_64
> openssl-devel-1.0.2k-8.el7.x86_64
>
> on Centos 7 the logging with "Loglevel debug"  in the apache config file is a lot less than Centos 6
>
>
> The SSL fails to establish with the error below:
>
>
> ssl_engine_kernel.c(1890): [client XX.XX.31.200:47576] AH02043: SSL virtual host for servername xxxxxxxx found
>
> ssl_engine_kernel.c(1360): [client XX.XX.31.200:47576] AH02275: Certificate Verification, depth 1, CRL checking mode: none [subject: emailAddress=[hidden email],CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: emailAddress=[hidden email],CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: E17F3D266C47321E / notbefore: Nov  7 12:45:52 2013 GMT / notafter: Nov  7 12:45:52 2033 GMT]

Please provide a complete dump of the hardware certificate.  There may
be a subjectAltName with fields that require an hex dump.  I want to see
if these are IEEE 802.1AR certificates...

If they are, they are suppose to be used to provision an owner (lDevID)
certificate.  But they should be usable; they may be ECDSA certs.

You can see some examples on how to create (and display) ECDSA 802.1AR
certs in:

https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/


>
> ssl_engine_kernel.c(1360): [client xx.xx.31.200:47576] AH02275: Certificate Verification, depth 0, CRL checking mode: none [subject: emailAddress=[hidden email],CN=001565c8be6f,OU=Yealink Equipment,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: emailAddress=[hidden email],CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: 303031353635633862653666 / notbefore: Mar  1 00:00:00 2014 GMT / notafter: Feb 24 00:00:00 2034 GMT]
>
> [ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH02276: Certificate Verification: Error (7): certificate signature failure [subject: emailAddress=[hidden email],CN=001565c8be6f,OU=Yealink Equipment,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: emailAddress=[hidden email],CN=Yealink Equipment Issuing CA,OU=yealink.com,O=Yealink Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: 303031353635633862653666 / notbefore: Mar  1 00:00:00 2014 GMT / notafter: Feb 24 00:00:00 2034 GMT]
>
> [ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH02008: SSL library error 1 in handshake (server xxx.xxx.xxx.xxx:443)
> [ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm
> [ssl:info] [pid 1611] SSL Library Error: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed
> [ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH01998: Connection closed to child 3 with abortive shutdown
>
>
> It fails across several phone vendors.
>
> Any suggestions greatly received, thanks in advance
>
> Stuart
>
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Hardware client certificates moving to Centos 7

Kyle Hamilton
In reply to this post by Stuart Marsden
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.)

-Kyle H


On Tue, Sep 26, 2017 at 8:56 AM, Stuart Marsden <[hidden email]> wrote:

> Sorry how can I tell ?
>
> I can run a wireshark if necessary
>
> thanks
>
>
>> On 26 Sep 2017, at 16:36, Wouter Verhelst <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:
>> Sorry how can I tell ?
>>
>> I can run a wireshark if necessary
>>
>> thanks
>>
>>
>>> On 26 Sep 2017, at 16:36, Wouter Verhelst <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Hardware client certificates moving to Centos 7

Stuart Marsden
In reply to this post by Kyle Hamilton
Hi

I think I know what you are going to say - MD5?

I ran openssl s_server -verify , then ran the x509 command as you suggested using the captured client certificate

This phone model has only just gone into production,  and I am using a "preview version" of the hardware

Is there a way a can install  a version of openssl on a dedicated standalone Centos 7 server which will support these phones?

That would be preferable to me than having to leave Centos 6 servers just for this

Thanks everyone for your help sofar 

Stuart


openssl x509 -noout -text -in yealink.pem 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            30:30:31:35:36:35:63:38:62:65:36:66
    Signature Algorithm: md5WithRSAEncryption
        Issuer: C=CN, ST=Fujian, L=Xiamen, O=Yealink Network Technology Co.,Ltd., OU=yealink.com, CN=Yealink Equipment Issuing [hidden email]
        Validity
            Not Before: Mar  1 00:00:00 2014 GMT
            Not After : Feb 24 00:00:00 2034 GMT
        Subject: C=CN, ST=Fujian, L=Xiamen, O=Yealink Network Technology Co.,Ltd., OU=Yealink Equipment, [hidden email]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:e9:22:52:1a:47:bf:06:4d:2e:86:4f:61:5e:f8:
                    70:47:7f:c7:7d:4d:1e:b7:9f:0d:38:d2:79:8e:e9:
                    47:88:f3:f1:dd:75:d0:b3:d7:72:da:aa:e8:72:12:
                    7e:67:5c:c1:63:f3:6e:54:48:f7:46:a8:1c:fe:6a:
                    96:13:87:31:68:bb:89:98:b5:45:8d:c2:ef:24:a0:
                    47:7c:bf:20:d6:88:6b:95:4b:3a:f4:90:ec:a1:b2:
                    8a:4e:f9:2a:01:02:ba:f9:7f:52:b7:5f:71:18:d4:
                    40:74:56:75:94:e1:2e:ed:87:69:5a:33:ca:51:45:
                    06:ce:5e:5d:f1:ff:c1:5f:2f
                Exponent: 65537 (0x10001)
    Signature Algorithm: md5WithRSAEncryption
         74:a9:f7:02:52:51:86:c9:09:15:c9:2e:32:1b:29:81:b6:d0:
         a9:7a:88:61:5a:fe:22:3e:6d:68:e3:71:64:e2:12:1f:5a:0e:
         35:54:19:b8:4a:e5:a1:70:27:0f:3b:99:ae:db:d1:bc:77:39:
         22:0a:4d:71:a9:08:ca:c4:e0:28:a6:a0:e4:bc:9d:56:c1:ad:
         49:4b:5c:70:b2:a7:e8:64:ef:fa:fa:c0:1c:89:92:63:c5:67:
         55:ab:d9:65:57:4b:a8:6e:59:a6:d3:4b:ff:9b:27:8b:0e:ea:
         ac:71:de:6c:5d:97:c7:78:17:40:4b:03:79:81:1b:02:31:6c:
         fa:01:4a:c2:e2:c2:d6:14:4c:ff:9a:1c:41:ed:14:c2:eb:b4:
         f5:1b:db:06:d7:1f:e3:bc:69:d0:f7:d6:8e:13:db:7b:f1:15:
         5c:11:b9:18:56:6b:d3:0f:96:20:99:a3:19:01:83:9a:f2:65:
         4d:7d:6b:41:92:d2:d1:4d:40:74:b7:8b:a8:54:ba:bf:b0:04:
         0e:a0:45:5b:62:c1:0e:7b:48:7d:c8:96:62:99:50:e7:44:b1:
         8a:01:e0:ec:b7:42:6c:3d:52:16:70:3b:0f:e6:e3:31:8b:31:
         ee:62:fd:fd:3c:94:90:04:05:99:7b:b2:c0:41:8f:92:05:db:
         46:a6:2d:ed:ba:e5:70:61:45:52:a4:f0:97:54:cf:75:9d:8b:
         f9:89:f2:01:0e:7f:f7:b6:1f:1c:03:56:a6:cc:d0:00:99:b9:
         f1:e3:6b:18:d5:69:46:38:a3:23:ba:f3:76:08:ff:02:bc:15:
         df:91:67:6e:94:62:35:34:a2:fa:d3:33:01:da:00:b6:07:4c:
         89:7e:f3:98:dc:81:e5:0f:4a:19:ea:fe:91:02:3a:9d:22:25:
         a9:38:f8:2f:91:ca:09:e1:6c:12:b2:68:a6:a2:af:8b:41:f7:
         61:e5:40:2f:98:60:18:10:90:af:55:50:8a:31:2d:17:82:d2:
         13:cf:27:5b:fa:c8:ee:74:e1:98:00:26:56:24:68:38:b4:e3:
         21:ee:3c:8b:16:32:72:93:fc:3b:0f:13:9a:b1:97:e8:6e:ca:
         33:00:ee:7b:30:7c:e2:e7:14:99:a0:5f:f1:f9:95:1f:fc:5c:
         17:79:33:2a:f1:fd:89:6e:50:d8:d7:8d:05:95:3f:11:72:c7:
         69:e8:0f:4c:82:7b:9d:26:86:04:60:b2:3b:24:76:4a:34:c6:
         87:ef:e6:e7:8b:53:98:de:f4:cc:d8:39:b2:2d:ea:09:a4:80:
         f3:c2:d7:bd:6f:7b:7d:4c:35:b2:23:ca:56:fc:5b:6d:08:05:
         6b:11:bd:c6:4b:92:4f:46


On 27 Sep 2017, at 01:04, Kyle Hamilton <[hidden email]> 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.)

-Kyle H


On Tue, Sep 26, 2017 at 8:56 AM, Stuart Marsden <[hidden email]> wrote:
Sorry how can I tell ?

I can run a wireshark if necessary

thanks


On 26 Sep 2017, at 16:36, Wouter Verhelst <[hidden email]> 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




--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Hardware client certificates moving to Centos 7

Robert Moskowitz


On 09/27/2017 08:07 AM, Stuart Marsden wrote:
Hi

I think I know what you are going to say - MD5?

Lots of problems with that cert.  If you have some connection with the vendor, have them read IEEE 802.1AR-2009 standard for Device Identity credentials.  You will be supporting this phone different from those that follow the standard.


I ran openssl s_server -verify , then ran the x509 command as you suggested using the captured client certificate

This phone model has only just gone into production,  and I am using a "preview version" of the hardware

Is there a way a can install  a version of openssl on a dedicated standalone Centos 7 server which will support these phones?

I run Centos7 on arm platforms  There are lots of ways to run dedicated C7 servers.  Talk about this on the Centos-user or Centos-arm list.


That would be preferable to me than having to leave Centos 6 servers just for this

A lot of years until EOL for Centos6.  They just did it for C5...


Thanks everyone for your help sofar 

Stuart


openssl x509 -noout -text -in yealink.pem 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            30:30:31:35:36:35:63:38:62:65:36:66
    Signature Algorithm: md5WithRSAEncryption
        Issuer: C=CN, ST=Fujian, L=Xiamen, O=Yealink Network Technology Co.,Ltd., OU=yealink.com, CN=Yealink Equipment Issuing [hidden email]
        Validity
            Not Before: Mar  1 00:00:00 2014 GMT
            Not After : Feb 24 00:00:00 2034 GMT
        Subject: C=CN, ST=Fujian, L=Xiamen, O=Yealink Network Technology Co.,Ltd., OU=Yealink Equipment, [hidden email]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:e9:22:52:1a:47:bf:06:4d:2e:86:4f:61:5e:f8:
                    70:47:7f:c7:7d:4d:1e:b7:9f:0d:38:d2:79:8e:e9:
                    47:88:f3:f1:dd:75:d0:b3:d7:72:da:aa:e8:72:12:
                    7e:67:5c:c1:63:f3:6e:54:48:f7:46:a8:1c:fe:6a:
                    96:13:87:31:68:bb:89:98:b5:45:8d:c2:ef:24:a0:
                    47:7c:bf:20:d6:88:6b:95:4b:3a:f4:90:ec:a1:b2:
                    8a:4e:f9:2a:01:02:ba:f9:7f:52:b7:5f:71:18:d4:
                    40:74:56:75:94:e1:2e:ed:87:69:5a:33:ca:51:45:
                    06:ce:5e:5d:f1:ff:c1:5f:2f
                Exponent: 65537 (0x10001)
    Signature Algorithm: md5WithRSAEncryption
         74:a9:f7:02:52:51:86:c9:09:15:c9:2e:32:1b:29:81:b6:d0:
         a9:7a:88:61:5a:fe:22:3e:6d:68:e3:71:64:e2:12:1f:5a:0e:
         35:54:19:b8:4a:e5:a1:70:27:0f:3b:99:ae:db:d1:bc:77:39:
         22:0a:4d:71:a9:08:ca:c4:e0:28:a6:a0:e4:bc:9d:56:c1:ad:
         49:4b:5c:70:b2:a7:e8:64:ef:fa:fa:c0:1c:89:92:63:c5:67:
         55:ab:d9:65:57:4b:a8:6e:59:a6:d3:4b:ff:9b:27:8b:0e:ea:
         ac:71:de:6c:5d:97:c7:78:17:40:4b:03:79:81:1b:02:31:6c:
         fa:01:4a:c2:e2:c2:d6:14:4c:ff:9a:1c:41:ed:14:c2:eb:b4:
         f5:1b:db:06:d7:1f:e3:bc:69:d0:f7:d6:8e:13:db:7b:f1:15:
         5c:11:b9:18:56:6b:d3:0f:96:20:99:a3:19:01:83:9a:f2:65:
         4d:7d:6b:41:92:d2:d1:4d:40:74:b7:8b:a8:54:ba:bf:b0:04:
         0e:a0:45:5b:62:c1:0e:7b:48:7d:c8:96:62:99:50:e7:44:b1:
         8a:01:e0:ec:b7:42:6c:3d:52:16:70:3b:0f:e6:e3:31:8b:31:
         ee:62:fd:fd:3c:94:90:04:05:99:7b:b2:c0:41:8f:92:05:db:
         46:a6:2d:ed:ba:e5:70:61:45:52:a4:f0:97:54:cf:75:9d:8b:
         f9:89:f2:01:0e:7f:f7:b6:1f:1c:03:56:a6:cc:d0:00:99:b9:
         f1:e3:6b:18:d5:69:46:38:a3:23:ba:f3:76:08:ff:02:bc:15:
         df:91:67:6e:94:62:35:34:a2:fa:d3:33:01:da:00:b6:07:4c:
         89:7e:f3:98:dc:81:e5:0f:4a:19:ea:fe:91:02:3a:9d:22:25:
         a9:38:f8:2f:91:ca:09:e1:6c:12:b2:68:a6:a2:af:8b:41:f7:
         61:e5:40:2f:98:60:18:10:90:af:55:50:8a:31:2d:17:82:d2:
         13:cf:27:5b:fa:c8:ee:74:e1:98:00:26:56:24:68:38:b4:e3:
         21:ee:3c:8b:16:32:72:93:fc:3b:0f:13:9a:b1:97:e8:6e:ca:
         33:00:ee:7b:30:7c:e2:e7:14:99:a0:5f:f1:f9:95:1f:fc:5c:
         17:79:33:2a:f1:fd:89:6e:50:d8:d7:8d:05:95:3f:11:72:c7:
         69:e8:0f:4c:82:7b:9d:26:86:04:60:b2:3b:24:76:4a:34:c6:
         87:ef:e6:e7:8b:53:98:de:f4:cc:d8:39:b2:2d:ea:09:a4:80:
         f3:c2:d7:bd:6f:7b:7d:4c:35:b2:23:ca:56:fc:5b:6d:08:05:
         6b:11:bd:c6:4b:92:4f:46


On 27 Sep 2017, at 01:04, Kyle Hamilton <[hidden email]> 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.)

-Kyle H


On Tue, Sep 26, 2017 at 8:56 AM, Stuart Marsden <[hidden email]> wrote:
Sorry how can I tell ?

I can run a wireshark if necessary

thanks


On 26 Sep 2017, at 16:36, Wouter Verhelst <[hidden email]> 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







--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Hardware client certificates moving to Centos 7

Jochen Bern
In reply to this post by Stuart Marsden
On 09/27/2017 02:07 PM, Stuart Marsden <[hidden email]> wrote:
> Is there a way a can install  a version of openssl on a dedicated standalone
> Centos 7 server which will support these phones?
> That would be preferable to me than having to leave Centos 6 servers just
> for this

I don't know offhand which OpenSSL versions did away with MD5, but you
*can* install an 0.9.8e (+ RHEL/CentOS backported security patches)
straight off CentOS 7 repos:

https://centos.pkgs.org/7/centos-x86_64/openssl098e-0.9.8e-29.el7.centos.3.x86_64.rpm.html

(There's a 32bit version of the RPM, too, of course, if you need it.)

Kind regards,
--
Jochen Bern
Systemingenieur

www.binect.de


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Hardware client certificates moving to Centos 7

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Jochen Bern
> Sent: Wednesday, September 27, 2017 06:51
> To: [hidden email]
> Subject: Re: [openssl-users] Hardware client certificates moving to Centos 7
>
> I don't know offhand which OpenSSL versions did away with MD5, but you
> *can* install an 0.9.8e (+ RHEL/CentOS backported security patches)
> straight off CentOS 7 repos:

Ugh. No need for 0.9.8e (which is from, what, the early Industrial Revolution?). MD5 is still available in OpenSSL 1.0.2, assuming it wasn't disabled in the build configuration. I think Stuart is dealing with an OpenSSL build that had MD5 disabled in the Configure step.

Heck, MD4 and MDC2 are still available in 1.0.2 - even with the default configuration, I believe. I'm looking at 1.0.2j here and it has GOST, MD4, MD5, MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard lengths), and Whirlpool.

That's just for digests, obviously; but the point is the MD5 support is still there. And yes, 1.0.2j can handle certificates with md5WithRsaEncryption signatures.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Hardware client certificates moving to Centos 7

Freemon Johnson
Not sure if this helps but the native installation for CentOS7 by default installs OpenSSL with FIPS mode compiled in which means deprecated algorithms such as MD5 and the like will not work. If you tried to generate a certificate you should have received an error or not have seen that algorithm in your certificate etc. 

As others have suggested you will have to end building a version of OpenSSL with FIPS mode disabled in order to use MD5 unless you can get a version from the Centos repo mirrors without FIPS. 

The default output from "openssl version" in CentOS7

OpenSSL 1.0.1e-fips 11 Feb 2013


On Wed, Sep 27, 2017 at 2:02 PM, Michael Wojcik <[hidden email]> wrote:
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Jochen Bern
> Sent: Wednesday, September 27, 2017 06:51
> To: [hidden email]
> Subject: Re: [openssl-users] Hardware client certificates moving to Centos 7
>
> I don't know offhand which OpenSSL versions did away with MD5, but you
> *can* install an 0.9.8e (+ RHEL/CentOS backported security patches)
> straight off CentOS 7 repos:

Ugh. No need for 0.9.8e (which is from, what, the early Industrial Revolution?). MD5 is still available in OpenSSL 1.0.2, assuming it wasn't disabled in the build configuration. I think Stuart is dealing with an OpenSSL build that had MD5 disabled in the Configure step.

Heck, MD4 and MDC2 are still available in 1.0.2 - even with the default configuration, I believe. I'm looking at 1.0.2j here and it has GOST, MD4, MD5, MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard lengths), and Whirlpool.

That's just for digests, obviously; but the point is the MD5 support is still there. And yes, 1.0.2j can handle certificates with md5WithRsaEncryption signatures.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
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
Reply | Threaded
Open this post in threaded view
|

Re: Hardware client certificates moving to Centos 7

Jeffrey Walton-3
In reply to this post by Michael Wojcik
>> I don't know offhand which OpenSSL versions did away with MD5, but you
>> *can* install an 0.9.8e (+ RHEL/CentOS backported security patches)
>> straight off CentOS 7 repos:
>
> Ugh. No need for 0.9.8e (which is from, what, the early Industrial Revolution?). MD5 is still available in OpenSSL 1.0.2, assuming it wasn't disabled in the build configuration. I think Stuart is dealing with an OpenSSL build that had MD5 disabled in the Configure step.
>
> Heck, MD4 and MDC2 are still available in 1.0.2 - even with the default configuration, I believe. I'm looking at 1.0.2j here and it has GOST, MD4, MD5, MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard lengths), and Whirlpool.

Some of those algorithms may still needed for some use cases. For
example, Apple still ships (or used to ship until recently) some
certificates that use MD2. They were present in iOS 7 and 8. Also see
http://seclists.org/fulldisclosure/2013/Sep/184.

I think the best OpenSSL can for now is allow those who don't need
antique algorithms to disable them at compile time. Otherwise, OpenSSL
is making policy decisions that may not work well for some folks.

Jeff
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Hardware client certificates moving to Centos 7

Freemon Johnson
FIPS mode is a policy decision in my opinion also but since RedHat prides itself in security e.g. SELinux, etc. I believe that is a RedHat decision as opposed to the OpenSSL community. The alternative would be to use a different Linux distro like Ubuntu, etc. which does not compile their OpenSSL with FIPS enabled natively to support legacy algorithms.

FYI I am not speaking on behalf of RedHat or OpenSSL. This is all conjecture and my 2 cents :-)

On Wed, Sep 27, 2017 at 3:15 PM, Jeffrey Walton <[hidden email]> wrote:
>> I don't know offhand which OpenSSL versions did away with MD5, but you
>> *can* install an 0.9.8e (+ RHEL/CentOS backported security patches)
>> straight off CentOS 7 repos:
>
> Ugh. No need for 0.9.8e (which is from, what, the early Industrial Revolution?). MD5 is still available in OpenSSL 1.0.2, assuming it wasn't disabled in the build configuration. I think Stuart is dealing with an OpenSSL build that had MD5 disabled in the Configure step.
>
> Heck, MD4 and MDC2 are still available in 1.0.2 - even with the default configuration, I believe. I'm looking at 1.0.2j here and it has GOST, MD4, MD5, MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard lengths), and Whirlpool.

Some of those algorithms may still needed for some use cases. For
example, Apple still ships (or used to ship until recently) some
certificates that use MD2. They were present in iOS 7 and 8. Also see
http://seclists.org/fulldisclosure/2013/Sep/184.

I think the best OpenSSL can for now is allow those who don't need
antique algorithms to disable them at compile time. Otherwise, OpenSSL
is making policy decisions that may not work well for some folks.

Jeff
--
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
Reply | Threaded
Open this post in threaded view
|

Re: Hardware client certificates moving to Centos 7

Jochen Bern
In reply to this post by Stuart Marsden
On 09/27/2017 10:10 PM, Michael Wojcik wrote:
> On Behalf Of Jochen Bern
> Sent: Wednesday, September 27, 2017 06:51
>> I don't know offhand which OpenSSL versions did away with MD5, but you
>> *can* install an 0.9.8e (+ RHEL/CentOS backported security patches)
>> straight off CentOS 7 repos
>
> Ugh. No need for 0.9.8e (which is from, what, the early Industrial Revolution?).

You and I would probably be willing to compile version $CURRENT_STABLE
ourselves if needed, but then again, a dedicated CentOS 6 server would
likely be fine with us as well. I presume that Stuart has an auditor
breathing down his neck and itching to tick "current OS release of
chosen standard distribs, only reputable / vendor repos configured,
updates installed in regular intervals, no sources used or compilers
installed, paid-support-request- and sue-for-damages forms prefilled in
the drawer" checkboxes.

Kind regards,
--
Jochen Bern
Systemingenieur

www.binect.de


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Hardware client certificates moving to Centos 7

Michael Wojcik
In reply to this post by Jeffrey Walton-3
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Jeffrey Walton
> Sent: Wednesday, September 27, 2017 13:15
> To: OpenSSL Users
> Subject: Re: [openssl-users] Hardware client certificates moving to Centos 7
>
> >
> > Heck, MD4 and MDC2 are still available in 1.0.2 - even with the default
> configuration, I believe. I'm looking at 1.0.2j here and it has GOST, MD4, MD5,
> MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard lengths), and Whirlpool.
>
> Some of those algorithms may still needed for some use cases. For
> example, Apple still ships (or used to ship until recently) some
> certificates that use MD2. They were present in iOS 7 and 8. Also see
> http://seclists.org/fulldisclosure/2013/Sep/184.
>
> I think the best OpenSSL can for now is allow those who don't need
> antique algorithms to disable them at compile time. Otherwise, OpenSSL
> is making policy decisions that may not work well for some folks.

Oh, definitely. I wasn't suggesting we should get rid of them. Just wanted to point out that it wasn't necessary to go back to a stone-age release of OpenSSL to have them.

Though, as subsequent people pointed out, I did not account for FIPS mode. Why anyone would install a FIPS build by default is beyond me (particularly since the FIPS validation is so picky about OS versions and the like). Though, of course, the application using OpenSSL need not enable FIPS mode...

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Hardware client certificates moving to Centos 7

Stuart Marsden
In reply to this post by Michael Wojcik
Hi

thanks for all the comments and suggestions, especially the ones I could understand

centos 7
yum upgrade

openssl version gives:

OpenSSL 1.0.2k-fips  26 Jan 2017


it looks like 

echo 'LegacySigningMDs md5' >> /etc/pki/tls/legacy-settings

allows the reading of Md5 Client certificates (which are still being installed in "not released yet" phones)

That is a week of my life I wont get back

thanks again

Stuart


On 27 Sep 2017, at 19:02, Michael Wojcik <[hidden email]> wrote:

From: openssl-users [[hidden email]] On Behalf
Of Jochen Bern
Sent: Wednesday, September 27, 2017 06:51
To: [hidden email]
Subject: Re: [openssl-users] Hardware client certificates moving to Centos 7

I don't know offhand which OpenSSL versions did away with MD5, but you
*can* install an 0.9.8e (+ RHEL/CentOS backported security patches)
straight off CentOS 7 repos:

Ugh. No need for 0.9.8e (which is from, what, the early Industrial Revolution?). MD5 is still available in OpenSSL 1.0.2, assuming it wasn't disabled in the build configuration. I think Stuart is dealing with an OpenSSL build that had MD5 disabled in the Configure step.

Heck, MD4 and MDC2 are still available in 1.0.2 - even with the default configuration, I believe. I'm looking at 1.0.2j here and it has GOST, MD4, MD5, MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard lengths), and Whirlpool.

That's just for digests, obviously; but the point is the MD5 support is still there. And yes, 1.0.2j can handle certificates with md5WithRsaEncryption signatures.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



Dr Stuart Marsden
Tel: +44 (0)1494 414100
Email: [hidden email]

Altos Banner


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Hardware client certificates moving to Centos 7

Robert Moskowitz


On 09/28/2017 01:25 PM, Stuart Marsden wrote:
Hi

thanks for all the comments and suggestions, especially the ones I could understand

centos 7
yum upgrade

openssl version gives:

OpenSSL 1.0.2k-fips  26 Jan 2017


it looks like 

echo 'LegacySigningMDs md5' >> /etc/pki/tls/legacy-settings

allows the reading of Md5 Client certificates (which are still being installed in "not released yet" phones)

I am almost concerned this is being done intentionally to meet some security downgrade requirement.  I the more reason to only use this cert to bootstrap your own cert for the actual management.



That is a week of my life I wont get back

thanks again

Stuart


On 27 Sep 2017, at 19:02, Michael Wojcik <[hidden email]> wrote:

From: openssl-users [[hidden email]] On Behalf
Of Jochen Bern
Sent: Wednesday, September 27, 2017 06:51
To: [hidden email]
Subject: Re: [openssl-users] Hardware client certificates moving to Centos 7

I don't know offhand which OpenSSL versions did away with MD5, but you
*can* install an 0.9.8e (+ RHEL/CentOS backported security patches)
straight off CentOS 7 repos:

Ugh. No need for 0.9.8e (which is from, what, the early Industrial Revolution?). MD5 is still available in OpenSSL 1.0.2, assuming it wasn't disabled in the build configuration. I think Stuart is dealing with an OpenSSL build that had MD5 disabled in the Configure step.

Heck, MD4 and MDC2 are still available in 1.0.2 - even with the default configuration, I believe. I'm looking at 1.0.2j here and it has GOST, MD4, MD5, MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard lengths), and Whirlpool.

That's just for digests, obviously; but the point is the MD5 support is still there. And yes, 1.0.2j can handle certificates with md5WithRsaEncryption signatures.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



Dr Stuart Marsden
Tel: +44 (0)1494 414100
Email: [hidden email]

Altos Banner





--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users