[openssl-users] public version of encode_pkcs1

[William Roberts]

I would like to use OpenSSL to compute the DigestInfo structure to
pass to a TPM for a TPM side RSA_Decrypt() operation when the TPM
doesn't support the digest algorithm.

I see in crypt/rsa_sign.c the routine encode_pkcs1() seems to do what
I want. Is their
a public version of this or a better way to do this?

I could just use the pre-computed ASN1 headers from the Notes section
in RFC3447 and concatenate the digest but my initial reaction to that
idea is don't do it.

Thoughts or ideas?

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

Re: [openssl-users] Path Length Constraint ignored for Root and any self-issued certificate

[Erwann Abalea via openssl-users]

Bonjour,

The prospective certification path excludes the Trust Anchor.
Therefore, the « max_path_length=0 » step is attained only when dealing with 
your EvilCA cert.

Cordialement,
Erwann Abalea

> Le 8 oct. 2018 à 14:47, Peter Magnusson  a 
> écrit :
> 
> That is not correct behaviour as far as I can understand.
> 
> RFC5280 Certification Path Validation algorithm process from root to
> leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> Preparation for Certificate i+1 is expected to occur upon Root
> certificate, i.e. the following should be expected behaviour:
> * max_path_length=n (initialisation)
> * max_path_length=n-1 (first decrement)
> * max_path_length=0 (copied from root certificate constraint)
> * VERIFY(max_path_length>0) error upon preparing transition from i=1
> (Root) to i=2 (EvilCA).
> 
> OpenSSL does everything in a slightly different reverse algorithm, but
> should perform the same controls and behaivor as the RFC imho.
> 
> And aside from the RFC algorithm checking for this condition, it is
> also analog with the description of the expected behaviour:
> 
>   The pathLenConstraint field is meaningful only if the cA boolean is
>   asserted and the key usage extension, if present, asserts the
>   keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
>   maximum number of non-self-issued intermediate certificates that may
>   follow this certificate in a valid certification path.  (Note: The
>   last certificate in the certification path is not an intermediate
>   certificate, and is not included in this limit.  Usually, the last
>   certificate is an end entity certificate, but it can be a CA
>   certificate.)  A pathLenConstraint of zero indicates that no non-
>   self-issued intermediate CA certificates may follow in a valid
>   certification path.  Where it appears, the pathLenConstraint field
>   MUST be greater than or equal to zero.  Where pathLenConstraint does
>   not appear, no limit is imposed.
> 
> So my understanding is that the OpenSSL algorithm is confused and
> fails to perform a check that is applicable to self-issued
> certificates. The decrement of max_path_length (aka plen++ in OpenSSL
> implementation) should not occur for self issued certificates, but the
> validation of max_path_length>0 (aka plen>(constraint+1)) should
> occur.
> On Mon, Oct 8, 2018 at 1:27 PM J Decker  wrote:
>> 
>> It was my interpretation that 0 pathlen on the root self signed meant 
>> infinite.
>> The pathlen only applies on the certs between root and the leaf (which 
>> obviously can be 0, and CA true or not, but bad form to say true I'd 
>> imagine.)
>> 
>> On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson 
>>  wrote:
>>> 
>>> One more logic confusion in the OpenSSL Path Length Constraint check.
>>> Any Path Length Constraint set by Root (or any other Self-Issued
>>> Certificate) is ignored.
>>> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
>>> applied to the checker (i.e. the checker and the calculation logic
>>> have been mixed up).
>>> 
>>> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
>>> 
>>> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
>>>Certificate Sign, CRL Sign
>>>X509v3 Basic Constraints: critical
>>>CA:TRUE, pathlen:0
>>> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
>>>Certificate Sign, CRL Sign
>>>X509v3 Basic Constraints: critical
>>>CA:TRUE, pathlen:0
>>> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
>>>X509v3 extensions:
>>>X509v3 Basic Constraints: critical
>>>CA:FALSE
>>> 
>>> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
>>>X509v3 extensions:
>>>X509v3 Subject Key Identifier:
>>>49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>> --
>>> --
>>>49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>>X509v3 Authority Key Identifier:
>>> 
>>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
>>>X509v3 extensions:
>>>X509v3 Subject Key Identifier:
>>>B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>>> --
>>> --
>>>B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>>>X509v3 Authority Key Identifier:
>>> 
>>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
>>>TLS Web Server Authentication
>>>X509v3 Subject Key Identifier:
>>>03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>>> --
>>> --
>>>03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>>>X509v3 Authority Key Identifier:

Re: [openssl-users] Incompatible Object error from EC_POINT_mul (Nicola)

[John Hughes]

 5 13:31:09 g3r1 named[32429]: threads support is enabled

Oct  5 13:31:09 g3r1 named[32429]:


Oct  5 13:31:09 g3r1 named[32429]: BIND 9 is maintained by Internet Systems
Consortium,

Oct  5 13:31:09 g3r1 named[32429]: Inc. (ISC), a non-profit 501(c)(3)
public-benefit

Oct  5 13:31:09 g3r1 named[32429]: corporation.  Support and training for
BIND 9 are

Oct  5 13:31:09 g3r1 named[32429]: available at https://www.isc.org/support

Oct  5 13:31:09 g3r1 named[32429]:


Oct  5 13:31:09 g3r1 named[32429]: adjusted limit on open files from 4096 to
1048576

Oct  5 13:31:09 g3r1 named[32429]: found 1 CPU, using 1 worker thread

Oct  5 13:31:09 g3r1 named[32429]: using 1 UDP listener per interface

Oct  5 13:31:09 g3r1 named[32429]: using up to 4096 sockets

Oct  5 13:31:09 g3r1 named[32429]: openssl_link.c:296: fatal error:

Oct  5 13:31:09 g3r1 named[32429]: OpenSSL pseudorandom number generator
cannot be initialized (see the `PRNG not seeded' message in the OpenSSL FAQ)





Thanks & Regards,



Aakash kumar

ITE - India

Tower B, 8th Floor, DLF Infinity Towers,

DLF Cyber City Phase - II

Gurgaon - 122002, Haryana, INDIA

aakash.ku...@orange.com



  Mobile: +91-8527288977

  CVS: 7357 3706







-Original Message-
From: Viktor Dukhovni [mailto:openssl-us...@dukhovni.org]
Sent: 05 October 2018 21:23
To: KUMAR Aakash IMT/OINIS
Cc: osf-cont...@openssl.org; SRIVASTAVA Himanshu IMT/OINIS; VARSHNEY Praveen
IMT/OINIS
Subject: Re: osf-contact Latest Openssl Issue with Bind 9.12.2-P2 on RHEL
7.5





Please try to send the text of error reports, not pictures.



> I am getting below error while starting the bind service.

>

> 



If you ask on the openssl-users list, someone else may have seen

the same issue, and may have useful advice to share.



NOTE!!!:  I've set the Reply-To: address to .

If you just hit "Reply", your answer may go to the list, though you'd

need to join the list first to be able to post...



Does the error still happen when you disable "chroot" in BIND?

Perhaps BIND is doing late initialization of the PRNG after

entering the chroot jail, and maybe trying to use "/dev/urandom",

which not be in the jail?  That's a wild guess.  You'd need to

trace system calls to see what it is actually doing...



--

Viktor.




_

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce message par
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed,
used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

-- next part --
An HTML attachment was scrubbed...
URL:
<http://mta.openssl.org/pipermail/openssl-users/attachments/20181008/9a4c315
f/attachment-0001.html>

--

Message: 3
Date: Mon, 8 Oct 2018 10:35:33 +0300
From: Nicola 
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Incompatible Object error from
EC_POINT_mul
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hi,

I did not run this in the debugger, but one issue is that you are not
initializing `pub` before calling EC_POINT_mul : try adding

pub = EC_POINT_new(curve);
(and check for errors making sure pub is not null afterwards).

Hope this helps!


Best regards,

Nicola


On Mon, Oct 8, 2018, 00:31 John Hughes  wrote:

> I'm trying to generate a public key from a private key generated on a 
> HSM (and obtained by calling PKCS#11). Everything works fine until I 
> call EC_POINT_mul - at which point I get the error message:
>
>error:100BB065:elliptic curve routines:ec_wNAF_mul:incompatible 
> objects
>
> I have checked the BIGNUM conversion - and that seems to be fine. The 
> key pair on the HSM is also generated using brainpoolP256r1.
>
> The basis of the code can be found at the end of the email. I'm 
> basically trying to follow the example provided in:
> https://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography.
>
> I'm using openssl 1.10h
>
> Any pointers or help would be appreciated.
>
>
> John
>
> -

Re: [openssl-users] Issue with using TLS

[Matt Caswell]

On 08/10/18 16:43, Sean Glazier wrote:
> Hi,
> 
> I have an issue with using a TLS client-server set up.
> 
> on the client side I am using 32 open ssl library version 1.1 and the
> same set on the server side in VA smalltalk. Both are on windows.
> 
> On the c side I set the SSL_CTX_new(TLS_client_method()) on the server I
> restricted to TLS only as per our security policy.
> 
> I get through the hand shake and the client sends data over to the
> sever. however upon reading the server gives and openSSL error as follows:
> OpenSSLError
> Error Code: 336130315
> Error Object: ('wrong version number')
> Error String: 'error:1408F10B:SSL routines:ssl3_get_record:wrong version
> number'
> Error Hint: 'ssl3_get_record:wrong version number'
> AuxiliaryData: nil. 

This usually occurs if the data that is received doesn't look like TLS,
either because it is corrupted or is some other protocol. The TLS record
version number is the first thing we check, so if you've got bad data
then this is the first error you hit.

> 
> I have attempted to work around this by setting on the server side the
> following option:  SSL_OP_TLS_ROLLBACK_BUG . I saw from forums that this
> will tell the server to ignore this bug. However, I still get the same bug.

Don't do that. That option is an ancient client bug workaround that
should not be necessary in modern code.


> Does anyone know the workaround for this issue? 

Send me a wireshark trace of a failing connection and I can take a look
at it.

Matt


>  
> Kind Regards,
>  
> Sean Glazier
>  
> 
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Path Length Constraint ignored for Root and any self-issued certificate

[Viktor Dukhovni]

> On Oct 8, 2018, at 8:47 AM, Peter Magnusson  
> wrote:
> 
> RFC5280 Certification Path Validation algorithm process from root to
> leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> Preparation for Certificate i+1 is expected to occur upon Root
> certificate, i.e. the following should be expected behaviour:
> * max_path_length=n (initialisation)
> * max_path_length=n-1 (first decrement)
> * max_path_length=0 (copied from root certificate constraint)
> * VERIFY(max_path_length>0) error upon preparing transition from i=1
> (Root) to i=2 (EvilCA).

Well, strictly speaking, the trust-anchor is not part of the certificate
chain in RFC5280, it is a public key and an issuer name, not a certificate
in the chain.  However, when the trust-anchor is in the form of a self-signed
CA certificate, one might take the view that this is a self-issued certificate
to be included in the chain:

 trust anchor -> self-issued root CA cert (i = 1) -> ... -> EE (i = n)

in which case the "path lenth: 0" in the self-issed root CA cert precludes
the root from issuing any subsidiary CAs that can in turn issue further
EE certs.  That is perhaps reasonable, so I updated PR #7353 with
a further commit:

  
https://github.com/openssl/openssl/pull/7353/commits/02804dbd04180bdb87046bcd7581f9ba9cb2baf3

Does that address your concerns?

-- 
Viktor.

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

[openssl-users] Issue with using TLS

[Sean Glazier]

Hi,

I have an issue with using a TLS client-server set up.

on the client side I am using 32 open ssl library version 1.1 and the same
set on the server side in VA smalltalk. Both are on windows.

On the c side I set the SSL_CTX_new(TLS_client_method()) on the server I
restricted to TLS only as per our security policy.

I get through the hand shake and the client sends data over to the sever.
however upon reading the server gives and openSSL error as follows:
OpenSSLError
Error Code: 336130315
Error Object: ('wrong version number')
Error String: 'error:1408F10B:SSL routines:ssl3_get_record:wrong version
number'
Error Hint: 'ssl3_get_record:wrong version number'
AuxiliaryData: nil.

I have attempted to work around this by setting on the server side the
following option:  SSL_OP_TLS_ROLLBACK_BUG . I saw from forums that this
will tell the server to ignore this bug. However, I still get the same bug.

Does anyone know the workaround for this issue?

Kind Regards,

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

Re: [openssl-users] How to build libcrypto64*.lib and libssl64*.lib on Windows 64-bit?

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Short, Todd via openssl-users
> Sent: Monday, October 08, 2018 09:56

> Looks to be debug (d) and multi-thread (MT?) versions of the libraries; not 
> sure what MD stands for.

It's Microsoft's naming convention for their C runtime. MT is multithreaded, 
statically linked; MD is multithreaded, dynamically linked. The "d" suffix is, 
as Todd guessed, the debug version.

This is important with Microsoft Visual C, because the various runtimes do not 
play together. Their heaps, iobs, etc are separate. So, for example, if you 
link your program with the MT runtime and with a library that was linked with 
the MD runtime, and your code tries to free memory allocated by the library, 
you'll get a heap exception (if you're lucky) or heap corruption.

You can get away with mixed runtimes if you're careful - if every module frees 
the storage it allocates, and you don't try to create a FILE* in one and use it 
in another, and so on. Nonetheless, it's a gaping architectural flaw, and some 
packages try to accommodate it by providing equivalent versions of their 
libraries.

Todd may well be correct that OP is looking at a LibreSSL package, not an 
OpenSSL one. (LibreSSL isn't "a wrapper for OpenSSL", but whatever.)

--
Michael Wojcik
Distinguished Engineer, Micro Focus


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

Re: [openssl-users] osf-contact Latest Openssl Issue with Bind 9.12.2-P2 on RHEL 7.5

[Porter, Andrew]

See the error message about looking at the FAQ? Here it is:

https://www.openssl.org/docs/faq.html#USER1

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
aakash.ku...@orange.com
Sent: Sunday, October 07, 2018 22:51
To: openssl-users@openssl.org
Cc: osf-cont...@openssl.org
Subject: Re: [openssl-users] osf-contact Latest Openssl Issue with Bind 
9.12.2-P2 on RHEL 7.5


Hi Team,



Please find below error in text format.



[root@g3r1 ~]# systemctl status bind -l

● bind.service - LSB: DNS Daemon

   Loaded: loaded (/etc/rc.d/init.d/bind)

   Active: active (exited) since Fri 2018-10-05 13:31:09 CEST; 2 days ago

 Docs: man:systemd-sysv-generator(8)

  Process: 32417 ExecStop=/etc/rc.d/init.d/bind stop (code=exited, 
status=0/SUCCESS)

  Process: 32421 ExecStart=/etc/rc.d/init.d/bind start (code=exited, 
status=0/SUCCESS)



Oct 05 13:31:09 g3r1 named[32429]: 


Oct 05 13:31:09 g3r1 named[32429]: adjusted limit on open files from 4096 to 
1048576

Oct 05 13:31:09 g3r1 named[32429]: found 1 CPU, using 1 worker thread

Oct 05 13:31:09 g3r1 named[32429]: using 1 UDP listener per interface

Oct 05 13:31:09 g3r1 named[32429]: using up to 4096 sockets

Oct 05 13:31:09 g3r1 named[32429]: openssl_link.c:296: fatal error:

Oct 05 13:31:09 g3r1 named[32429]: OpenSSL pseudorandom number generator cannot 
be initialized (see the `PRNG not seeded' message in the OpenSSL FAQ)

Oct 05 13:31:09 g3r1 named[32429]: exiting (due to fatal error in library)

Oct 05 13:31:09 g3r1 bind[32421]: [13B blob data]

Oct 05 13:31:09 g3r1 systemd[1]: Started LSB: DNS Daemon.





[root@g3r1 ~]# tail /var/log/message

Oct  5 13:31:09 g3r1 systemd: Starting LSB: DNS Daemon...

Oct  5 13:31:09 g3r1 bind: /etc/rc.d/init.d/bind: line 36: log_info_msg: 
command not found

Oct  5 13:31:09 g3r1 named[32429]: starting BIND 9.12.2-P2 

Oct  5 13:31:09 g3r1 named[32429]: running on Linux x86_64 
3.10.0-327.13.1.el7.x86_64 #1 SMP Mon Feb 29 13:22:02 EST 2016

Oct  5 13:31:09 g3r1 named[32429]: built with '--prefix=/usr' 
'--sysconfdir=/etc' '--localstatedir=/var' 'mandir=/usr/share/man' 
'--enable-threads' '--with-libtool' '--with-openssl=/usr/local/ssl' 
'--disable-static' '--with-randomdev=/dev/urandom'

Oct  5 13:31:09 g3r1 named[32429]: running as: named -u named -t /srv/named -c 
/etc/named.conf

Oct  5 13:31:09 g3r1 named[32429]: compiled by GCC 4.8.5 20150623 (Red Hat 
4.8.5-28)

Oct  5 13:31:09 g3r1 named[32429]: compiled with OpenSSL version: OpenSSL 
1.0.2p  14 Aug 2018

Oct  5 13:31:09 g3r1 named[32429]: linked to OpenSSL version: OpenSSL 1.0.2p  
14 Aug 2018

Oct  5 13:31:09 g3r1 named[32429]: compiled with zlib version: 1.2.7

Oct  5 13:31:09 g3r1 named[32429]: linked to zlib version: 1.2.7

Oct  5 13:31:09 g3r1 named[32429]: threads support is enabled

Oct  5 13:31:09 g3r1 named[32429]: 


Oct  5 13:31:09 g3r1 named[32429]: BIND 9 is maintained by Internet Systems 
Consortium,

Oct  5 13:31:09 g3r1 named[32429]: Inc. (ISC), a non-profit 501(c)(3) 
public-benefit

Oct  5 13:31:09 g3r1 named[32429]: corporation.  Support and training for BIND 
9 are

Oct  5 13:31:09 g3r1 named[32429]: available at https://www.isc.org/support

Oct  5 13:31:09 g3r1 named[32429]: 


Oct  5 13:31:09 g3r1 named[32429]: adjusted limit on open files from 4096 to 
1048576

Oct  5 13:31:09 g3r1 named[32429]: found 1 CPU, using 1 worker thread

Oct  5 13:31:09 g3r1 named[32429]: using 1 UDP listener per interface

Oct  5 13:31:09 g3r1 named[32429]: using up to 4096 sockets

Oct  5 13:31:09 g3r1 named[32429]: openssl_link.c:296: fatal error:

Oct  5 13:31:09 g3r1 named[32429]: OpenSSL pseudorandom number generator cannot 
be initialized (see the `PRNG not seeded' message in the OpenSSL FAQ)





Thanks & Regards,



Aakash kumar

ITE - India

Tower B, 8th Floor, DLF Infinity Towers,

DLF Cyber City Phase - II

Gurgaon - 122002, Haryana, INDIA

aakash.ku...@orange.com



  Mobile: +91-8527288977

  CVS: 7357 3706







-Original Message-
From: Viktor Dukhovni [mailto:openssl-us...@dukhovni.org]
Sent: 05 October 2018 21:23
To: KUMAR Aakash IMT/OINIS
Cc: osf-cont...@openssl.org; SRIVASTAVA Himanshu IMT/OINIS; VARSHNEY Praveen 
IMT/OINIS
Subject: Re: osf-contact Latest Openssl Issue with Bind 9.12.2-P2 on RHEL 7.5





Please try to send the text of error reports, not pictures.



> I am getting below error while starting the bind service.

>

> 



If you ask on the openssl-users list, someone else may have seen

the same issue, and may have useful advice to share.



NOTE!!!:  I've set the Reply-To: address to .

If you just hit "Reply", your answer may go to the list, though you'd

need to join the list first to be able to post...



Does the error still happen when you disable "chroot" in BIND?

Perhaps BIND is doing late initialization of the PRNG after

entering the 

Re: [openssl-users] Path Length Constraint ignored for Root and any self-issued certificate

[Peter Magnusson]

Tested mbedtls to see how other code bases handle thus.

mbedtls rejects the EvilCA certificate when connecting to openssl
s_server (as opposed to openssl c_client -verify that accepts the
connection).

Verify requested for (Depth 1):
cert. version : 3
serial number : 10:00
issuer name   : C=SE, ST=Root, L=Root, O=Root, OU=Root, CN=Root
subject name  : C=SE, ST=EvilCA, L=EvilCA, O=EvilCA, OU=EvilCA, CN=EvilCA
issued  on: 2018-10-08 08:20:21
expires on: 2028-10-05 08:20:21
signed using  : RSA with SHA-256
RSA key size  : 4096 bits
basic constraints : CA=true, max_pathlen=0
key usage : Key Cert Sign, CRL Sign
  ! The certificate is not correctly signed by the trusted CA

The handshake fails after this error, mbedtls_ssl_handshake returned -9984.
On Mon, Oct 8, 2018 at 2:51 PM Peter Magnusson
 wrote:
>
> sorry, typo on the verify line, this was what I should have written:
> VERIFY(max_path_length>0) error upon preparing transition from i=2
> (EvilCA) to i=2 (EvilServer).
> On Mon, Oct 8, 2018 at 2:47 PM Peter Magnusson
>  wrote:
> >
> > That is not correct behaviour as far as I can understand.
> >
> > RFC5280 Certification Path Validation algorithm process from root to
> > leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> > Preparation for Certificate i+1 is expected to occur upon Root
> > certificate, i.e. the following should be expected behaviour:
> > * max_path_length=n (initialisation)
> > * max_path_length=n-1 (first decrement)
> > * max_path_length=0 (copied from root certificate constraint)
> > * VERIFY(max_path_length>0) error upon preparing transition from i=1
> > (Root) to i=2 (EvilCA).
> >
> > OpenSSL does everything in a slightly different reverse algorithm, but
> > should perform the same controls and behaivor as the RFC imho.
> >
> > And aside from the RFC algorithm checking for this condition, it is
> > also analog with the description of the expected behaviour:
> >
> >The pathLenConstraint field is meaningful only if the cA boolean is
> >asserted and the key usage extension, if present, asserts the
> >keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
> >maximum number of non-self-issued intermediate certificates that may
> >follow this certificate in a valid certification path.  (Note: The
> >last certificate in the certification path is not an intermediate
> >certificate, and is not included in this limit.  Usually, the last
> >certificate is an end entity certificate, but it can be a CA
> >certificate.)  A pathLenConstraint of zero indicates that no non-
> >self-issued intermediate CA certificates may follow in a valid
> >certification path.  Where it appears, the pathLenConstraint field
> >MUST be greater than or equal to zero.  Where pathLenConstraint does
> >not appear, no limit is imposed.
> >
> > So my understanding is that the OpenSSL algorithm is confused and
> > fails to perform a check that is applicable to self-issued
> > certificates. The decrement of max_path_length (aka plen++ in OpenSSL
> > implementation) should not occur for self issued certificates, but the
> > validation of max_path_length>0 (aka plen>(constraint+1)) should
> > occur.
> > On Mon, Oct 8, 2018 at 1:27 PM J Decker  wrote:
> > >
> > > It was my interpretation that 0 pathlen on the root self signed meant 
> > > infinite.
> > > The pathlen only applies on the certs between root and the leaf (which 
> > > obviously can be 0, and CA true or not, but bad form to say true I'd 
> > > imagine.)
> > >
> > > On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson 
> > >  wrote:
> > >>
> > >> One more logic confusion in the OpenSSL Path Length Constraint check.
> > >> Any Path Length Constraint set by Root (or any other Self-Issued
> > >> Certificate) is ignored.
> > >> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
> > >> applied to the checker (i.e. the checker and the calculation logic
> > >> have been mixed up).
> > >>
> > >> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
> > >>
> > >> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
> > >> Certificate Sign, CRL Sign
> > >> X509v3 Basic Constraints: critical
> > >> CA:TRUE, pathlen:0
> > >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
> > >> Certificate Sign, CRL Sign
> > >> X509v3 Basic Constraints: critical
> > >> CA:TRUE, pathlen:0
> > >> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
> > >> X509v3 extensions:
> > >> X509v3 Basic Constraints: critical
> > >> CA:FALSE
> > >> 
> > >> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
> > >> X509v3 extensions:
> > >> X509v3 Subject Key Identifier:
> > >> 
> > >> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> > >> --
> 

Re: [openssl-users] How to build libcrypto64*.lib and libssl64*.lib on Windows 64-bit?

[Short, Todd via openssl-users]

Could that be LibreSSL? (Or some similar wrapper for OpenSSL?)

https://github.com/Ruzzz/LibreSSL

This above repo creates libraries in the named format below; to match how 
Microsoft provides multiple versions of libraries.

Looks to be debug (d) and multi-thread (MT?) versions of the libraries; not 
sure what MD stands for.

Also:
https://gitlab.kitware.com/cmake/cmake/commit/ed1758f8eb58a4e52acf0f3885f82403814f5ffd


--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Oct 2, 2018, at 11:59 AM, Richard Levitte 
mailto:levi...@openssl.org>> wrote:

Our scripts have *never*, as far as I know, produced libraries named
like that.  Don't those DLLs come from some specific packager that
produces binary install kits?

For 1.1.x, *our* naming is a bit more elaborate, you will see these
names:

   libcrypto-1_1.dll & libssl-1_1.dll   - VC-WIN32 build
   libcrypto-1_1-x64.dll & libssl-1_1-x64.dll   - VC-WIN64A build
   libcrypto-1_1-ia64.dll & libssl-1_1-ia64.dll - VC-WIN64I build

You will also see the corresponding import libraries: libcrypto.lib &
libssl.lib

Cheers,
Richard

In message 
mailto:byapr17mb2150827bb4432c4b7edaf69ddf...@byapr17mb2150.namprd17.prod.outlook.com>>
 on Mon, 1 Oct 2018 16:29:15 +, 
mailto:aaron.frie...@non.keysight.com>> said:

A current project using Net-SNMP and OpenSSL require that these both are built 
locally (customer
requirement).

I am attempting to build OpenSSL 1.1.1.

After building OpenSSL, “nmake test” succeeds.

However, the Net-SNMP build is looking for various .lib files that are in the 
pre-built package, but
do not seem to be in what I build locally.

From the pre-built package, in the lib/VC folder:

libcrypto64MD.lib

libcrypto64MDd.lib

libcrypto64MT.lib

libcrypto64MTd.lib

libssl64MD.lib

libssl64MDd.lib

libssl64MT.lib

libssl64MTd.lib

But the VC folder is not part of my locally built version.

What am I missing in order to get these .lib files to build locally?

Thank you for your assistance.

Best Regards,
Aaron Friesen

Contract Software Engineer of Aerotek on behalf of Keysight

Keysight Technologies, Inc.

970.679.5632 T

--
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] Path Length Constraint ignored for Root and any self-issued certificate

[Peter Magnusson]

sorry, typo on the verify line, this was what I should have written:
VERIFY(max_path_length>0) error upon preparing transition from i=2
(EvilCA) to i=2 (EvilServer).
On Mon, Oct 8, 2018 at 2:47 PM Peter Magnusson
 wrote:
>
> That is not correct behaviour as far as I can understand.
>
> RFC5280 Certification Path Validation algorithm process from root to
> leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> Preparation for Certificate i+1 is expected to occur upon Root
> certificate, i.e. the following should be expected behaviour:
> * max_path_length=n (initialisation)
> * max_path_length=n-1 (first decrement)
> * max_path_length=0 (copied from root certificate constraint)
> * VERIFY(max_path_length>0) error upon preparing transition from i=1
> (Root) to i=2 (EvilCA).
>
> OpenSSL does everything in a slightly different reverse algorithm, but
> should perform the same controls and behaivor as the RFC imho.
>
> And aside from the RFC algorithm checking for this condition, it is
> also analog with the description of the expected behaviour:
>
>The pathLenConstraint field is meaningful only if the cA boolean is
>asserted and the key usage extension, if present, asserts the
>keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
>maximum number of non-self-issued intermediate certificates that may
>follow this certificate in a valid certification path.  (Note: The
>last certificate in the certification path is not an intermediate
>certificate, and is not included in this limit.  Usually, the last
>certificate is an end entity certificate, but it can be a CA
>certificate.)  A pathLenConstraint of zero indicates that no non-
>self-issued intermediate CA certificates may follow in a valid
>certification path.  Where it appears, the pathLenConstraint field
>MUST be greater than or equal to zero.  Where pathLenConstraint does
>not appear, no limit is imposed.
>
> So my understanding is that the OpenSSL algorithm is confused and
> fails to perform a check that is applicable to self-issued
> certificates. The decrement of max_path_length (aka plen++ in OpenSSL
> implementation) should not occur for self issued certificates, but the
> validation of max_path_length>0 (aka plen>(constraint+1)) should
> occur.
> On Mon, Oct 8, 2018 at 1:27 PM J Decker  wrote:
> >
> > It was my interpretation that 0 pathlen on the root self signed meant 
> > infinite.
> > The pathlen only applies on the certs between root and the leaf (which 
> > obviously can be 0, and CA true or not, but bad form to say true I'd 
> > imagine.)
> >
> > On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson 
> >  wrote:
> >>
> >> One more logic confusion in the OpenSSL Path Length Constraint check.
> >> Any Path Length Constraint set by Root (or any other Self-Issued
> >> Certificate) is ignored.
> >> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
> >> applied to the checker (i.e. the checker and the calculation logic
> >> have been mixed up).
> >>
> >> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
> >>
> >> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
> >> Certificate Sign, CRL Sign
> >> X509v3 Basic Constraints: critical
> >> CA:TRUE, pathlen:0
> >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
> >> Certificate Sign, CRL Sign
> >> X509v3 Basic Constraints: critical
> >> CA:TRUE, pathlen:0
> >> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
> >> X509v3 extensions:
> >> X509v3 Basic Constraints: critical
> >> CA:FALSE
> >> 
> >> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
> >> X509v3 extensions:
> >> X509v3 Subject Key Identifier:
> >> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> >> --
> >> --
> >> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> >> X509v3 Authority Key Identifier:
> >>
> >> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
> >> X509v3 extensions:
> >> X509v3 Subject Key Identifier:
> >> B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> >> --
> >> --
> >> B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> >> X509v3 Authority Key Identifier:
> >>
> >> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> >> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key 
> >> Identifier"
> >> TLS Web Server Authentication
> >> X509v3 Subject Key Identifier:
> >> 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
> >> --
> >> --
> >> 

Re: [openssl-users] Path Length Constraint ignored for Root and any self-issued certificate

[Peter Magnusson]

That is not correct behaviour as far as I can understand.

RFC5280 Certification Path Validation algorithm process from root to
leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
Preparation for Certificate i+1 is expected to occur upon Root
certificate, i.e. the following should be expected behaviour:
* max_path_length=n (initialisation)
* max_path_length=n-1 (first decrement)
* max_path_length=0 (copied from root certificate constraint)
* VERIFY(max_path_length>0) error upon preparing transition from i=1
(Root) to i=2 (EvilCA).

OpenSSL does everything in a slightly different reverse algorithm, but
should perform the same controls and behaivor as the RFC imho.

And aside from the RFC algorithm checking for this condition, it is
also analog with the description of the expected behaviour:

   The pathLenConstraint field is meaningful only if the cA boolean is
   asserted and the key usage extension, if present, asserts the
   keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
   maximum number of non-self-issued intermediate certificates that may
   follow this certificate in a valid certification path.  (Note: The
   last certificate in the certification path is not an intermediate
   certificate, and is not included in this limit.  Usually, the last
   certificate is an end entity certificate, but it can be a CA
   certificate.)  A pathLenConstraint of zero indicates that no non-
   self-issued intermediate CA certificates may follow in a valid
   certification path.  Where it appears, the pathLenConstraint field
   MUST be greater than or equal to zero.  Where pathLenConstraint does
   not appear, no limit is imposed.

So my understanding is that the OpenSSL algorithm is confused and
fails to perform a check that is applicable to self-issued
certificates. The decrement of max_path_length (aka plen++ in OpenSSL
implementation) should not occur for self issued certificates, but the
validation of max_path_length>0 (aka plen>(constraint+1)) should
occur.
On Mon, Oct 8, 2018 at 1:27 PM J Decker  wrote:
>
> It was my interpretation that 0 pathlen on the root self signed meant 
> infinite.
> The pathlen only applies on the certs between root and the leaf (which 
> obviously can be 0, and CA true or not, but bad form to say true I'd imagine.)
>
> On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson 
>  wrote:
>>
>> One more logic confusion in the OpenSSL Path Length Constraint check.
>> Any Path Length Constraint set by Root (or any other Self-Issued
>> Certificate) is ignored.
>> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
>> applied to the checker (i.e. the checker and the calculation logic
>> have been mixed up).
>>
>> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
>>
>> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
>> Certificate Sign, CRL Sign
>> X509v3 Basic Constraints: critical
>> CA:TRUE, pathlen:0
>> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
>> Certificate Sign, CRL Sign
>> X509v3 Basic Constraints: critical
>> CA:TRUE, pathlen:0
>> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
>> X509v3 extensions:
>> X509v3 Basic Constraints: critical
>> CA:FALSE
>> 
>> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
>> X509v3 extensions:
>> X509v3 Subject Key Identifier:
>> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>> --
>> --
>> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>> X509v3 Authority Key Identifier:
>>
>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
>> X509v3 extensions:
>> X509v3 Subject Key Identifier:
>> B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>> --
>> --
>> B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>> X509v3 Authority Key Identifier:
>>
>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
>> TLS Web Server Authentication
>> X509v3 Subject Key Identifier:
>> 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>> --
>> --
>> 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>> X509v3 Authority Key Identifier:
>>
>> keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>> 
>> ../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
>> root.pem -untrusted evilca.pem evilserver.pem
>> *** important variables ***
>> *** check_chain_extensions:524 i=0
>> *** check_chain_extensions:525 plen=0
>> *** check_chain_extensions:526 x->ex_pathlen=-1

Re: [openssl-users] Path Length Constraint ignored for Root and any self-issued certificate

[J Decker]

It was my interpretation that 0 pathlen on the root self signed meant
infinite.
The pathlen only applies on the certs between root and the leaf (which
obviously can be 0, and CA true or not, but bad form to say true I'd
imagine.)

On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson <
blaufish.public.em...@gmail.com> wrote:

> One more logic confusion in the OpenSSL Path Length Constraint check.
> Any Path Length Constraint set by Root (or any other Self-Issued
> Certificate) is ignored.
> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
> applied to the checker (i.e. the checker and the calculation logic
> have been mixed up).
>
> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
>
> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
> Certificate Sign, CRL Sign
> X509v3 Basic Constraints: critical
> CA:TRUE, pathlen:0
> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
> Certificate Sign, CRL Sign
> X509v3 Basic Constraints: critical
> CA:TRUE, pathlen:0
> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
> X509v3 extensions:
> X509v3 Basic Constraints: critical
> CA:FALSE
> 
> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
> X509v3 extensions:
> X509v3 Subject Key Identifier:
> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> --
> --
> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> X509v3 Authority Key Identifier:
>
> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
> X509v3 extensions:
> X509v3 Subject Key Identifier:
> B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> --
> --
> B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> X509v3 Authority Key Identifier:
>
> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key
> Identifier"
> TLS Web Server Authentication
> X509v3 Subject Key Identifier:
> 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
> --
> --
> 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
> X509v3 Authority Key Identifier:
>
> keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> 
> ../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
> root.pem -untrusted evilca.pem evilserver.pem
> *** important variables ***
> *** check_chain_extensions:524 i=0
> *** check_chain_extensions:525 plen=0
> *** check_chain_extensions:526 x->ex_pathlen=-1
> *** if statement components ***
> *** check_chain_extensions:528 i > 1=0
> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
> *** check_chain_extensions:530 (x->ex_pathlen != -1)=0
> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> proxy_path_length + 1))=0
> *** important variables ***
> *** check_chain_extensions:524 i=1
> *** check_chain_extensions:525 plen=1
> *** check_chain_extensions:526 x->ex_pathlen=0
> *** if statement components ***
> *** check_chain_extensions:528 i > 1=0
> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> proxy_path_length + 1))=0
> *** important variables ***
> *** check_chain_extensions:524 i=2
> *** check_chain_extensions:525 plen=2
> *** check_chain_extensions:526 x->ex_pathlen=0
> *** if statement components ***
> *** check_chain_extensions:528 i > 1=1
> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> proxy_path_length + 1))=1
> evilserver.pem: OK
> Chain:
> depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
> EvilServer, CN = EvilServer (untrusted)
> depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
> = EvilCA (untrusted)
> depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
> --
> 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] Path Length Constraint ignored for Root and any self-issued certificate

[Peter Magnusson]

One more logic confusion in the OpenSSL Path Length Constraint check.
Any Path Length Constraint set by Root (or any other Self-Issued
Certificate) is ignored.
Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
applied to the checker (i.e. the checker and the calculation logic
have been mixed up).

https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2

openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE

openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
X509v3 extensions:
X509v3 Subject Key Identifier:
49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
--
--
49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
X509v3 Authority Key Identifier:

keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
X509v3 extensions:
X509v3 Subject Key Identifier:
B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
--
--
B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
X509v3 Authority Key Identifier:

keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
TLS Web Server Authentication
X509v3 Subject Key Identifier:
03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
--
--
03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
X509v3 Authority Key Identifier:

keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C

../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
root.pem -untrusted evilca.pem evilserver.pem
*** important variables ***
*** check_chain_extensions:524 i=0
*** check_chain_extensions:525 plen=0
*** check_chain_extensions:526 x->ex_pathlen=-1
*** if statement components ***
*** check_chain_extensions:528 i > 1=0
*** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
*** check_chain_extensions:530 (x->ex_pathlen != -1)=0
*** check_chain_extensions:531 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
*** important variables ***
*** check_chain_extensions:524 i=1
*** check_chain_extensions:525 plen=1
*** check_chain_extensions:526 x->ex_pathlen=0
*** if statement components ***
*** check_chain_extensions:528 i > 1=0
*** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
*** check_chain_extensions:530 (x->ex_pathlen != -1)=1
*** check_chain_extensions:531 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
*** important variables ***
*** check_chain_extensions:524 i=2
*** check_chain_extensions:525 plen=2
*** check_chain_extensions:526 x->ex_pathlen=0
*** if statement components ***
*** check_chain_extensions:528 i > 1=1
*** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
*** check_chain_extensions:530 (x->ex_pathlen != -1)=1
*** check_chain_extensions:531 (plen > (x->ex_pathlen +
proxy_path_length + 1))=1
evilserver.pem: OK
Chain:
depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
EvilServer, CN = EvilServer (untrusted)
depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
= EvilCA (untrusted)
depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Incompatible Object error from EC_POINT_mul

[Nicola]

Hi,

I did not run this in the debugger, but one issue is that you are not
initializing `pub` before calling EC_POINT_mul : try adding

pub = EC_POINT_new(curve);
(and check for errors making sure pub is not null afterwards).

Hope this helps!


Best regards,

Nicola


On Mon, Oct 8, 2018, 00:31 John Hughes  wrote:

> I'm trying to generate a public key from a private key generated on a HSM
> (and obtained by calling PKCS#11). Everything works fine until I call
> EC_POINT_mul - at which point I get the error message:
>
>error:100BB065:elliptic curve routines:ec_wNAF_mul:incompatible
> objects
>
> I have checked the BIGNUM conversion - and that seems to be fine. The key
> pair on the HSM is also generated using brainpoolP256r1.
>
> The basis of the code can be found at the end of the email. I'm basically
> trying to follow the example provided in:
> https://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography.
>
> I'm using openssl 1.10h
>
> Any pointers or help would be appreciated.
>
>
> John
>
> ---
>
>
> BN_CTX *ctx;
> ctx = BN_CTX_new();
> if(!ctx) {
> outputInfo("unable to create openssl BN_CTX");
> return;
> }
>
> EC_GROUP *curve;
>
> outputInfo("about to create EC_GROUP_new_by_curve_name");
> if(NULL == (curve =
> EC_GROUP_new_by_curve_name(NID_brainpoolP256r1))) {
> outputERRORmess("unable to setup curve");
> }
>
> outputInfo("about to create EC_KEY_new_by_curve_name");
> EC_KEY *key;
> if(NULL == (key = EC_KEY_new_by_curve_name(NID_brainpoolP256r1))) {
> outputERRORmess("unable to setup EC_KEY");
> }
>
> // now get the private key contained in CKA_VALUE via PKCS#111 and
> place in *attrPrivate.pValue
>
> .. (handle error)
>
> EC_POINT *pub;
>
>
> BIGNUM *prv = BN_bin2bn((unsigned char*)attrPrivate.pValue,
> attrPrivate.ulValueLen, NULL);
> if (prv == NULL) {
>
> .. (handle error)
> }
>
> if (1 != EC_KEY_set_private_key(key, prv)) {
>
>  (handle error)
> }
>
> if (1 != EC_POINT_mul(curve, pub, prv, NULL, NULL, ctx)) {
> outputInfo("unable to calculate the public key from the
> HSM's private key using EC_POINT_mul");
> (handle error)
>
> }
>
>
>
>
>
>
>
> --
> 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