[openssl-users] 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  found

ssl_engine_kernel.c(1360): [client XX.XX.31.200:47576] AH02275: Certificate 
Verification, depth 1, CRL checking mode: none [subject: 
emailAddress=supp...@yealink.com,CN=Yealink Equipment Issuing 
CA,OU=yealink.com,O=Yealink Network Technology 
Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: 
emailAddress=supp...@yealink.com,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=supp...@yealink.com,CN=001565c8be6f,OU=Yealink Equipment,O=Yealink 
Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: 
emailAddress=supp...@yealink.com,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=supp...@yealink.com,CN=001565c8be6f,OU=Yealink Equipment,O=Yealink 
Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: 
emailAddress=supp...@yealink.com,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

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

[Wouter Verhelst]

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

Re: [openssl-users] 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  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

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

[Robert Moskowitz]

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  found

ssl_engine_kernel.c(1360): [client XX.XX.31.200:47576] AH02275: Certificate 
Verification, depth 1, CRL checking mode: none [subject: 
emailAddress=supp...@yealink.com,CN=Yealink Equipment Issuing 
CA,OU=yealink.com,O=Yealink Network Technology 
Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: 
emailAddress=supp...@yealink.com,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=supp...@yealink.com,CN=001565c8be6f,OU=Yealink Equipment,O=Yealink 
Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: 
emailAddress=supp...@yealink.com,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=supp...@yealink.com,CN=001565c8be6f,OU=Yealink Equipment,O=Yealink 
Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: 
emailAddress=supp...@yealink.com,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

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

[Kyle Hamilton]

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  wrote:
> Sorry how can I tell ?
>
> I can run a wireshark if necessary
>
> thanks
>
>
>> On 26 Sep 2017, at 16:36, Wouter Verhelst  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

Re: [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  wrote:

Sorry how can I tell ?

I can run a wireshark if necessary

thanks



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

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

[Stuart Marsden]

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 
CA/emailAddress=supp...@yealink.com
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, CN=001565c8be6f/emailAddress=supp...@yealink.com
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  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  wrote:
>> Sorry how can I tell ?
>> 
>> I can run a wireshark if necessary
>> 
>> thanks
>> 
>> 
>>> On 26 Sep 2017, at 16:36, Wouter Verhelst  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-u

Re: [openssl-users] 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 CA/emailAddress=supp...@yealink.com 


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, 
CN=001565c8be6f/emailAddress=supp...@yealink.com 


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 > 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 > wrote:

Sorry how can I tell ?

I can run a wireshark if necessary

thanks


On 26 Sep 2017, at 16:36, Wouter Verhelst 
mailto:wouter.verhe...@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 me

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

[Jochen Bern]

On 09/27/2017 02:07 PM, Stuart Marsden  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



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Jochen Bern
> Sent: Wednesday, September 27, 2017 06:51
> To: openssl-users@openssl.org
> 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

Re: [openssl-users] 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 <
michael.woj...@microfocus.com> wrote:

> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> > Of Jochen Bern
> > Sent: Wednesday, September 27, 2017 06:51
> > To: openssl-users@openssl.org
> > 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

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

[Jeffrey Walton]

>> 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

Re: [openssl-users] 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  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

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

[Jochen Bern]

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



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] 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

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

[Stuart Marsden]

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  
> wrote:
> 
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
>> Of Jochen Bern
>> Sent: Wednesday, September 27, 2017 06:51
>> To: openssl-users@openssl.org
>> 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: stu...@myphones.com <mailto:stu...@myphones.com> 



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

Re: [openssl-users] 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 
<mailto:michael.woj...@microfocus.com>> wrote:



From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Jochen Bern
Sent: Wednesday, September 27, 2017 06:51
To: openssl-users@openssl.org <mailto:openssl-users@openssl.org>
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:* stu...@myphones.com <mailto:stu...@myphones.com>

Altos Banner





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