Re: [openssl-users] PKCS7 and RSA_verify

[ch]

Hello!

Thanks for the support.

On 2017-09-28 01:06, Dr. Stephen Henson wrote:

On Thu, Sep 28, 2017, ch wrote:


Hello!

I am working on a tool for verifying SMIME-messages.
Because cms and smime is only able to verify base64 pkcs7-signatures
I try to do it "manually" and I now have a problem with the
signing-timestamp.


I'm not sure what you mean by "only able to verify base64 pkcs7-signatures"
it can handle PEM and DER forms too.
If the pkcs-signature is binary encoded it is not working for verifiying 
a SMIME-message in my experience with
smime or cms-smime on the console. I tried to convert the binary ones to 
base64 but that does not everytime the trick.





Lets do an example:

openssl smime -sign -md sha1  -in plain.txt  -inkey mykey -signer
mycert  -noattr  -outform der | openssl asn1parse -inform der

If I put plain.txt and the 128 byte signature (from asn1parse out of
the pkcs7) into RSA_verify it works perfectly.
Every call would produce the same signature-hexdump.

But if I remove the -noattr the signature-value will be different
every second and then RSA_verify it not working anymore.

How can I handle this?


When you don't use attributes the signature is over performed over the
content. If you use attributes then the signature is over the encoding of a
bunch of attributes including a signing time and the digest of the content.
Because the signing time changes the data being signed in the attributes
changes too.
Would PKCS7_verify (or something else) handle that for me or do I need 
to consider that different

content with RSA_verify?


Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org


Again, thanks for the support!
chris
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] PKCS7 and RSA_verify

[Dr. Stephen Henson]

On Thu, Sep 28, 2017, ch wrote:

> Hello!
> 
> I am working on a tool for verifying SMIME-messages.
> Because cms and smime is only able to verify base64 pkcs7-signatures
> I try to do it "manually" and I now have a problem with the
> signing-timestamp.
> 

I'm not sure what you mean by "only able to verify base64 pkcs7-signatures"
it can handle PEM and DER forms too.

> Lets do an example:
> 
> openssl smime -sign -md sha1  -in plain.txt  -inkey mykey -signer
> mycert  -noattr  -outform der | openssl asn1parse -inform der
> 
> If I put plain.txt and the 128 byte signature (from asn1parse out of
> the pkcs7) into RSA_verify it works perfectly.
> Every call would produce the same signature-hexdump.
> 
> But if I remove the -noattr the signature-value will be different
> every second and then RSA_verify it not working anymore.
> 
> How can I handle this?
> 

When you don't use attributes the signature is over performed over the
content. If you use attributes then the signature is over the encoding of a
bunch of attributes including a signing time and the digest of the content.
Because the signing time changes the data being signed in the attributes
changes too.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] PKCS7 and RSA_verify

[ch]

Hello!

I am working on a tool for verifying SMIME-messages.
Because cms and smime is only able to verify base64 pkcs7-signatures I 
try to do it "manually" and I now have a problem with the signing-timestamp.


Lets do an example:

openssl smime -sign -md sha1  -in plain.txt  -inkey mykey -signer 
mycert  -noattr  -outform der | openssl asn1parse -inform der


If I put plain.txt and the 128 byte signature (from asn1parse out of the 
pkcs7) into RSA_verify it works perfectly.

Every call would produce the same signature-hexdump.

But if I remove the -noattr the signature-value will be different every 
second and then RSA_verify it not working anymore.


How can I handle this?

Thanks!

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

Re: [openssl-users] Storing private key on tokens

[Ken Goldman]

On 9/27/2017 2:19 PM, Dirk-Willem van Gulik wrote:



On 27 Sep 2017, at 20:02, Michael Wojcik

The tokens / HSMs I've used don't let you generate a key somewhere
else and install it on the token. They insist on doing the key
generation locally. That is, after all, part of the point of using
a token - the key never leaves it.


I've found that the Feitian ePass2000's and the Yubico keys allow for
importing of the private key. They do usually want the 'extra' flags
to specify use:


FWIW, the TPM hardware also permits key import.  It does validate 
attributes, so users will know that the key was not generated on chip.



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

[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

[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

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

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] Storing private key on tokens

[Dirk-Willem van Gulik]

> On 27 Sep 2017, at 20:02, Michael Wojcik  
> wrote:
> 
>> What is the most natural way to generate private keys using openssl but 
>> store them on a specific hardware tokens? 
>> Reading/writing is implemented via engine mechanism.
> 
> The tokens / HSMs I've used don't let you generate a key somewhere else and 
> install it on the token. They insist on doing the key generation locally. 
> That is, after all, part of the point of using a token - the key never leaves 
> it.

I've found that the Feitian ePass2000's and the Yubico keys allow for importing 
of the private key. They do usually want the 'extra' flags to specify use:

pkcs15-init --store-private-key .ssh/id_rsa-foo --auth-id 01 
--key-usage sign,decrypt --label "ssh key of m...@mydomain.com"

and some fail silently when you do not provide these.

Dw.

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

Re: [openssl-users] Storing private key on tokens

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Dmitry Belyavsky
> Sent: Wednesday, September 27, 2017 06:22
> To: openssl-users@openssl.org
> Subject: [openssl-users] Storing private key on tokens

> What is the most natural way to generate private keys using openssl but store 
> them on a specific hardware tokens? 
> Reading/writing is implemented via engine mechanism.

The tokens / HSMs I've used don't let you generate a key somewhere else and 
install it on the token. They insist on doing the key generation locally. That 
is, after all, part of the point of using a token - the key never leaves it.

Some tokens and HSMs support key backup and restore, e.g. Nitrokey HSM's DKEK 
share mechanism, but that's deliberately not open to "restoring" some arbitrary 
private key onto the device.

So this wouldn't make much sense for the pkcs11 engine, even if PKCS#11 
provided an API for it.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 


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

Re: [openssl-users] DH_generate_key Hangs

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Jason Qian via openssl-users
> Sent: Wednesday, September 27, 2017 07:00
> To: openssl-users@openssl.org
> Subject: [openssl-users] DH_generate_key Hangs

> Need some help,  one of our application that hangs when calling
> DH_generate_key (openssl-0.9.8y). This occurs randomly under loaded 
> condition.  
> Not sure, if anyone know this issue ?

The issue is running OpenSSL 0.9.8, which has not been supported since 2015.

DH_generate_key can use an engine (at least in supported versions of OpenSSL - 
I no longer have any 0.9.8 code around to check), so we really can't say what 
it might be doing in your application. But if it's using the default OpenSSL 
implementation, then if your DH parameters don't already include a private key, 
you'll end up generating random numbers. That can hang, if OpenSSL is using a 
blocking CPRNG source such as /dev/random.

But you haven't provided nearly enough information to do more than speculate.

What you need to do:

1. Upgrade to OpenSSL 1.0.2 (or possibly 1.1.0, but that has API changes and 
isn't an LTS release). There's really no point in proceeding unless you do so. 
Your application is broken if it's using 0.9.8.

2. If the problem still occurs, debug a hanging instance and find out where 
*exactly* it's hung.

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

[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] Storing private key on tokens

[Dirk-Willem van Gulik]

On 27 Sep 2017, at 14:22, Dmitry Belyavsky  wrote:

> What is the most natural way to generate private keys using openssl but store 
> them on a specific hardware tokens? Reading/writing is implemented via engine 
> mechanism.
> 
> I suppose that it should be added support of -outform ENGINE to the genpkey 
> command, but do not understatnd how to deal with it after that. 

The OpenSC tools integrate nicely (and the yubico toools too with a bit more 
fiddling).

You typically end up with constructs like:

${OPENSSL} << EOM || exit 1
engine dynamic -pre 
SO_PATH:/Library/OpenSC/lib/engines/engine_pkcs11.so \
-pre ID:pkcs11 \
-pre LIST_ADD:1 -pre LOAD \
-pre MODULE_PATH:opensc-pkcs11.so \
\
XXX -engine pkcs11 -key slot_$SLOT-id_$KID -keyform 
engine YY
EOM

where ‘XX’ and ‘YYY’ are the openssl command and arguments. The slot 
information of existing keys does usually need OpenSC or similar; as there is 
no easy syntaxtic sugar to get access for the engine (AFAIK):

set `pkcs11-tool --module /Library/OpenSC/lib/opensc-pkcs11.so 
--list-slots | grep Slot | grep SCM`
SLOT=$2
set `pkcs15-tool --list-keys | grep ID`
AID=$4
KID=$7

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

[openssl-users] DH_generate_key Hangs

[Jason Qian via openssl-users]

Hi,

Need some help,  one of our application that hangs when calling
DH_generate_key (openssl-0.9.8y). This occurs randomly under loaded
condition.
Not sure, if anyone know this issue ?


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

Re: [openssl-users] Storing private key on tokens

[Blumenthal, Uri - 0553 - MITLL]

AFAIK, at this point pkcs11 engine doesn't support key generation. 

The only viable options AFAIK are OpenSC (pkcs11-tool) and vendor-specific 
applications like yubico-piv-tool.

Regards,
Uri

Sent from my iPhone

> On Sep 27, 2017, at 08:23, Dmitry Belyavsky  wrote:
> 
> Hello,
> 
> What is the most natural way to generate private keys using openssl but store 
> them on a specific hardware tokens? Reading/writing is implemented via engine 
> mechanism.
> 
> I suppose that it should be added support of -outform ENGINE to the genpkey 
> command, but do not understatnd how to deal with it after that. 
> 
> Thank you!
> 
> -- 
> SY, Dmitry Belyavsky
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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

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


On 26-09-17 17:26, Stuart Marsden wrote:
[ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 
encoding 

[openssl-users] Storing private key on tokens

[Dmitry Belyavsky]

Hello,

What is the most natural way to generate private keys using openssl but
store them on a specific hardware tokens? Reading/writing is implemented
via engine mechanism.

I suppose that it should be added support of -outform ENGINE to the genpkey
command, but do not understatnd how to deal with it after that.

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
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

Re: [openssl-users] How to load the right engine?

[Dmitry Belyavsky]

Hello,

I usually use strace for this purpose.

On Wed, Sep 27, 2017 at 12:53 AM, Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> I’m debugging programmatic access to a (modified) pkcs11 engine. My system
> has several OpenSSL installations: Apple-provided OpenSSL-0.9.8 (kept as
> that came with the OS :), Macports-installed OpenSSL-1.0.2l (the main one
> installed to /opt/local, used by everything Macports builds, and what I use
> mostly for my software), and a couple of OpenSSL-1.1.x installations mostly
> used for debugging.
>
>
>
> Libp11 is installed in /opt/local/lib/engines, and that version is built
> for/compatible with OpenSSL-1.0.2.
>
>
>
> There’s an installation of OpenSSL-1.1.0-stable in ~/openssl-1.1. libp11
> built for 1.1 is installed in ~/openssl-1.1/lib/engines-1.1 directory. So
> far so good.
>
>
>
> The problem I’m having now is – my application appears to be getting the
> wrong pkcs11 engine (the one for 1.0.2), based on the error message I get
> on decrypting, which is indicative of the unmodified libp11 version (not
> the one I’m working with for 1.1).
>
>
>
> Question: how do I ensure/verify that the right pkcs11 library is loaded?
>
>
>
> Tail of openssl.cnf:
>
>
>
> [pkcs11_section]
>
>engine_id = pkcs11
>
>dynamic_path = /Users/ur20980/openssl-1.1/lib/engines-1.1/pkcs11.dylib
>
>MODULE_PATH = /usr/local/lib/yubihsm_pkcs11.dylib
>
>init = 0
>
>
>
>
>
> Thanks!
>
> --
>
> Regards,
>
> Uri Blumenthal
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
SY, Dmitry Belyavsky
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users