Re: CPU Software Engine

[Jan Just Keijser]

Hi Costas,

Costas Stasimos wrote:

Hello!

I'm currently using the cryptodev framework-engine with openssl-1.0.1e.

By run the command

# openssl engine -t
(cryptodev) cryptodev engine
 [ available ]
(dynamic) Dynamic engine loading support
 [ unavailable ]

we can see that the cryptodev is the active-chosen engine.

So it seems that all the cryptographic load is directed automatically 
to /dev/crypto via the cryptodev engine.


My question is, how i can use the CPU instead of cryptodev, or with 
other words how i can disable the cryptodev from application level?


Is there an engine id-name in order to change the activated cryptodev 
engine and send the execution to the Software-CPU?


AFAIK the cryptodev engine won't be used unless you actually specify it 
on the command line, e.g.

 openssl speed -engine cryptodev -evp 
etc.

HTH,

JJK

Re: Retrieve CA for client cert from SSL*

[Jan Just Keijser]

On 24/10/19 19:55, Fen Fox wrote:


Is there a way to figure out which CA the server used to validate the 
client certificate?



on the server side?  you would have to write your own verify callback to 
intercept the certificate stack as it is processed. That way, you can 
monitor which CA openssl selected for verification.


HTH,

JJK

Re: AW: openssl and external card reader support in TLS

[Jan Just Keijser]

Hi Tobias,

On 23/10/19 10:11, tobias.w...@t-systems.com wrote:

Our PKCS11 module development will discontinue and therefore I can`t use it 
anymore, but the idea is great and very interesting.
To give more details we need a callback or similar mechanism to replace the 
signature created in Certificate TLS message with our signature coming from the 
card reader.

TLS handshake
..
S: Certificate Request
C: Certificate Verify --> here we want to hook in "Signature" and replace the 
value!
.

We tried already with the client callback

int (*client_cert_cb)(SSL *ssl, X509 **x509,
EVP_PKEY **pkey));

But there it is mandatory to give in the private key which we don`t have, 
because that part is done by the card reader machine.
I think the caller of the callback is doing later on a rsa sign processing with 
the private key and there I want to hook in!



writing your own engine might be the easiest thing: the way it 
currently(most likely) works, is

  openssl -> engine_pkcs11 -> libp11 -> pkcs11 driver

all you'd have to do is move your pkcs11 driver code into a fork of the 
engine_pkcs11 code. That code is less than 2000 lines long, so it should 
be fairly straightforward.


JM2CW,

JJK

Re: SSL certificate verification

[Jan Just Keijser]

On 18/12/19 09:54, Mody, Darshan Arvindkumar (Darshan) wrote:


Hi

We are using SSL_CTX_use_certificate and 
SSL_CTX_use_certificate_chain_file APIs to load the certificates.


My query is when we are loading the certificate in the Context does 
openssl verify the certificates for e.g. whether the certificate is 
expired already etc.



the short answer is no, it does not; the openssl library will let you 
load expired/invalid certificates if you do not do any explicit checks.  
Use a verify_callback and call X509_verify_cert() to check the validity.


HTH,

JJK

Re: OpenSSL on embedded systems

[Jan Just Keijser]

On 17/02/20 11:51, Innocenti, Michele via openssl-users wrote:


Hi,

Which is the minimum footprint needed to use OpenSSL TLS 1.3 library 
in an embedded context?


Which embedded OS are supported? i.e. FreeRTOS, VxWorks, Micirium uC-OS



AFAICT, OpenSSL is supported on VxWorks, not on RTOS or uC-OS.

For embedded crypto libraries I would recommend mbed-tls (formerly 
polarssl) and wolfssl.

Both support TLS 1.3 in their latest releases.

HTH,

JJK

Re: Program works with older libssl, but not with newer

[Jan Just Keijser]

Hi,

On 31/03/20 19:42, Viktor Dukhovni wrote:

On Tue, Mar 31, 2020 at 04:51:32PM +0200, Christoph Pleger wrote:


I have here a self-written server program and the corresponding
self-written client program. These run well together with libssl 1.1.0l,
but with libssl 1.1.1d, the same programs give errors SSL_ERROR_SYSCALL
in SSL_read(), no matter if I recompile the programs and then run them,
or just replace libssl with the newer version.

OpenSSL 1.1.1 supports TLS 1.3, which OpenSSL 1.1.0 did not.


So, I want to ask if there are any known incompabilities in the libssl
versions that require me to change the code of the programs, or if there
is
any known bug in libssl1.1.1d that may cause the mentioned errors.

Use of TLS 1.3 changes the communication patterns of the TLS protocol in
some non-trivial ways, and, if your application were fragile, it might
have gotten by with TLS 1.2, but the latent bugs could show up with TLS
1.3.

Now, I replaced TLS_server_method() and TLS_client_method() with
TLSv1_2_server_method() and TLSv1_2_client_method() respectively, and the same
error occurs.

Well, in that case, you need to provide more detail.  Does the handshake
complete?  If not, at what stage does it fail?

A PCAP file may be needed.  And you need to explain what operation
fails with SSL_ERROR_SYSCALL, and do an "strace" or equivalent to
understand what the relevant socket read calls returned.

on a related note: I am experiencing similar problems with my ppp 
EAP-TLS patch ; I now that EAP-TLS + TLSv1.3 is experimental but I do 
notice that the entire handshake seems to differ for TLSv1.3 versus 
TLSv1.2 ; as a workaround I am adding

  SSL_CTX_set_max_proto_version(ctx, TLS1_2_VERSION);
to my code to avoid a TLSv1.3 handshake. I am not sure yet why and where 
it is failing, but it seems the client is not sending its certificate 
chain to the server.  I am positive it is a programming error on my side 
but I will say that this problem is particularly hard to track down.



JM2CW,

JJK / Jan Just Keijser

Re: How to debug a TLSv1.3 protocol problem?

[Jan Just Keijser]

Hi Claus,

On 18/05/20 20:59, Claus Assmann wrote:

On Mon, May 18, 2020, Alexander Gryanko wrote:

[thanks for the hints, I will try that ASAP]


But first of all, check your cert type. Looks like you are using non-RSA
cert which is not supported by S8.

As I wrote: it works fine if I don't use TLSv1.3 or if I use openssl
s_client with TLSv1.3 (it is an RSA cert and I also tested against
another S8 server which uses a Let's Encrypt cert).
FWIW:  adding TLS 1.3 support to my EAP-TLS code got me stumped for a 
while as well. I eventually added up the following snippet:


    /* Set up a SSL Session cache with a callback. This is needed for 
TLSv1.3+.
 * During the initial handshake the server signals to the client 
early on

 * that the handshake is finished, even before the client has sent its
 * credentials to the server. The actual connection (and moment 
that the
 * client sends its credentials) only starts after the arrival of 
the first

 * session ticket. The 'ssl_new_session_cb' catches this ticket.
 */
    SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_CLIENT | 
SSL_SESS_CACHE_NO_INTERNAL_STORE);

    SSL_CTX_sess_set_new_cb(ctx, ssl_new_session_cb);



with

int ssl_new_session_cb(SSL *s, SSL_SESSION *sess)
{
    dbglog("EAP-TLS: Post-Handshake New Session Ticket arrived:");

    /* always return success */
    return 1;
}


This callback is necessary as otherwise the client thinks the session 
handshake is done too soon (and in my case, it does not bother to send 
any client-side certificate info to the server).


Perhaps you are seeing something similar? If not, then sorry for the noise.

HTH,

JJK / Jan Just Keijser

Re: server key exchange signature behavior

[Jan Just Keijser]

Hi,

see comments/questions inline

On 23/06/20 14:03, Bruce Cloutier wrote:

Hello,

We administer a server (Windows) with a Bitnami stack for a Wordpress
implementation and that uses Apache Httpd and OpenSSL. Separately I am
developing the TLS ECC aspect of a controller device implementation and
note a problematic behavior with the server_key_exchange for ECDHE_RSA.
The developed device ECDHE_RSA suite works properly and as expected with
all of the other servers thus far tested. There is likely a
configuration issue with this Apache installation and I am fishing for a
hint.
you mention TLS ECC, suggesting Elliptic Curve Crypto, which might 
indicate EC-encoded certificates as well, yet talk about ECDHE_RSA which 
is Elliptic-curve Diffie-Hellman Exchange with RSA  (for which you'd 
normally use RSA-encoded certificates.


Now you can use both with httpd+openssl but you do need to specify the 
right certificate (or certificates) when configuring mod_ssl - you can 
even concatenate the RSA-signed certificate and the EC-signed 
certificate in a single hostcert.pem and mod_ssl will pick up both , 
simply using



#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/httpd/certs/hostcert.pem

#    Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/httpd/certs/hostkey.pem


I'd recommend to take your test cert+key and see if you can run it using
  openssl s_server  
against
  openssl s_client 

(use 'openssl s_server -help' and 'openssl s_client -help' for the 
parameter list).


If *that* works and apache+mod_ssl does not then you're looking at an 
mod_ssl configuration issue.


HTH,

JJK




The issue is that the RSA signature as part of the server_key_exchange
does not decrypt with the supplied certificate public RSA key. It does
indicate an rsa_pkcs1_sha256 signature.

With a fresh Bitnami install that still uses the default key and
certificate files, the protocol provides a valid digital signature. When
we change the server's certificate (and confirm this with the browser)
the server_key_exchange signature no longer validates. It is as if the
server continues to use the default key for the signature. I have not
tried to confirm that specific point.

My immediate question for someone close to the code is where does
Apache/OpenSSL look for the key file for this signature at this point in
the protocol?

I am hoping that there is just some additional configuration location
that needs to be given our new key file and/or certificate. Can anyone
confirm?

We noted this concern on a production server. We then installed the
stack on a different machine to confirm the fresh install operation. In
adding different key and certificate files we confirm that the signature
then fails. If I ignore the bad signature the secure communications
succeed.

I have been searching the net for this issue for weeks. That has been
fruitless. So I am turning to this list.

Re: server key exchange signature behavior

[Jan Just Keijser]

On 25/06/20 20:02, Bruce Cloutier wrote:

I agree that I am not being explicit regarding my terminology. I don't
mean to confuse. I just cannot get anywhere on this in a vacuum. So, I
need to reach out.

Specifically, the Signature covering the EC Diffe-Hellman Server Params
in the server_key_exchange message that I eventually receive in making
an outgoing client connection from my TLS implementation, does not
decrypt into a valid PKCS1 ASN.1 structure (or anything recognizable).
That is happening with this one server installation using Apache in a
Bitnami stack (Windows machine). My TLS code is running as part of the
operating system on our separate single board computer controller (JNIOR).

I use the public key extracted from the supplied certificate to decrypt
and then compare the calculated hash. This procedure has been successful
(and signatures verify/validate/match) in every other connection attempt
to other servers (including google.com). It also works with this Apache
server before we move away from the default key and certificate files.
Basically, our server is using some other key for this. Maybe still the
default. After we point configuration to a new certificate and key.

Yeah, I had at first thought that there was an intrusion. But in testing
with a clean sandboxed server we see the same results. Yes, it is most
likely an Apache configuration issue but, we've dug through all of that
and nothing jumps out.

So either we haven't configured every possible corner of this Apache
server correctly, or there is some odd extension to TLS that I've
missed. But as you all know, debugging in this area is difficult.

jnior.com is obviously public and we need to know if we have it
improperly configured. But, I need to know why in this one instance my
TLS implementation fails. In either case, it is an symptom that
shouldn't be ignored as you would agree.

The good news is that if there were an OpenSSL bug somewhat associated
with this, you all would have already mentioned it (I assume).



I'd suggest to run something like wireshark and capture the TLS 
handshake - if I do that against jnior.com I see that the jnior.com 
certificate has a X509 cert extension unknown to my rather old Wireshark 
version, but that should not matter much. Wireshark will give you 
detailed info about the EC Diffie-Hellman Server Params that were sent 
over the wire, including the signature. Wireshark does not indicate any 
problems there, although I am not sure if it *would* , if there was a 
problem.


However, it will give you an easy method to see what wireshark thinks 
the signature is compared to what your code thinks the signature is.


As a side-remark: I did notice your server cert is using 3072 bit RSA 
whereas the CAs are based on 2048bit RSA - nothing wrong with that, but 
do make sure your code can handle that (under normal circumstances it 
would not be an issue).


HTH,

JJK


On 6/25/20 1:32 PM, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Bruce Cloutier
Sent: Thursday, June 25, 2020 12:10

By "If OpenSSL fails to validate this particular digital signature that
would be the case." I meant to question whether or not OpenSSL is in
fact doing the validation? In the case that the signature is being
ignored then clients wouldn't complain. They wouldn't notice.

s_client should be verifying the signature.[1] That is, it should be verifying 
every signature that's part of the actual TLS protocol. I admit it's not 
entirely clear to me which signature isn't being verified successfully by your 
client.


[1] I'm not sure "validate" is the proper term here, technically speaking. In my experience, the 
literature usually uses "verify" for confirming a signature. "Validate" is generally used 
for more complex protocols, such as certificate validation, which involves a large number of steps with 
various types of checks.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

Re: Lack of documentation for OPENSSL_ia32cap_P

[Jan Just Keijser]

On 23/07/20 02:35, Jakob Bohm via openssl-users wrote:

The OPENSSL_ia32cap_P variable, its bitfields and the code that sets
it (in assembler) seemto have no clear documentation.

Looking at x86_64cpuid.pl, I see jumps to ".Lintel" etc. being 
conditional
on stuff other than the CPU being an Intel CPU, while the code in 
there is
generally unreadable due to the backwards SCO assembler format and the 
lack
of clear comments about register usage such as "Here, EDX holds XXX 
and ESI

holds " or eventhe code rationale "P50 microarchitecture stepping A
incorrectly implements FDIV, so clear out private bit for using that in
bignum implementations"

As there is an external interface for changing the variable via an 
environment

var, the lack of documentation makes that useless except for "cargo-cult"
copying of values from old mailing list posts.
in the openssl 1.1.1g tree there's a file 'doc/man3/OPENSSL_ia32cap.pod' 
which documents it a little - not sure if that is still up-to-date though...


HTH,

JJK

Re: TLS with Client Authentication using private key from Windows store

[Jan Just Keijser]

Hi Ferenc,

On 23/11/20 13:03, Ferenc Gerlits via openssl-users wrote:

Hi,

I am trying to use openssl to implement a client-side TLS connection 
with Client Authentication on Windows, using a non-exportable private 
key stored in the Windows Certificate Store.  Currently, our code can 
use a private key stored in a local file, and if the key in the 
Windows store was exportable, I could export it and use it in the 
existing code.  But the key is non-exportable, which is a problem.


Does anyone know how to do this?

So far, I have found suggestions to use the CAPI engine (eg. 
https://groups.google.com/g/mailing.openssl.users/c/_rdJLc7emAY?pli=1), 
but no examples of how to do that, and also some tickets (eg. 
https://github.com/openssl/openssl/issues/12859) which say that the 
CAPI engine does not work with TLS >= 1.2 on openssl 1.1.1, so that 
doesn't look like a good solution.



OpenVPN 2.4+  can use the Windows Certificate Store to encrypt and sign 
traffic using CNG (Crypto Next Gen, I believe). I'd suggest you download 
the source code and examine the file  cryptoapi.c for details.


HTH,

JJK

Re: private key not available for client_cert_cb

[Jan Just Keijser]

Hi,

On 14/12/20 08:08, George wrote:

Hi,

   I'm new to OpenSSL and am trying to set up mutual authentication in 
a client. The client is setup with OpenSSL 1.0.2u. and the client's 
certificate + private key is stored on a Smart Card.  When the client 
receives a certificate request from the server during the mutual 
authentication handshake, the OpenSSL /client_cert_cb/ callback 
function is automatically invoked. The problem is that 
/client_cert_cb/ requires a private key. Unfortunately, it is not 
possible to get a private key from a Smart Card. Is there a way to 
send a certificate to the server without needing the private key?


I'm setting up the callback function with:

void SSL_CTX_set_client_cert_cb(SSL_CTX *ctx, int 
(*client_cert_cb)(SSL *ssl, X509 **x509, EVP_PKEY **pkey));



Here is a sample of what my code looks like when I set this up:

SSL_CTX_set_client_cert_cb(context, 
*openSSLClientAuthenticationCallBack*);


int *openSSLClientAuthenticationCallBack*(SSL *ssl, X509 **x509, 
EVP_PKEY **pkey)

{
. . .
}


I can access the Smart Card using the PKCS#11 interface and I'm able 
to get the certificate and sign it, etc. However, I cannot get the 
actual private key from the Smart Card.


Does anyone know how I can get around this problem?



to use a pkcs#11 smartcard you normally use the OpenSSL pkcs11 engine ; 
you then do something like:


    engine_name = "pkcs11";
    ENGINE_register_all_complete();
    pkey_engine = ENGINE_by_id( "dynamic" );
    if (pkey_engine)
    {
    if (!ENGINE_ctrl_cmd_string(pkey_engine, "SO_PATH", 
engine_name, 0)

 || !ENGINE_ctrl_cmd_string(pkey_engine, "LOAD", NULL, 0))
    {
    warn( "EAP-TLS: Error loading dynamic engine '%s'", 
engine_name );

    log_ssl_errors();
    ENGINE_free(e);
    pkey_engine = NULL;
    }
    }
    }

    if (pkey_engine)
    {
    if(!ENGINE_set_default(pkey_engine, ENGINE_METHOD_ALL))
    }
    pkey_engine = eaptls_ssl_load_engine( "pkcs11" );
    pkey = ENGINE_load_private_key(pkey_engine, pkey_identifier, 
transfer_pin, &cb_data);

    SSL_CTX_use_PrivateKey(ctx, pkey);

where "transfer_pin" is a callback UI function to query the user for the 
pkcs11 device password.


More detailed code can be found in my pppd EAP-TLS patch, file eap-tls.c at
  https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c

(and search for pkey_engine)

HTH,

JJK

Re: private key not available for client_cert_cb

[Jan Just Keijser]

Hi,

On 14/12/20 21:01, George wrote:
Ok, so I am not actually going to populate EVP_PKEY with a private key 
in the callback function:

int (*client_cert_cb)(SSL *ssl, X509 **x509, *EVP_PKEY **pkey*)?

Instead, I will call
EVP_PKEY *ENGINE_load_private_key(ENGINE *e, const char *key_id, 
UI_METHOD *ui_method, void *callback_data);
to get the EVP_PKEY, which will be used by OpenSSL to access the Smart 
Card.


Once I get the resulting EVP_PKEY using ENGINE_load_private_key(...), 
how do I assign it to pkey in the callback function?

If I had private key I would use something like
EVP_PKEY_assign_RSA(..)
Since I don't actually have a private key, should I use something else?

like Michael pointed out, my  eap-tls code is just an example of how you 
could handle a pkcs11 device; it does not us a callback at all, but my 
code loads the client cert+key upfront and avoids having to use a client 
callback altogether.


I guess you could also use a client callback for this (perhaps in 
combination with SSL_CTX_set_client_cert_engine()) . In that case you 
would get the (pseudo) key from the engine like this
   EVP_PKEY *engine_key = ENGINE_load_private_key(ENGINE *e, const char 
*key_id, UI_METHOD *ui_method, void *callback_data);

and then set
  pkey = &engine_key;
and see if that works.
Note that the ENGINE_load_private_key() function *does* return a 
EVP_PKEY struct but that does not mean the entire private key is 
contained in it; a private key consists of a modulus and a private part 
(exponent, prime1, prime2, exponent1, exponent2 etc). the 
ENGINE_load_private_key() call will return a struct containing the 
modulus but not the rest. You then use the engine to do the actual 
encryption and decryption.


HTH,

JJK





Thanks,
George


On 2020-12-14 12:59 p.m., Michael Wojcik wrote:


You can't get the private key from the smartcard. Instead, you have to let the 
engine do the encryption. I don't know what ENGINE_load_private_key actually 
does - in my PKCS#11 work I didn't have to get into this - but I suspect it 
just puts a key identifier into pkey.

Then what ought to happen is that you pass that pkey to OpenSSL where you need an 
EVP_PKEY, and OpenSSL will call the engine's appropriate method for whatever it needs to 
do, and the engine will tell the smartcard "do this thing using the key with this 
identifier".

I suggest you refer to a example such as the PPP code that Jan cited to see how 
it does this sort of thing.

Or you can take the approach that Paul suggests in his reply of writing your 
own engine specifically for your hardware, if you don't need generic PKCS#11 
support. Basically, PKCS#11 gives you support for more devices, and in 
principle should do some of the work for you; but as Paul suggests, the PKCS#11 
API and its dependence on external drivers and libraries means it's not easy to 
work with. In some cases where you only need to support one type of device (or 
a family of devices that all use the same driver / library) it might well be 
easier to just write a simple engine that only supports the features you need. 
You can use the source for the existing engines in OpenSSL to get an idea of 
what that looks like.

A few years back I forked the OpenSSL CAPI engine to make some fixes and 
enhancements, and that was pretty straightforward.

So if you have a well-documented API for your particular smartcard, with handy functions 
like "do this to get an RSA signature of a blob of data with this key ID and these 
parameters", you may want to try Paul's route. Really depends on your requirements 
and what kind of support you already have for your device.

And all of this changes in 3.0 with the new "provider" architecture, so you'll 
get to take another crack at it soon.

--
Michael Wojcik

Re: private key not available for client_cert_cb

[Jan Just Keijser]

Hi,

On 16/12/20 20:26, George wrote:

Hi,

   I've been looking at the code in the pppd EAP-TLS patch, but I 
can't seem to load the engine with the pkcs11 DLL. It is failing with 
the error:


error:2507606A:DSO support routines:WIN32_BIND_FUNC:could not bind to 
the requested symbol name


I've verified the path is correct.

I am using OpenSSL1.0.2u with the FIPS Object Module 2.0.16  in 
Windows 10. Do I need to do anything special to allow loading of DLLs 
in OpenSSL?


Here is what I am trying to do:

    char* engine_name = 
"C:\\Users\\whipp\\junk4\\ActivClient\\acpkcs211.dll";

    ENGINE_load_builtin_engines();
    ENGINE_register_all_complete();
    ENGINE *pkey_engine = ENGINE_by_id("dynamic");
    ENGINE_ctrl_cmd_string(pkey_engine, "SO_PATH", engine_name, 0);
    ENGINE_ctrl_cmd_string(pkey_engine, "ID", "pkcs11", 0);
    ENGINE_ctrl_cmd_string(pkey_engine, "LOAD", NULL, 0);

Do you see anything wrong with this?



I forgot to mention that loading a PKCS11 driver from within OpenSSL is 
a 2 stage rocket:


first stage:  load the engine_pkcs11 module using

    char* engine_name = "|C:\\Windows\\System32\\pkcs11.dll"|

This is a separate piece of code and is part of the libp11 project:
  https://github.com/OpenSC/libp11

(it also has a nice wiki that explains how to do it on the command line 
using OPENSSL.EXE)


Then create an openssl.cnf section like this:

|openssl_conf = openssl_init [openssl_init] engines = engine_section 
[engine_section] pkcs11 = pkcs11_section [pkcs11_section] engine_id = 
pkcs11 dynamic_path = "C:\Windows\System32\opensc-pkcs11.dll" 
MODULE_path = "||C:\Users\whipp\junk4\ActivClient\acpkcs211.dll" PIN = "0001password" 
init = 0|



and load that (see the EAP-TLS code for an example or read
https://stackoverflow.com/questions/41119744/pkcs11-engine-for-openssl
for a similar question).

HTH,

JJK





On 2020-12-15 4:38 a.m., Jan Just Keijser wrote:

Hi,

On 14/12/20 21:01, George wrote:
Ok, so I am not actually going to populate EVP_PKEY with a private 
key in the callback function:

int (*client_cert_cb)(SSL *ssl, X509 **x509, *EVP_PKEY **pkey*)?

Instead, I will call
EVP_PKEY *ENGINE_load_private_key(ENGINE *e, const char *key_id, 
UI_METHOD *ui_method, void *callback_data);
to get the EVP_PKEY, which will be used by OpenSSL to access the 
Smart Card.


Once I get the resulting EVP_PKEY using 
ENGINE_load_private_key(...), how do I assign it to pkey in the 
callback function?

If I had private key I would use something like
EVP_PKEY_assign_RSA(..)
Since I don't actually have a private key, should I use something else?

like Michael pointed out, my  eap-tls code is just an example of how 
you could handle a pkcs11 device; it does not us a callback at all, 
but my code loads the client cert+key upfront and avoids having to 
use a client callback altogether.


I guess you could also use a client callback for this (perhaps in 
combination with SSL_CTX_set_client_cert_engine()) . In that case you 
would get the (pseudo) key from the engine like this
   EVP_PKEY *engine_key = ENGINE_load_private_key(ENGINE *e, const 
char *key_id, UI_METHOD *ui_method, void *callback_data);

and then set
  pkey = &engine_key;
and see if that works.
Note that the ENGINE_load_private_key() function *does* return a 
EVP_PKEY struct but that does not mean the entire private key is 
contained in it; a private key consists of a modulus and a private 
part (exponent, prime1, prime2, exponent1, exponent2 etc). the 
ENGINE_load_private_key() call will return a struct containing the 
modulus but not the rest. You then use the engine to do the actual 
encryption and decryption.


HTH,

JJK

Re: private key not available for client_cert_cb

[Jan Just Keijser]

On 17/12/20 14:55, George wrote:
Ok. So I use the libp11 project DLL file for the SO_PATH and my smart 
card middleware DLL for the MODULE_PATH when setting up the OpenSSL 
Engine?




yes just like in the example I posted below.

I would recommend the p11 wiki page to do it using the command line 
first - much easier to test & debug.


JJK




On 2020-12-17 3:22 a.m., Jan Just Keijser wrote:

Hi,

On 16/12/20 20:26, George wrote:

Hi,

   I've been looking at the code in the pppd EAP-TLS patch, but I 
can't seem to load the engine with the pkcs11 DLL. It is failing 
with the error:


error:2507606A:DSO support routines:WIN32_BIND_FUNC:could not bind 
to the requested symbol name


I've verified the path is correct.

I am using OpenSSL1.0.2u with the FIPS Object Module 2.0.16 in 
Windows 10. Do I need to do anything special to allow loading of 
DLLs in OpenSSL?


Here is what I am trying to do:

    char* engine_name = 
"C:\\Users\\whipp\\junk4\\ActivClient\\acpkcs211.dll";

    ENGINE_load_builtin_engines();
    ENGINE_register_all_complete();
    ENGINE *pkey_engine = ENGINE_by_id("dynamic");
    ENGINE_ctrl_cmd_string(pkey_engine, "SO_PATH", engine_name, 0);
    ENGINE_ctrl_cmd_string(pkey_engine, "ID", "pkcs11", 0);
    ENGINE_ctrl_cmd_string(pkey_engine, "LOAD", NULL, 0);

Do you see anything wrong with this?



I forgot to mention that loading a PKCS11 driver from within OpenSSL 
is a 2 stage rocket:


first stage:  load the engine_pkcs11 module using

    char* engine_name = "|C:\\Windows\\System32\\pkcs11.dll"|

This is a separate piece of code and is part of the libp11 project:
https://github.com/OpenSC/libp11

(it also has a nice wiki that explains how to do it on the command 
line using OPENSSL.EXE)


Then create an openssl.cnf section like this:

|openssl_conf = openssl_init [openssl_init] engines = engine_section 
[engine_section] pkcs11 = pkcs11_section [pkcs11_section] engine_id = 
pkcs11 dynamic_path = "C:\Windows\System32\opensc-pkcs11.dll" 
MODULE_path = "||C:\Users\whipp\junk4\ActivClient\acpkcs211.dll" PIN = "0001password" 
init = 0|


and load that (see the EAP-TLS code for an example or read
https://stackoverflow.com/questions/41119744/pkcs11-engine-for-openssl
for a similar question).

HTH,

JJK





On 2020-12-15 4:38 a.m., Jan Just Keijser wrote:

Hi,

On 14/12/20 21:01, George wrote:
Ok, so I am not actually going to populate EVP_PKEY with a private 
key in the callback function:

int (*client_cert_cb)(SSL *ssl, X509 **x509, *EVP_PKEY **pkey*)?

Instead, I will call
EVP_PKEY *ENGINE_load_private_key(ENGINE *e, const char *key_id, 
UI_METHOD *ui_method, void *callback_data);
to get the EVP_PKEY, which will be used by OpenSSL to access the 
Smart Card.


Once I get the resulting EVP_PKEY using 
ENGINE_load_private_key(...), how do I assign it to pkey in the 
callback function?

If I had private key I would use something like
EVP_PKEY_assign_RSA(..)
Since I don't actually have a private key, should I use something 
else?


like Michael pointed out, my  eap-tls code is just an example of 
how you could handle a pkcs11 device; it does not us a callback at 
all, but my code loads the client cert+key upfront and avoids 
having to use a client callback altogether.


I guess you could also use a client callback for this (perhaps in 
combination with SSL_CTX_set_client_cert_engine()) . In that case 
you would get the (pseudo) key from the engine like this
   EVP_PKEY *engine_key = ENGINE_load_private_key(ENGINE *e, const 
char *key_id, UI_METHOD *ui_method, void *callback_data);

and then set
  pkey = &engine_key;
and see if that works.
Note that the ENGINE_load_private_key() function *does* return a 
EVP_PKEY struct but that does not mean the entire private key is 
contained in it; a private key consists of a modulus and a private 
part (exponent, prime1, prime2, exponent1, exponent2 etc). the 
ENGINE_load_private_key() call will return a struct containing the 
modulus but not the rest. You then use the engine to do the actual 
encryption and decryption.


HTH,

JJK

Re: private key not available for client_cert_cb

[Jan Just Keijser]

Hi,

On 18/12/20 06:21, George wrote:

Hi,

   I'm able to setup the engine now, but as soon as I attempt to 
execute the command

ENGINE_set_default(pkey_engine, ENGINE_METHOD_ALL);
,I see all kinds of middleware exceptions being generated:

Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ exception: 
unsigned long at memory location 0x07FCFA00.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ exception: 
AI::Middleware::CMWException at memory location 0x032FD2D0.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ exception: 
AI::Middleware::CMWException at memory location 0x032FD2D0.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ exception: 
AI::Middleware::CMWException at memory location 0x032FD2D0.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ exception: 
AI::Middleware::CMWException at memory location 0x032FD2D0.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ exception: 
AI::Middleware::CMWException at memory location 0x032FD2D0.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ exception: 
AI::Middleware::CMWException at memory location 0x032FD2D0.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ exception: 
AI::Middleware::CMWException at memory location 0x032FD2D0.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ exception: 
AI::Middleware::CMWException at memory location 0x032FD2D0.

.
.
.


Do you have any idea what is causing these errors? Am I missing 
something in the configuration? When I use the OpenSSL command line 
debugger, there are no errors:


OpenSSL> engine -t dynamic -pre 
"SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll" 
-pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre "MODULE_PATH:C:\Program 
Files (x86)\HID Global\ActivClient\\acpkcs211.dll"

(dynamic) Dynamic engine loading support
[Success]: 
SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll

[Success]: ID:pkcs11
[Success]: LIST_ADD:1
[Success]: LOAD
[Success]: MODULE_PATH:C:\Program Files (x86)\HID 
Global\ActivClient\\acpkcs211.dll

Loaded: (pkcs11) pkcs11 engine
 [ available ]
OpenSSL>


Here is what my simplified code looks like:

char* enginePluginLibrary = 
"C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll";
char* pkcs11MiddlewareLibrary = "C:\\Program Files (x86)\\HID 
Global\\ActivClient\\acpkcs211.dll";

ENGINE_load_builtin_engines();
ENGINE_register_all_complete();
ENGINE *pkey_engine = ENGINE_by_id("dynamic");

ENGINE_ctrl_cmd_string(pkey_engine, "SO_PATH", enginePluginLibrary, 0);
ENGINE_ctrl_cmd_string(pkey_engine, "ID", "pkcs11", 0);
ENGINE_ctrl_cmd_string(pkey_engine, "LIST_ADD", "1", 0);
ENGINE_ctrl_cmd_string(pkey_engine, "LOAD", NULL, 0);
ENGINE_ctrl_cmd_string(pkey_engine, "MODULE_PATH", 
pkcs11MiddlewareLibrary, 0);

ENGINE_set_default(pkey_engine, ENGINE_METHOD_ALL);


main difference between the OPENSSL.EXE example and your code is that 
last call:


here's wat "ENGINE_set_default(pkey_engine, ENGINE_METHOD_ALL)" does:


int ENGINE_set_default(ENGINE *e, unsigned int flags)
{
    if ((flags & ENGINE_METHOD_CIPHERS) && !ENGINE_set_default_ciphers(e))
    return 0;
    if ((flags & ENGINE_METHOD_DIGESTS) && !ENGINE_set_default_digests(e))
    return 0;
#ifndef OPENSSL_NO_RSA
    if ((flags & ENGINE_METHOD_RSA) && !ENGINE_set_default_RSA(e))
    return 0;
#endif
#ifndef OPENSSL_NO_DSA
    if ((flags & ENGINE_METHOD_DSA) && !ENGINE_set_default_DSA(e))
    return 0;
#endif
#ifndef OPENSSL_NO_DH
    if ((flags & ENGINE_METHOD_DH) && !ENGINE_set_default_DH(e))
    return 0;
#endif
#ifndef OPENSSL_NO_ECDH
    if ((flags & ENGINE_METHOD_ECDH) && !ENGINE_set_default_ECDH(e))
    return 0;
#endif
#ifndef OPENSSL_NO_ECDSA
    if ((flags & ENGINE_METHOD_ECDSA) && !ENGINE_set_default_ECDSA(e))
    return 0;
#endif
    if ((flags & ENGINE_METHOD_RAND) && !ENGINE_set_default_RAND(e))
    return 0;
    if ((flags & ENGINE_METHOD_PKEY_METHS)
    && !ENGINE_set_default_pkey_meths(e))
    return 0;
    if ((flags & ENGINE_METHOD_PKEY_ASN1_METHS)
    && !ENGINE_set_default_pkey_asn1_meths(e))
    return 0;
    return 1;
}

(from the openssl 1.0.2 source tree)
It could be that one of those methods is not throwing the errors with 
your smart card.
I'd advise you to test your smart card capabilities . It might also be 
useful to do more command line testing with your smartcard using


  engine - -t dynamic -pre 
"SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll" 
-pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre "MODULE_PATH:C:\Program 
Files (x86)\HID Global\ActivClient\\acpkcs211.dll"


and then try out certai

Re: private key not available for client_cert_cb

[Jan Just Keijser]

Hi,

On 19/12/20 04:48, George wrote:

Hi,

  I narrowed the problem down to
ENGINE_set_default(pkey_engine, ENGINE_METHOD_ALL)

This causes the initial exception
Exception thrown at 0x757346D2 in GENCom.exe: Microsoft C++ exception: 
unsigned long at memory location 0x006FCD68.


It looks like some of the Engine methods cause an exception, but not 
all of them:

*
Works:*
ENGINE_METHOD_CIPHERS
ENGINE_METHOD_DIGESTS
ENGINE_METHOD_DSA
ENGINE_METHOD_DH
ENGINE_METHOD_RAND
ENGINE_METHOD_PKEY_ASN1_METHS

*Causes An Exception:*
ENGINE_METHOD_RSA
ENGINE_METHOD_ECDH
ENGINE_METHOD_ECDSA
ENGINE_METHOD_PKEY_METHS


Is that normal behaviour, or is something wrong? Is there a way to 
find the supported engine methods to avoid triggering an exception?


I'd say no engine/pkcs11 module should trigger exceptions - that's an 
error in the pkcs11 module.


Something you can try is this:

run the 'openssl.exe' command:

openssl engine -t dynamic -pre 
"SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll" 
-pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre "MODULE_PATH:C:\Program 
Files (x86)\HID Global\ActivClient\\acpkcs211.dll"


then on the OpenSSL prompt , try

  s_client -keyform engine -key 0:  -cert "clientcert.pem"  
-connect remote_host:remote_port


that should start a TLS connection and use the pcks11 engine to ask for 
the key , identified by  in slot 0 (adjust the slot number if 
your smart card starts at number 1 etc.


HTH,

JJK





It seems like alot of other smaple code I have looked at calls
ENGINE_init(pkey_engine);

Is the needed? When I call it, it always returns with "0". Should it 
be returning with "1"?


I did some testing in the OpenSSL command line, and here is what I found:

- The command line "speed" test appears to be fine:

OpenSSL> speed -engine pkcs11
engine "pkcs11" set.
Doing mdc2 for 3s on 16 size blocks: 2688737 mdc2's in 2.98s
Doing mdc2 for 3s on 64 size blocks: 880529 mdc2's in 3.00s
Doing mdc2 for 3s on 256 size blocks: 240916 mdc2's in 2.98s
Doing mdc2 for 3s on 1024 size blocks: 61287 mdc2's in 3.00s
Doing mdc2 for 3s on 8192 size blocks: 7774 mdc2's in 2.98s
.
.
.

-  I also tried the following, which successfully created the PEM
files:

OpenSSL> req -engine pkcs11 -new -key
"pkcs11:object=Authentication -
*;type=private;pin-value=123456" -keyform engine -out req2.pem
-text -x509 -subj "/CN=*"
OpenSSL> x509 -engine pkcs11 -signkey
"pkcs11:object=Authentication -
    *;type=private;pin-value=123456" -keyform engine -in req2.pem
-out cert2.pem





Thanks,
George


On 2020-12-18 3:40 a.m., Jan Just Keijser wrote:

Hi,

On 18/12/20 06:21, George wrote:

Hi,

   I'm able to setup the engine now, but as soon as I attempt to 
execute the command

ENGINE_set_default(pkey_engine, ENGINE_METHOD_ALL);
,I see all kinds of middleware exceptions being generated:

Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ 
exception: unsigned long at memory location 0x07FCFA00.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ 
exception: AI::Middleware::CMWException at memory location 0x032FD2D0.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ 
exception: AI::Middleware::CMWException at memory location 0x032FD2D0.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ 
exception: AI::Middleware::CMWException at memory location 0x032FD2D0.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ 
exception: AI::Middleware::CMWException at memory location 0x032FD2D0.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ 
exception: AI::Middleware::CMWException at memory location 0x032FD2D0.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ 
exception: AI::Middleware::CMWException at memory location 0x032FD2D0.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ 
exception: AI::Middleware::CMWException at memory location 0x032FD2D0.
Exception thrown at 0x773046D2 in GENCom.exe: Microsoft C++ 
exception: AI::Middleware::CMWException at memory location 0x032FD2D0.

.
.
.


Do you have any idea what is causing these errors? Am I missing 
something in the configuration? When I use the OpenSSL command line 
debugger, there are no errors:


OpenSSL> engine -t dynamic -pre 
"SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll" 
-pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre 
"MODULE_PATH:C:\Program Files (x86)\HID 
Global\ActivClient\\acpkcs211.dll"

(dynamic) Dynamic engine loading support
[Success]: 
SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll

[Success]: ID:pkcs11
[Success]: LIST_ADD:1
[Success]: LOAD
[Success]: MODULE_PATH:C:\Program Files (x86)\HID 
Globa

Re: private key not available for client_cert_cb

[Jan Just Keijser]

Hi,

On 20/12/20 09:39, George wrote:

Hi,

   I tried running the "s_client" command and it appears to be working.

I guess there must be something wrong in my code.


it is good news that the s_client command is working - it means there is 
something wrong with your code but you have everything at hand to fix 
it: download the openssl 1.0.2 tarball / zip file and look for the files

  apps/s_client.c
  apps/apps.c

that contains all of the code that the 's_client' command uses to make a 
connection and my bet is that is also does not call ENGINE_init

My crash occurs when I call

ENGINE_init(pkey_engine);

I notice your code does not call this function.  Is this needed 
needed? If so, when/where should it be called?


tbh,  I don't know - look through the openssl sources to see what it 
does, exactly.



What exactly is the definition of "pkey_identifier" in

ENGINE_load_private_key(pkey_engine, *pkey_identifier*,
transfer_pin, &cb_data) ?


I'm not clear on what this value should be. Can you give an example of 
what it would look like?


I have the following on my smart card:

Private Key Object; RSA
  label:  Authentication - *
*ID:**2b2586c684d69b670c0a805edf514e720f2b757d8e2faa0b3a7ff23d1ccfc7ba*
  Usage:  unwrap
  Access: sensitive, never extractable
  Allowed mechanisms: RSA-PKCS,RSA-X-509


Would the *pkey_identifier* be the *ID* in the above?

yes, although if you have multiple smartcards inserted at the same time 
then it helps to add the slot number, e.g.

  0:




What exactly is "prompt_info" in the structure PW_CB_DATA?
i.e.
typedef struct pw_cb_data {
    const void* password;
    const char* *prompt_info;*
} PW_CB_DATA;
Can you give an example of what it might look like?

Is the value of cb_data populated by the transfer_pin callback 
functions, or should it already contain a value when 
ENGINE_load_private_key is called?


Is there a way to skip the callback transfer_pin and use a hard coded 
pin for test purposes when calling ENGINE_load_private_key(...)?


my eap-tls code does just that: if the password is specified in  the ppp 
config file then the user is not prompted:


    if (pkey_engine)
    {
    EVP_PKEY   *pkey = NULL;
    PW_CB_DATA  cb_data;
    UI_METHOD* transfer_pin = NULL;

    cb_data.password = passwd;
    cb_data.prompt_info = pkey_identifier;


HTH,

JJK


On 2020-12-19 8:05 p.m., Jan Just Keijser wrote:


I'd say no engine/pkcs11 module should trigger exceptions - that's an 
error in the pkcs11 module.


Something you can try is this:

run the 'openssl.exe' command:

openssl engine -t dynamic -pre 
"SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll" 
-pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre "MODULE_PATH:C:\Program 
Files (x86)\HID Global\ActivClient\\acpkcs211.dll"


then on the OpenSSL prompt , try

  s_client -keyform engine -key 0:  -cert "clientcert.pem"  
-connect remote_host:remote_port


that should start a TLS connection and use the pcks11 engine to ask 
for the key , identified by  in slot 0 (adjust the slot 
number if your smart card starts at number 1 etc.


HTH,

JJK

Re: private key not available for client_cert_cb

[Jan Just Keijser]

Hi,

On 05/01/21 07:39, George wrote:

Hi,

    I was looking at the  code in 
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c and 
realized I forgot to call ENGINE_ctrl_cmd(...) to setup 
"LOAD_CERT_CTRL". However, when I do this, the callback function is no 
longer being called during the mutual authentication handshake. I'm 
wondering if I have the parameter "cert_info.s_slot_cert_id" 
incorrectly configured. Here is what my code looks like:


struct
{
   const char* s_slot_cert_id;
   X509* cert;
} cert_info;
*cert_info.s_slot_cert_id =
"a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45";*
cert_info.cert = NULL;

*ENGINE_ctrl_cmd(engine, "LOAD_CERT_CTRL", 0, &cert_info, NULL, 0);*
*SSL_CTX_use_certificate(sslContext, cert_info.cert);*


I tried manually using LOAD_CERT_CTRL in the openssl shell but I 
cannot seem to get it to work and cannot find any examples of how to 
use it.  Is the syntax for *LOAD_CERT_CTRL* correct? I am 
using***"LOAD_CERT_CTRL:".*


OpenSSL> engine - -t dynamic -pre
"SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll"
-pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre
"MODULE_PATH:C:\Program Files (x86)\HID
Global\ActivClient\\acpkcs211.dll" -pre PIN:123456 -pre
FORCE_LOGIN *-pre

"LOAD_CERT_CTRL:a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45"

*(dynamic) Dynamic engine loading support
[Success]:
SO_PATH:C:\\Users\\whipp\\junk4\\libp11-libp11-0.4.11\\src\\pkcs11.dll
[Success]: ID:pkcs11
[Success]: LIST_ADD:1
[Success]: LOAD
[Success]: MODULE_PATH:C:\Program Files (x86)\HID
Global\ActivClient\\acpkcs211.dll
[Success]: PIN:123456
[Success]: FORCE_LOGIN
*[Failure]:

LOAD_CERT_CTRL:a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45**
**4196:error:260AB086:engine routines:ENGINE_ctrl_cmd_string:cmd
not executable:.\crypto\engine\eng_ctrl.c:316:*
Loaded: (pkcs11) pkcs11 engine
 [ available ]
 SO_PATH: Specifies the path to the 'pkcs11' engine shared library
  (input flags): STRING
 MODULE_PATH: Specifies the path to the PKCS#11 module shared
library
  (input flags): STRING
 PIN: Specifies the pin code
  (input flags): STRING
 VERBOSE: Print additional details
  (input flags): NO_INPUT
 QUIET: Remove additional details
  (input flags): NO_INPUT
*LOAD_CERT_CTRL: Get the certificate from card**
**  (input flags): [Internal]*
 INIT_ARGS: Specifies additional initialization arguments to
the PKCS#11 module
  (input flags): STRING
 SET_USER_INTERFACE: Set the global user interface (internal)
  (input flags): [Internal]
 SET_CALLBACK_DATA: Set the global user interface extra data
(internal)
  (input flags): [Internal]
 FORCE_LOGIN: Force login to the PKCS#11 module
  (input flags): NO_INPUT
OpenSSL>


I'm using the certificate object ID 
"a9bee4d72100c52f77c3fc288d2be01a34b5d44f91b3b7ea3d349b8a25752c45" for 
LOAD_CERT_CTRL. Is this right? (I also tried adding "0:" in front of 
it to indicate slot 0, but that did not work either.



this has little to do with OpenSSL at the moment and more with libp11 - 
perhaps someone more knowledgable on the libp11 mailing list can help you.


I'd try to use
  -post LOAD_CERT_CTRL
instead of '-pre', as you want this done after the engine has been loaded.

The cert ID does look OK. Note that if you want to use the s_client 
command that you canNOT specify the certificate form '-certform engine' 
as the code does not grok that.


HTH,

JJK

Re: Random and rare Seg faults at openssl library level

[Jan Just Keijser]

Hi,

On 06/01/21 18:10, Gimhani Uthpala wrote:

Dear team,
I'm running an application which uses openssl for secure communication 
between processes. I am getting seg-faults at openssl level. This only 
occurred very randomly and the following are stacks that seg faults  
at openssl level in the given 2 cases. We are using openssl 1.0.2k.



version 1.0.2k suggests you are using RHEL7/CentOS 7, correct?
Went through the security vulnerabilities list for this version but 
couldn't find a clue. Running valgrind too didn't give an exact clue 
related to the issue. Can you please guide me how can I find the exact 
root cause for the seg fault?


I am calling SSL_do_handshake(ssl_ctx) from my code level and both the 
below seg faults are occuring from it's inside.


#0  0x7fd64cdabdd3 in ASN1_item_verify () from /lib64/libcrypto.so.10
#1  0x7fd64cdcac58 in internal_verify () from /lib64/libcrypto.so.10
#2  0x7fd64cdccaef in X509_verify_cert () from /lib64/libcrypto.so.10
#3  0x7fd64d111c68 in ssl_verify_cert_chain () from 
/lib64/libssl.so.10
#4  0x7fd64d0e8cc6 in ssl3_get_client_certificate () from 
/lib64/libssl.so.10

*#5  0x7fd64d0ea3f8 in ssl3_accept () from /lib64/libssl.so.10*


so the segfault occurs inside ASN1_item_verify () when verifying the 
certificate - it could be a malformed certificate with invalid ASN1 
encoding; do you have the certificate that causes the segfault?


If you do not, then it is worthwhile recording/storing all certificates 
until you find the one that causes the segfault and then examine it.



HTH,

JJK

Re: Random and rare Seg faults at openssl library level

[Jan Just Keijser]

On 06/01/21 21:57, Michael Wojcik wrote:


The same way you'd track down an intermittent cause of Undefined Behavior in 
any other program: some combination of dynamic monitoring, symbolic execution, 
static code analysis, source code review, testing variants, tracing, fuzzing, 
post-mortem analysis, and so on. This isn't specific to OpenSSL.

But you're asking the wrong question. The correct question is: Why are you 
using an outdated version of OpenSSL?


possibly because:

$ cat /etc/redhat-release && openssl version
CentOS Linux release 7.9.2009 (Core)
OpenSSL 1.0.2k-fips  26 Jan 2017

?

Re: private key not available for client_cert_cb

[Jan Just Keijser]

Hi,

On 08/01/21 22:35, George wrote:

Hi,

   I have been trying to setup mutual authentication using a smart 
card but I can't seem to get the OpenSSL Engine to send a response 
back to the server containing client's certificate from the smart card.


I'm using the following to configure the certificate and private key:

    ENGINE_ctrl_cmd(engine, "LOAD_CERT_CTRL", 0, &cert_info, NULL, 0);
    SSL_CTX_use_certificate(sslContext, cert_info.cert);

    EVP_PKEY* privateKey = ENGINE_load_private_key(engine, 
"2b2586c684d69b670c0a805edf514e720f2b757d8e2faa0b3a7ff23d1ccfc7ba", 
transfer_pin, &cb_data);

    SSL_CTX_use_PrivateKey(sslContext, privateKey);

(I have been using the code in 
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c as a guide.)


This seems be successful. However, when I start the mutual 
authentication with

SSL_connect(ssl)
, the mutual authentications handshake fails. I can see the server 
requesting the certificate from the client and the client sends back 
an ACK for this message. However, the client does not send the 
certificate to the server.


I was looking through the OpenSSL code openssl-1.0.2u\ssl\ssl_rsa.c 
and noticed something interesting. The comment indicates that the flag 
*RSA_METHOD_FLAG_NO_CHECK* should be set for smart cards:


static int ssl_set_pkey(CERT *c, EVP_PKEY *pkey)
{
 . . .
#ifndef OPENSSL_NO_RSA
*   /***
** * Don't check the public/private key, this is mostly for 
smart**

** * cards.**
** */*
    if ((pkey->type == EVP_PKEY_RSA) &&
    (RSA_flags(pkey->pkey.rsa) & RSA_METHOD_FLAG_NO_CHECK)) ;
    else
#endif
. . .
}

However, it is not actually set when I use a debugger to inspect the 
flag. Does it need to be set? If so, how is this done? I could not 
find anything related to this in

https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c



if you read through the code blob that Michael pointed you to, you will 
find that this flag needs to be set *under certain circumstances* when 
using smartcards. It has to do mostly with the situation where

- private key is on the smart card
- the public key/certificate is NOT on the smart card
- you ask OpenSSL to verify the private key without explicitly providing 
a public key.


I've never run into this issue, but then again, I have not tested very 
often the case where the certificate was not present on the HSM/smart 
card but the private key is.  YMMV.


As for using pksc11helper versus using libp11: that is just a matter of 
taste. I used the engine_pkcs11 + libp11 route for the eap-tls code , 
mostly because it was the first "working" set of tools I found at the time.


You can also take the "pkcs11helper" route, which is what OpenVPN does 
(see https://github.com/openvpn).  Both methods have pro's and con's.


Do you run into problems if you DO not set the RSA_METHOD_FLAG_NO_CHECK 
flag?  All that flag does is to stop OpenSSL from verifying that a 
public key/cert and private key match/belong together for RSA keys only; 
if your smartcard supports EC keys then this flag will do you no good.


HTH,

JJK

Re: Random and rare Seg faults at openssl library level

[Jan Just Keijser]

Hi,

On 07/01/21 23:53, Gimhani Uthpala wrote:



On Thu, Jan 7, 2021 at 3:08 AM Ken Goldman > wrote:


On 1/6/2021 12:10 PM, Gimhani Uthpala wrote:

> I am getting seg-faults at openssl level. This only
occurred very randomly and the following are stacks that seg
faults  at openssl level in the given 2 cases. We are using
openssl 1.0.2k.

The usual cause is that you are compiling with one version of
openssl and (static or dynamic) linking with a different one.
The cause of that is typically that you have more than one version
of openssl installed.

If this is a 3rd party application, not one you're building, you
have to find out what version of openssl they expect.



I only have this 1.0.2.k-fips one version installed in both compiling 
and running machines. However, I am compiling the application in RH7.4 
and running in RH7.8 linking to openssl library dynamically. I assume 
no issue with that as I am using the same version of openssl in both.


actually - there could be an issue with that, as RedHat has this 
tendency to patch openssl between releases (mostly backporting security 
fixes from openssl 1.1.x to 1.0.2k).


Have you tried installing the debuginfo package for openssl so that the 
stacktrace will show you better info:

  debuginfo-install openssl-libs openssl

right now all you know is that the segfault occurs *somewhere* within 
ASN1_item_verify ()


HTH,

JJK

Re: OpenSSL 1.1.1g Windows build slow rsa tests

[Jan Just Keijser]

Hi Dan,

On 21/01/21 19:22, Dan Heinz wrote:

[...]


Thank you all for the helpful suggestions. When I removed no-asm and 
built using nmake in the Developer Command Prompt for Visual Studio 
2015, I ended up getting an error "VC-WIN64A X86 conflicts with target 
x64". From the command prompt I ran cl and saw this "Microsoft (R) 
C/C++ Optimizing Compiler Version 19.00.24215.1 for x86". So I was 
building for x86? I'm not sure why it built with no-asm, but it did.

Once I ran the correct command prompt (I used Visual Studio x64 Native Tools 
Command Prompt), I saw a huge speed increase.  For example, 2048 bits:
Doing 2048 bits private rsa's for 10s: 8384 2048 bits private RSA's in 10.02s
Doing 2048 bits public rsa's for 10s: 236090 2048 bits public RSA's in 9.98s

Previously, I saw:
Doing 2048 bits private rsa's for 10s: 409 2048 bits private RSA's in 10.00s
Doing 2048 bits public rsa's for 10s: 15663 2048 bits public RSA's in 10.02s

For further testing, I added back no-asm and my speed tests were in line with 
the downloaded openssl binary I was testing with.
Doing 2048 bits private rsa's for 10s: 1868 2048 bits private RSA's in 10.00s
Doing 2048 bits public rsa's for 10s: 71338 2048 bits public RSA's in 10.02s

You can see removing no-asm does make a pretty large speed increase too.

In summary, using the correct build tools helps (although I am surprised it 
built with no-asm).  And removing no-asm sped things up.


Not sure why you'd want to do a 'no-asm' build to begin with, but 
another thing worth testing with your "asm" build is to run the speed 
test like this:

 set OPENSSL_ia32cap=0
 openssl speed rsa
(Linux/UNIX:  OPENSSL_ia32cap=0 openssl speed rsa)

On my (10th gen Intel ) laptop this gives me a ~35% performance hit. 
Explanation:
- no-asm build -> compiler generates all code, no hand-tuned assembly 
used at all; should be slowest


- asm build + OPENSSL_ia32cap=0  -> no newer CPU features used, but 
hand-tuned assembly is used. Especially AES encryption takes a hit if 
you disable these newer features


- asm build -> hand-tuned assemby, including the use of all new CPU 
features such as AES, SHA etc.


I've found that this sometimes helps manage expectations when the "build 
environment" CPU and the "runtime environment" CPU are very different. 
I've seen a developer claim his/her code runs blazingly fast on his/her 
Core i7 bla bla but when deploying it on a cheaper runtime device 
performance is terrible.


Note that no-asm + OPENSSL_ia32cap=0 should not have any effect compared 
to "no-asm".


JM2CW,

JJK / Jan Just Keijser

Re: UI_METHOD functions not being invoked for smart card

[Jan Just Keijser]

On 26/01/21 05:28, George wrote:

Hi,

    I'm trying to get OpenSSL 1.0.2u with the FIPS Object Module 
2.0.16  in Windows 10 to prompt the user for a smart card's PIN number 
every time the application is launched. However, I cannot seem to get 
it to work. My UI_METHOD callback functions are not being invoked.


I'm using the following code as a reference:
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c

I tried the following:

UI_METHOD* transfer_pin = UI_create_method("transfer_pin");

int writer (UI *ui, UI_STRING *uis)
{
    PW_CB_DATA* cb_data = (PW_CB_DATA*)UI_get0_user_data(ui);
    UI_set_result(ui, uis, cb_data->password);
    return 1;
};
int stub (UI* ui) {return 1;};
int stub_reader (UI *ui, UI_STRING *uis) {return 1;};

UI_method_set_writer(transfer_pin,  writer);
UI_method_set_opener(transfer_pin,  stub);
UI_method_set_closer(transfer_pin,  stub);
UI_method_set_flusher(transfer_pin, stub);
UI_method_set_reader(transfer_pin,  stub_reader);

pkey = ENGINE_load_private_key(pkey_engine, pkey_identifier,
transfer_pin, &cb_data);



However, none of the callback functions "writer", "stub", or 
"stub_reader" actually get called. Do I need to do anything else to 
enable this functionality?  I would like to force the user to enter 
PIN number every time.




this depends on how openssl for windows was built ; some non-UNIX builds 
set the flag OPENSSL_NO_UI_CONSOLE  (or possibly OPENSSL_NO_UI) in which 
case all UI_methods are effectively disabled. If this flag is set for 
your build then you will have to rebuild OpenSSL.


Apart from that, that code snippet above is not the cleanest code I have 
ever written  - some C/C++ compilers do not like functions defined 
insides an  "if { } " block; you might have to take the function "int 
writer { } " outside of the "if { } " block.


HTH,

JJK

Re: Version compatibility issues - Re: openssl development work / paid - SSL now FIXED

[Jan Just Keijser]

On 28/03/21 15:20, Yassine Chaouche wrote:


Le 3/26/21 à 12:35 PM, Embedded Devel a écrit :

This has now been fixed SSL is working


In a few hours ?

Yup, took me about 4 hours to understand the problem and get a working 
fix - there wasn't much wrong with the code itself, but I suspect a 
weird interaction/build issue with the OpenWRT build of OpenSSL 1.1.1j.


JJK

Re: Compute HMAC using nCipher ENGINE and HSM-based symmetric key

[Jan Just Keijser]

Hi,

On 30/03/21 20:58, Ron Kundla wrote:

Hello!

I have a requirement to generate a HMAC value using a secret/symmetric
key inside the HSM. I have seen examples that use public/private keys
to do such a thing, but nothing that would use an AES or a
nCipher-specific HMAC key.

Does OpenSSL support this function using the ENGINE subsystem?


OpenSSL supports this, but not many HSMs do; you can take a look at the 
/dev/crypto engine for an example;  the corresponding bits in the 
OpenSSL source code are in .../engine/crypto/eng_devcrypto.c


I have never seen a PKCS#11 device that support symmetric keys though - 
but there will be plenty of SSL accelerator cards out there that do (but 
I would not call them HSMs).


HTH,

JJK

Re: Why does OpenSSL report google's certificate is "self-signed"?

[Jan Just Keijser]

On 31/03/21 19:43, Michael Wojcik wrote:

From: openssl-users  On Behalf Of Viktor
Dukhovni
Sent: Wednesday, 31 March, 2021 10:31
To: openssl-users@openssl.org
Subject: Re: Why does OpenSSL report google's certificate is "self-signed"?

It looks like Google includes a self-signed root CA in the wire
certificate chain, and if no match is found in the trust store,
you'll get the reported error.

What do people think about this practice of including the root in the chain?

As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say 
anything about the practice, though I may have missed something. I had a vague memory 
that some standard or "best practice" guideline somewhere said the server 
should send the chain up to but not including the root, but I don't know what that might 
have been.

On the one hand, including the root doesn't help with path validation: either 
some certificate along the chain is a trust anchor already, in which case 
there's no need to include the root; or it isn't, in which case the peer has no 
reason to trust the chain.

On the other, it's useful for debugging, and perhaps for quickly finding 
whether the highest intermediate in the chain is signed by a trusted root if 
that intermediate is missing an AKID (though we'd hope that isn't the case).

I can also see an application deferring trust to the user in this case: "this chain 
ends in this root, which you don't currently trust, but maybe you'd like to add 
it?". Which doesn't seem like a great plan either -- and PKIX says trust anchors 
should be added using a trustworthy out-of-band procedure, which this is not -- but I 
suppose it's a conceivable use case.


The only thing I'd like to add to this is that whenever I *do* include 
the root anchor in a website and run Qualys' ssllabs test on it, I get a 
(minor) warning:


Additional Certificates (if supplied)
Certificates provided     3 (5051 bytes)
*Chain issues     Contains anchor*

Unfortunately their documentation does not state *why* they print out 
this warning or why it would be bad, but I normally remove the trust 
anchor from the webserver certificate chain nevertheless.  It could very 
well be that I'm not the only web admin that follows their advice in 
this respect.


JM2CW,

JJK / Jan Just Keijser

Re: Why does OpenSSL report google's certificate is "self-signed"?

[Jan Just Keijser]

On 01/04/21 09:49, Dr Paul Dale wrote:
Perhaps ask Qualys to answer your concerns directly?  They must have a 
reason for including this warning.



oh, I am not particularly /concerned/ about it  - it's just that I 
noticed Qualys spits out this warning whenever I do include the root 
anchor, without bothering to tell me *why*. A search points me to this 
discussion:

  https://qualys-secure.force.com/discussions/s/article/03197

which says it is harmless to include the root anchor, except that it 
will increase your site's latency due to a (slightly) larger TLS handshake.


cheers,

JJK / Jan Just Keijser



On 1/4/21 5:43 pm, Jan Just Keijser wrote:

On 31/03/21 19:43, Michael Wojcik wrote:

From: openssl-users  On Behalf Of Viktor
Dukhovni
Sent: Wednesday, 31 March, 2021 10:31
To:openssl-users@openssl.org
Subject: Re: Why does OpenSSL report google's certificate is "self-signed"?

It looks like Google includes a self-signed root CA in the wire
certificate chain, and if no match is found in the trust store,
you'll get the reported error.

What do people think about this practice of including the root in the chain?

As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say 
anything about the practice, though I may have missed something. I had a vague memory 
that some standard or "best practice" guideline somewhere said the server 
should send the chain up to but not including the root, but I don't know what that might 
have been.

On the one hand, including the root doesn't help with path validation: either 
some certificate along the chain is a trust anchor already, in which case 
there's no need to include the root; or it isn't, in which case the peer has no 
reason to trust the chain.

On the other, it's useful for debugging, and perhaps for quickly finding 
whether the highest intermediate in the chain is signed by a trusted root if 
that intermediate is missing an AKID (though we'd hope that isn't the case).

I can also see an application deferring trust to the user in this case: "this chain 
ends in this root, which you don't currently trust, but maybe you'd like to add 
it?". Which doesn't seem like a great plan either -- and PKIX says trust anchors 
should be added using a trustworthy out-of-band procedure, which this is not -- but I 
suppose it's a conceivable use case.


The only thing I'd like to add to this is that whenever I *do* 
include the root anchor in a website and run Qualys' ssllabs test on 
it, I get a (minor) warning:


Additional Certificates (if supplied)
Certificates provided     3 (5051 bytes)
*Chain issues     Contains anchor*

Unfortunately their documentation does not state *why* they print out 
this warning or why it would be bad, but I normally remove the trust 
anchor from the webserver certificate chain nevertheless.  It  could 
very well be that I'm not the only web admin that follows their 
advice in this respect.


JM2CW,

JJK / Jan Just Keijser

Re: Porting to version 1.1.1 with old Linux kernel 3.0.8

[Jan Just Keijser]

On 05/04/21 22:07, Boris Shpoungin via openssl-users wrote:

Thank you for response.

Could you suggest best approach for porting application from 1.0.2 to 
1.1.1?

So far I've found good manual which describes required modifications:
https://wiki.tizen.org/Security/Tizen_5.X_Migration_from_OpenSSL_1.0.2_to_OpenSSL_1.1.1_guide

The question is whether it describes ALL required modification?

I'd say you're better off asking this question on a Tizen mailing list; 
the list looks pretty exhaustive but does it list everything? only one 
way to find out: recompile your application using openssl 1.1.1 and see 
if/where it breaks.


If you are worried about the combination of Linux 3.0.8 plus the switch 
from openssl 1.0.2 -> 1.1.1 then I'd suggest a three step process
1) build openssl 1.1.1 on your old kernel and run 'make test' if that 
passes, then openssl is functional ; if it does not pass these tests, 
then figure out what's wrong before proceeding
2) get yourself a Linux vm with a newer kernel and with a known-to-work 
openssl 1.1.1 (Fedora 33 & Ubuntu 20, CentOS 8 would work) then rebuild 
and relink your application on THAT platform, recording all required changes

3) finally, rebuild your ported application on the older Linux kernel

HTH,

JJK



On Monday, April 5, 2021, 03:57:36 PM EDT, Viktor Dukhovni 
 wrote:




> On Apr 5, 2021, at 11:16 AM, Boris Shpoungin via openssl-users 
mailto:openssl-users@openssl.org>> wrote:

>
> Is there minimal requirements for Linux kernel for usage of openssl 
library version 1.1.1?

>
> I have old application based on Linux kernel 3.0.8 which uses 
openssl version 1.0.2. My question is whether it is possible to port 
this application to use openssl version 1.1.1 in Linux 3.0.8 environment?



The version of the Linux kernel is almost certainly irrelevant.  OpenSSL
makes minimal demands of the operating system.  Only random number 
generation
is plausibly something you need to think about.  The getrandom(2) 
kernel API

was added in Linux 3.17, so you'll need to use /dev/urandom instead.

Otherwise, sockets, threads, ... are all present in Linux even before 3.0.

--
    Viktor.

Re: Porting to version 1.1.1 with old Linux kernel 3.0.8

[Jan Just Keijser]

On 05/04/21 17:16, Boris Shpoungin via openssl-users wrote:

Hello,

Is there minimal requirements for Linux kernel for usage of openssl 
library version 1.1.1?


I have old application based on Linux kernel 3.0.8 which uses openssl 
version 1.0.2. My question is whether it is possible to port this 
application to use openssl version 1.1.1 in Linux 3.0.8 environment?


If yes, then any useful info about "how to" will be greatly appreciated.


And FWIW:

I just built and tested openssl 1.1.1k successfully on a 32bit CentOS 6 
vm with kernel 2.6.32 - so if *THAT* works then surely kernel 3.0.8 will 
also work:


All tests successful.
Files=158, Tests=2635, 121 wallclock secs ( 1.21 usr  0.15 sys + 98.81 
cusr 10.06 csys = 110.23 CPU)

Result: PASS


HTH,

JJK

PS getting the tests to run on centos 6 was the biggest hurdle , not 
openssl itself

Re: X509_sign_ctx and ENGINE

[Jan Just Keijser]

Hi,

On 13/04/21 17:05, Ron Kundla wrote:

Hello,

I am trying to adapt a piece of software to use an nCipher HSM using
OpenSSL 1.1.1j along with the nfkm.dll engine library from nCipher.

One function uses X509_sign_ctx() to calculate a SHA256 digest and
sign a X509 certificate using RSA-PSS.

I am running a debug version of x64 on Windows and I get the following
error while executing the function rsa_pmeth.c:RSA_private_encrypt()

error:06078081:digital envelope routines:EVP_PKEY_get0_DSA:expecting a dsa key

This is the code that generates the error above:

if (rsa->d == NULL) {
 RSAerr(RSA_F_RSA_OSSL_PRIVATE_ENCRYPT, RSA_R_MISSING_PRIVATE_KEY);
 BN_free(d);
 goto err;
 }

The debugger shows me that the RSA structure does not have any RSA key
data inside of it, which would be due to the fact that it is in the
HSM. I did use ENGINE_load_private_key() to create a PKEY that does
show references to the engine structure and associated methods.

My first guess is that X509_sign_ctx is not 'ENGINE' compatible. While
the PKEY has an engine associated with it, there may not be the hooks
to invoke the ENGINE private encryption method.

Is there another way I can use OpenSSL functions to allow it to work
with the ENGINE to do the exact same thing mentioned above? Or is the
only way to make this work requrire X509_sign_ctx to be modified to
support ENGINE operation?


I'd suggest to read the source code of the openssl 'req' command 
(./apps/req.c) , as it is capable of generating an X509 request from a 
token;  as a matter of fact, you will find that that code calls 
X509_sign_ct(...)


So I'd get the certificate request generation working first using
  openssl req -engine pkcs11 -keyform engine -key [:]12345678 
-new -text

   -out newcert.csr -config openssl.cnf -subj $SUBJECT

first with the nCipher HSM and if that works, then look at your code.

HTH,

JJK

Re: Linker failure after compilation with "enable-crypto-mdebug"

[Jan Just Keijser]

Hi,

On 26/04/21 20:29, Robert Smith via openssl-users wrote:

Hello everyone.

I'm trying to recompile OpenSSL version 1.1.1k under Windows 10 with 
the following configuration flag enable-crypto-mdebug

and getting the following linker error:


 Creating library apps\openssl.lib and object apps\openssl.exp
openssl.obj : error LNK2019: unresolved external symbol 
_CRYPTO_mem_leaks referenced in function _main

apps\openssl.exe : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio 10.0\VC\BIN\link.EXE"' : return code '0x460'

Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio 10.0\VC\BIN\nmake.exe"' : return code '0x2'

Stop.

Wasted already a few hours trying to figure out the cause for this 
failure.


when building and linking with "enable-crypto-mdebug" set the file 
"crypto/mem_dbg.o" needs to be included in the library libcrypto.a (or 
crypto.lib); check that this file is indeed included when creating the 
crypto library.


For the record: a Linux build with "enable-crypto-mdebug" works fine.

HTH,

JJK

Re: Linker failure after compilation with "enable-crypto-mdebug"

[Jan Just Keijser]

Hi,

On 28/04/21 21:22, Robert Smith wrote:

Hi Jan,

Thank you for your response.
Obviously the file mem_dbg is not included and that is why I am having 
this problem.


The questions are:
Whether the "enable-crypto-mdebug" flag supported in Windows at all?

Whether this is known issue?

What control do I have over Windows build (I mean how can I include or 
exclude certain file)? My assumption was if I have to mess with 
Windows build scripts, I am in the wrong direction. However I could be 
I wrong ...


Whether the file mem_dbg was excluded on purpose from Windows build?


there does not seem to be anything specific about mem_dbg ; I don't have 
Visual Studio but if I do a mingw64 build of openssl 1.1.1k with 
"enable-crypto-mdebug" set then it builds just fine.


How did you configure openssl ? what command did you run and what build 
environment are you using? msys?


It will also be interesting to see the output of
  perl configdata.pm --dump
after you've run  the Configure script - that should tell you whether 
mdebug is enabled or not:


    crypto-mdebug   [default] OPENSSL_NO_CRYPTO_MDEBUG

is the default.

HTH,

JJK


On Wednesday, April 28, 2021, 06:51:36 AM EDT, Jan Just Keijser 
 wrote:



Hi,

On 26/04/21 20:29, Robert Smith via openssl-users wrote:
Hello everyone.

I'm trying to recompile OpenSSL version 1.1.1k under Windows 10 with 
the following configuration flag enable-crypto-mdebug

and getting the following linker error:


 Creating library apps\openssl.lib and object apps\openssl.exp
openssl.obj : error LNK2019: unresolved external symbol 
_CRYPTO_mem_leaks referenced in function _main

apps\openssl.exe : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio 10.0\VC\BIN\link.EXE"' : return code '0x460'

Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio 10.0\VC\BIN\nmake.exe"' : return code '0x2'

Stop.

Wasted already a few hours trying to figure out the cause for this 
failure.



when building and linking with "enable-crypto-mdebug" set the file 
"crypto/mem_dbg.o" needs to be included in the library libcrypto.a (or 
crypto.lib); check that this file is indeed included when creating the 
crypto library.


For the record: a Linux build with "enable-crypto-mdebug" works fine.

HTH,

JJK

Re: Version compatibility issues - Re: openssl development work / paid

[Jan Just Keijser]

Just for the record:

On 26/03/21 09:51, Embedded Devel wrote:
i now have a second developer looking at this, so hoping he can sort 
it all out.



[...]

I was that second developer and even though 'Embedded Devel' listed this 
as "paid" work and even though he made repeated promises about following 
up on payment, I never did receive payment.


I checked the email address and IP addresses used for this job and found 
nothing terribly wrong. My conclusion is that either someone hijacked an 
email address - meaning that Optimcloud is not a very *safe* company to 
do business with -  or that 'Embedded Devel' at Optimcloud simply thinks 
he can get away with this - meaning that Optimcloud is not a very 
*trustworthy* company to do business with.


You have been warned.

JJK


On 26/03/21 09:51, Embedded Devel wrote:
i believe this was all from back in the 0.9x days, the code in 
question is close to 10+/- years old


if everyone would look at the email thread  re: "ssl client write / 
server accept seems broken"


some might see more of the issue i am facing, i have has 1 person look 
at this and he believes


quote "

This looks like using *very* outdated OpenSSL API. Hence the SSL
client (and server) code needs to ported to work with more recent
versions OpenSSL and make use of TLS methods instead of SSL methods.

For testing you could try to build OpenSSL with the old SSL3 support
enabled (we don't even support that at all in OpenWrt any longer, but
should work to build manually).
Because ssl_undefined_function is most likely a result of:
Disabled features:
...
    ssl3                    [default] OPENSSL_NO_SSL3
    ssl3-method             [default] OPENSSL_NO_SSL3_METHOD
...

If you find someone very familiar with OpenSSLs API (I've used it, more
than once, but it's not what I'm doing every day), this can be done in
a few days. I'd probably need a week for this and I'm not particularly
keen on it, there are things I'm better with which are waiting as well."

i now have a second developer looking at this, so hoping he can sort 
it all out.

Re: Version compatibility issues - Re: openssl development work / paid

[Jan Just Keijser]

First of all, apologies to this mailing list for making you part of this.
I will reply one more time , then take this discussion off-list.

On 04/05/21 07:24, Embedded Devel wrote:


On 5/3/21 2:20 PM, Jan Just Keijser wrote:

Just for the record:

On 26/03/21 09:51, Embedded Devel wrote:
i now have a second developer looking at this, so hoping he can sort 
it all out.



[...]

I was that second developer and even though 'Embedded Devel' listed 
this as "paid" work and even though he made repeated promises about 
following up on payment, I never did receive payment.


I checked the email address and IP addresses used for this job and 
found nothing terribly wrong. My conclusion is that either someone 
hijacked an email address - meaning that Optimcloud is not a very 
*safe* company to do business with -  or that 'Embedded Devel' at 
Optimcloud simply thinks he can get away with this - meaning that 
Optimcloud is not a very *trustworthy* company to do business with.


no actually, neither is the case. I submitted the work for payment, 
accounting inquired of the developer if it was all working and he 
stated it wasnt. So where it is, and its more i think we dont 
understand is when the client registers and is authorized it should 
generate a new xml config for the client, and right now there appears 
to be some mismatch, basically we have no idea how you had this 
working. so we are a month in from the work you did and i submitted 
payment for, and still have had 0 reproducability. Ive even reviewed 
the document you sent, as has he, and we are missing something.


This is the first time I hear of this. To get a few things straight (and 
I have the full email exchange at hand to back this up):
- 'embedded devel' originally asked for a developer to port old OpenSSL 
code to openssl 1.1+
- I offered to do this and ported the application to work with openssl 
1.1.1 within a few hours. 'embedded devel' agreed with me in email that 
I had achieved the original goal.
- after that, I offered to help in debugging the rest of the 
client/server application workflow, which was poorly documented but 
which had little to do with openssl specifics. I never offered or 
promised to get the entire client/server application framework working 
again.
- 'embedded devel' accepted my offer and said he had a fixed maximum 
amount that he could spend.
- I worked for the remainder of the time on analyzing and debugging the 
application workflow, even though it turned out that I was not given all 
source code. 'embedded devel' confirmed that a part was missing.
- I wrote a report with my findings and suggestions on how to proceed. 
'embedded devel' was satisfied with the report and told me he would ask 
accounting to pay me.
- after several reminders about payment he did not respond to my emails 
until I made my post yesterday, claiming for the first time that what I 
had done was not reproducible.


Reviewing this, I see no reason to change my viewpoint on the 
trustworthiness of either 'embedded devel' or the company Optimcloud.


[...]
Snipping out the rest of the mail as it is off-topic to this mailing 
list. I will reply to it privately.


JJK

Re: Version compatibility issues - Re: openssl development work / paid

[Jan Just Keijser]

Hi,

Apologies for top-posting, but I am glad to report that Optimcloud and I 
managed to resolve this issue. It turns out that some of my emails were 
not received and that the other party was not aware that I had *not* 
been paid.
Optimcloud promptly proceeded to pay the agreed sum, which I have now 
received.


I am also glad to report that - after more emails back and forth - he is 
now able to continue with the development of his application.


JJK / Jan Just Keijser


On 03/05/21 09:20, Jan Just Keijser wrote:

Just for the record:

On 26/03/21 09:51, Embedded Devel wrote:
i now have a second developer looking at this, so hoping he can sort 
it all out.



[...]

I was that second developer and even though 'Embedded Devel' listed 
this as "paid" work and even though he made repeated promises about 
following up on payment, I never did receive payment.

Re: How to set the different parameters of X509_STORE_CTX structure.

[Jan Just Keijser]

Hi,

On 26/05/21 10:15, Kumar Mishra, Sanjeev wrote:

Hi,

I am upgrading the code of OpenSSL 1.0 to 3.0. I am not getting some 
API for setting some parameter of X509_STORE_CTX structure as it is 
opaque in 3.0. For example the code is like -


X509_STORE_CTX  *ctx;



ctx->current_issuer = NULL;
ctx->current_crl_score = 0;
ctx->current_reasons = 0;




this changed with openssl 1.1.1 already; do
  man X509_STORE_CTX_init

which sets all of the above.

HTH,

JJK

Re: Why can't we get a proper installation method to keep OpenSSL at the latest revision for Linux?

[Jan Just Keijser]

On 30/05/21 14:05, Michael McKenney wrote:


Why can't we get a proper installation method to keep OpenSSL at the 
latest revision for Linux?


My biggest compliant with Linux is it is so difficult to get best 
practice installations for services like OpenSSL. Ubuntu is still on 
1.1.1f.    I have been trying to upgrade to 1.1.1k.   Openssl version 
-a states I am on 1.1.1k.   When programs in Wordpress that use 
OpenSSL show I am using 1.1.1.f.   Spending hours of time on various 
sites like AskUbuntu.com, only to be disappointed.   Microsoft has 
best practices guides for installations.   Why can’t we get them for 
Linux.




this is both very hard and undesirable:
openssl can be regarded as a low-level system library that is used by 
many applications across the entire Linux distribution. You cannot 
simply upgrade this low-level system library without breaking these 
applications. Admittedly, for an upgrade from 1.1.1f -> 1.1.1k the risk 
of introducing an API change is quite low, but for anything else (e.g. 
1.1.0x -> 1.1.1k) you will almost certainly have to rebuild and relink 
all applications that depend on the OpenSSL libraries.
This is not something you can expect from the Linux distro maintainers. 
For them, it is far less risky to backport security fixes to the version 
of OpenSSL that they built their distro on (e.g. Ubuntu 20 > 1.1.1f; 
CentOS 7 -> 1.0.2k (yes!), etc).


Note that most update woes that Windows 10 has had over the past few 
years were related to library updates breaking applications - so even 
microsoft has problems with "best practices".


HTH,

JJK

Re: Why can't we get a proper installation method to keep OpenSSL at the latest revision for Linux?

[Jan Just Keijser]

Hi,

On 31/05/21 13:01, Michael McKenney wrote:


My wordpress servers are under constant attack.  My Fortinet 60E 
firewall logs are filled.  Openssl is constantly reported on The 
Hacker News and other sites.   So I don’t need to worry about 
upgrading OpenSSL in the future to 1.1.1k or above? I can just use 
what the distro has to offer by apt?  Ubuntu 20.04 started with 
1.1.1f.    My Kali server is mainly used for Try Hack Me challenges 
and learn cyber security.




if you use an LTS distro then you can trust the distro makers - if not, 
then there are thousands of servers out there that are vulnerable ;)


I run several public Wordpress sites on CentOS 7 and have locked them 
down quite rigorously - I have not had any breakins for the past 7 years 
or so, whilst relying fully on the RH/CentOS-supplied openssl library.


HTH,

JJK


*From:*Jan Just Keijser 
*Sent:* Monday, May 31, 2021 5:55 AM
*To:* Michael McKenney ; 
openssl-users@openssl.org
*Subject:* Re: Why can't we get a proper installation method to keep 
OpenSSL at the latest revision for Linux?


On 30/05/21 14:05, Michael McKenney wrote:

Why can't we get a proper installation method to keep OpenSSL at
the latest revision for Linux?

My biggest compliant with Linux is it is so difficult to get best
practice installations for services like OpenSSL. Ubuntu is still
on 1.1.1f.    I have been trying to upgrade to 1.1.1k.   Openssl
version -a states I am on 1.1.1k. When programs in Wordpress that
use OpenSSL show I am using 1.1.1.f.   Spending hours of time on
various sites like AskUbuntu.com, only to be disappointed.  
Microsoft has best practices guides for installations.   Why can’t
we get them for Linux.

this is both very hard and undesirable:
openssl can be regarded as a low-level system library that is used by 
many applications across the entire Linux distribution. You cannot 
simply upgrade this low-level system library without breaking these 
applications. Admittedly, for an upgrade from 1.1.1f -> 1.1.1k the 
risk of introducing an API change is quite low, but for anything else 
(e.g. 1.1.0x -> 1.1.1k) you will almost certainly have to rebuild and 
relink all applications that depend on the OpenSSL libraries.
This is not something you can expect from the Linux distro 
maintainers. For them, it is far less risky to backport security fixes 
to the version of OpenSSL that they built their distro on (e.g. Ubuntu 
20 > 1.1.1f; CentOS 7 -> 1.0.2k (yes!), etc).


Note that most update woes that Windows 10 has had over the past few 
years were related to library updates breaking applications - so even 
microsoft has problems with "best practices".


HTH,

JJK

Re: Compile opensslß1.1.1k on CentOS8

[Jan Just Keijser]

Hi,

On 07/06/21 20:26, Lothar Belle wrote:

Hi,
recently I compiled openssl-1.1.1k on CentOS-8
but when I am using libcrypto.so.1.1 I get errors like:

libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b

Obviously RedHat added additional features into there own libraries,
but using the same version/naming.
See https://bugzilla.redhat.com/show_bug.cgi?id=1829790

I tried also to apply the patches, but they don‘t work with the latest
source code

https://git.centos.org/rpms/openssl/blob/c8/f/SOURCES/openssl-1.1.1-evp-kdf.patch

The suggested solution renaming the libraries didn‘t work neither for me.

But we want to use the latest version, including all security fixes,
therefore I can‘t use the build-in version.

Has anybody a solution for this?
Is it planned to implement such features in official OpenSSL in the near future?

CentOS 8(.3) uses openssl 1.1.1g *with security backports*  . The whole 
idea of an enterprise OS like RHEL 8 is that you fix packages at certain 
version (e.g. kernel 4.18.0, gcc 8.3.1, openssl 1.1.1g) and that those 
versions will remain (mostly) constant throughout the life cycle of the OS.
Redhat backports security fixes from newer releases into this 1.1.1g 
release, thus one can claim that "rhel8 openssl 1.1.1g" is as safe (or 
unsafe) as the stock version of openssl 1.1.1k.


If you don't like this, then switch to a distro that does not use this 
"version pinning" - the downside of that will that you will be doing 
upgrades very frequently.


As you found out, it is nearly impossible to swap out the existing 
openssl 1.1.1g with a "stock" openssl version, as RedHat/CentOS have 
applied patches to it. My advice would be: don't even try. If you *have 
to* use openssl 1.1.1k, then switch to Fedora or to Ubuntu (not the LTS 
releases). But keep in mind:

- debian 10 uses openssl 1.1.1d
- ubuntu seems to be at openssl 1.1.1j
etc.

HTH,

JJK

Re: openssl verify question

[Jan Just Keijser]

Hi,

On 12/06/21 22:20, Gaardiolor wrote:

Hello,

My openssl-1.0.2k-21.0.1.el7_9.x86_64 verify fails with HSM-signed 
certificates. The HSM is causing other issues and is likely 
misbehaving, I think this is a HSM bug. I'm sure I'm using the correct 
server.crt and rootca.crt.


$ openssl verify -CAfile rootca.crt server.crt
server.crt: C 
error 7 at 0 depth lookup:certificate signature failure
139734096439184:error:0D0680A8:asn1 encoding 
routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1239:
139734096439184:error:0D07803A:asn1 encoding 
routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:405:Type=X509_SIG
139734096439184:error:0D0C5006:asn1 encoding 
routines:ASN1_item_verify:EVP lib:a_verify.c:249:


just wondering: why and how are you using an HSM to verify a certificate 
(without including a private key) ?  is the certificate stored only on 
the HSM?  is it possible to get it off the HSM?


Also, how are you connecting the HSM to OpenSSL? via opensc-pkcs11 ?  
you should have an openssl.cnf file somewhere for this.


HTH,

JJK




I tried doing the verification manually like so:

Extracting the 'to be signed' part of the server.crt:
openssl asn1parse -in server.crt -strparse 4 -out server.tbs

sha256 that:
cat server.tbs | openssl sha256 -binary > server.tbs.sha256

Extracting the signature from the server.crt:
openssl asn1parse -in server.crt -strparse 569 -out server.sig

Extracting the public key from rootca.crt:
openssl x509 -in rootca.crt -noout -pubkey > rootca.pub

Decrypting the signature:
openssl rsautl -inkey rootca.pub -pubin -in server.sig -out 
server.sig.decrypted


Comparing server.tbs.sha256 and server.sig.decrypted .

When I compare those, they are exactly the same. But that's the thing, 
I think server.sig.decrypted should be prepended with a sha256 
designator 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20, 
which is missing. I do see this designator with working certificates. 
I suspect this is the problem.


Is that designator mandatory and likely the cause of my issue ? 
https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.1.2 suggests 
it's mandatory.. but I'm not sure if I'm looking at the right section.


Thanks.

Re: OpenSSL version 3.0.0-beta1 published

[Jan Just Keijser]

Hi,

On 17/06/21 15:36, Matt Caswell wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


OpenSSL version 3.0 beta 1 released
===

OpenSSL - The Open Source toolkit for SSL/TLS
https://www.openssl.org/

OpenSSL 3.0 is currently in beta.

OpenSSL 3.0 beta 1 has now been made available.

Note: This OpenSSL pre-release has been provided for testing ONLY.
It should NOT be used for security critical purposes.

Specific notes on upgrading to OpenSSL 3.0 from previous versions are
available in the OpenSSL Migration Guide, here:

 https://www.openssl.org/docs/manmaster/man7/migration_guide.html

The beta release is available for download via HTTPS and FTP from the
following master locations (you can find the various FTP mirrors under
https://www.openssl.org/source/mirror.html):

  * https://www.openssl.org/source/
  * ftp://ftp.openssl.org/source/

The distribution file name is:

 o openssl-3.0.0-beta1.tar.gz
   Size: 14878832
   SHA1 checksum:  4b48947969bb3c989ba95ac4bdc4a78e70212d2b
   SHA256 checksum:  
7bfedc9a1062cbd2aabc294acc93cbd5259e6e7bd5bbe38e454cc6a32564029f

The checksums were calculated using the following commands:

 openssl sha1 openssl-3.0.0-beta1.tar.gz
 openssl sha256 openssl-3.0.0-beta1.tar.gz

Please download and check this beta release as soon as possible.
To report a bug, open an issue on GitHub:

 https://github.com/openssl/openssl/issues

Please check the release notes and mailing lists to avoid duplicate
reports of known issues. (Of course, the source is also available
on GitHub.)

   
excellent news - I've downloaded it and played with it a bit; it 
compiles fine and all tests pass on CentOS 7 and Fedora 32+33 .
I've managed to compile ppp-2.4.9 with it and apart from the deprecated 
ENGINE functions it builds OK (with a minor patch to ppp itself which I 
will upload shortly).


However, I was wondering if anyone has ported/refactored the pkcs11 
engine stuff for OpenSSL 3.0 already?  is this on the TODO list for the 
OpenSC/pkcs11 team?  If I wanted to try to refactor the opensc-pkcs11 
module, how would I start?


thanks for all your hard work,

JJK / Jan Just Keijser

Re: Compilation issues

[Jan Just Keijser]

On 29/06/21 11:58, david raingeard wrote:

Hello,

Technically, why prevents openssl 1.1.1g from compiling correctly on some
operating systems like Solaris 2.6, CentOS 7.8,... ?


you will have to provide more details - openssl 1.1.1g compiles just 
fine on CentOS 7 (7.9 in my case).


Can't talk about Solaris 2.6 , other than that it has been out of 
support since July 2006.


HTH,

JJK

Re: client certificate error

[Jan Just Keijser]

Hi,

On 30/06/21 00:23, Paulo Wollny wrote:

Dear @ll

My environment:

OpenSSL 1.1.1f  31 Mar 2020

Ubuntu 20.04

Server version: Apache/2.4.41 (Ubuntu)
Server built:   2021-06-17T18:27:53

My problem:

connecting to a secure server requiring client certificate, i get the 
following error when presenting my certificate:


ERR_BAD_SSL_CLIENT_AUTH_CERT

It started to fail after the previous one voided and i issued a new one.

CA, the same, server cert, renewed after previous voided.



this is an apache/mod_ssl issue and has little to do with openssl; from 
reading the logs the lines


[Tue Jun 29 19:15:45.592363 2021] [ssl:error] [pid 241357] [client 
127.0.0.1:57026] AH02261: Re-negotiation handshake failed


look suspicious - it means your client is connecting from 127.0.0.1 and 
your server is also listening on 127.0.0.1 ; is this really what you 
have in mind?


But again, this is an apache httpd/mod_sssl issue and does not belong on 
this list.


JJK


My server conf:


    ServerAdmin webmaster@localhost

    DocumentRoot /home/www/

    # Available loglevels: trace8, ..., trace1, debug, 
info, notice, warn,

    # error, crit, alert, emerg.
    # It is also possible to configure the loglevel for 
particular

    # modules, e.g.
    #LogLevel info ssl:warn

    ErrorLog /var/log/apache2/ssl_engine.log
    LogLevel debug

    #ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    # For most configuration files from conf-available/, 
which are
    # enabled or disabled at a global level, it is 
possible to
    # include a line for only one particular virtual host. 
For example the
    # following line enables the CGI configuration for 
this host only

    # after it has been globally disabled with "a2disconf".
    #Include conf-available/serve-cgi-bin.conf

    #   SSL Engine Switch:
    #   Enable/Disable SSL for this virtual host.
    SSLEngine on

    SSLProtocol all -SSLv3 -TLSv1.3
    #SSLProtocol all
    #SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.3
    SSLHonorCipherOrder on
    SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM 
EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 
EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW 
!3DES !MD5 !EXP !PSK !SRP !DSS"


    #   A self-signed (snakeoil) certificate can be 
created by installing

    #   the ssl-cert package. See
    #   /usr/share/doc/apache2/README.Debian.gz for more 
info.
    #   If both key and certificate are stored in the same 
file, only the

    #   SSLCertificateFile directive is needed.
    SSLCertificateFile /etc/ssl/private/server.crt
    SSLCertificateKeyFile /etc/ssl/private/server.key
    SSLCACertificatePath /etc/ssl/certs/
    #SSLCACertificateFile 
/etc/ssl/certs/PSign_TrustCenter_Root_CA-I.pem

    SSLCACertificateFile /etc/ssl/private/fullchain.crt


    #   Server Certificate Chain:
    #   Point SSLCertificateChainFile at a file containing 
the
    #   concatenation of PEM encoded CA certificates which 
form the
    #   certificate chain for the server certificate. 
Alternatively
    #   the referenced file can be the same as 
SSLCertificateFile
    #   when the CA certificates are directly appended to 
the server

    #   certificate for convinience.
    #SSLCertificateChainFile 
/etc/apache2/ssl.crt/server-ca.crt


    #   Certificate Authority (CA):
    #   Set the CA certificate verification path where to 
find CA
    #   certificates for client authentication or 
alternatively one
    #   huge file containing all of them (file must be PEM 
encoded)
    #   Note: Inside SSLCACertificatePath you need hash 
symlinks
    #    to point to the certificate files. 
Use the provided
    #    Makefile to update the hash symlinks 
after changes.

    #SSLCACertificatePath /etc/ssl/certs/
    #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt

    #   Certificate Revocation Lists (CRL):
    #   Set the CA revocation path where to find CA CRLs 
for client
    #   authentication or alternatively one huge file 
containing all

    #   of them (file must be PEM encoded)
    #   Note: Inside SSLCARevocationPath you need hash 
symlinks
    #    to point to the certificate files. 
Use the provided
    #

Re: Compilation issues

[Jan Just Keijser]

Hi,

On 29/06/21 18:31, david raingeard wrote:
Ok, here it is. It compiled mostly ok (some fixes for solaris 2.6, 
like inttypes.h instead of stdint).

The test suite fails (dubious error).

*Tls 1.2 works* just fine (*openssl s_client -connect google.com:443 
 -tls1_2 -trace*)


but *Tls 1.3 fails* starting when the *ApplicationData *record is 
received.


I'd say this is a local build issue; I just unpacked 1.1.1g on my CentOS 
7.9 box, did a

  ./config no-shared
  make
  make test
then
  ./apps/openssl s_client -CAfile /etc/pki/tls/cert.pem -connect 
google.com:443


and got this:

./apps/openssl s_client -CAfile /etc/pki/tls/cert.pem -connect 
google.com:443

CONNECTED(0003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
verify return:1
depth=0 CN = *.google.com
verify return:1
---
Certificate chain
 0 s:CN = *.google.com
   i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
 1 s:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
---
Server certificate
-BEGIN CERTIFICATE-
[...]
-END CERTIFICATE-
subject=CN = *.google.com

issuer=C = US, O = Google Trust Services LLC, CN = GTS CA 1C3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 6449 bytes and written 392 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---


So no errors, no warnings and it is using TLS 1.3 to connect.
Check your local environment and especially check that
  make test
does not give any errors.

HTH,

JJK

Re: client certificate error

[Jan Just Keijser]

Hi,

On 30/06/21 15:22, Paulo Wollny wrote:

Hi,

thank you for the answer.

can you please point the right direction for solution, please?


try
 http://httpd.apache.org/userslist.html


Regarding the "look suspicious - it means your client is connecting 
from 127.0.0.1 and your server is also listening on 127.0.0.1 ; is 
this really what you have in mind? "  i'm testin on my local system, 
having apache server and browser (chrome) on the same system.


And yes, the server cetificate have localhost as DNS alias.


The apache mailing list is a better place to ask ; as for using a 
certificate with localhost alias - I would not recommend doing that. It 
is better to use a FDQN and then add that FQDN to the /etc/hosts file using

  127.0.0.1    


HTH,

JJK

Re: installing OpenSSL 1.1.1 on RedHat 6.x

[Jan Just Keijser]

On 08/07/21 18:55, Tim Culhane wrote:

Hi,

We have a customer who is running our product on a RedHat 6.x server.
Our product uses OpenSSL 1.1.1 to handle secure connections.

Initial testing by the customer is showing segmentation faults in OpenSSL
during the handshake process.

We have successfully tested our product on CentOS 7.x servers.

I know that RedHat certainly doesn't ship recent versions of OpenSSL  for
RedHat 6.x.  However it is still possible to install later OpenSSL versions
to run side-by-side the system installation.

What I'm wondering is, would there be a  technical reason why OpenSSL 1.1.1
would not work correctly on a RedHat 6.x system?

For the record the customer has tried with OpenSSL 1.1.1g and 1.1.1k with
similar results.


Note that RH 6 is out of support and it will be hard to find support for 
it anywhere. It uses openssl 1.0.1e by default which is *not* API 
compatible with 1.1.1k; please ensure that the RH openssl header files 
and development libraries are NOT installed when compiling your 
application against 1.1.1k (try removing the RPM openssl-devel).


I compiled and used OpenSSL up to version 1.1.1d on RH 6 without any 
issues; I just revived an old VM and built openssl 1.1.1k on it without 
problems. However, the command

  make test
failed as I am missing certain dependencies.

Without knowing how you build your appilcation it is impossible to tell 
where and how it is failing.


A long shot, but one thing to try is to install a newer gcc compiler; 
you can find one in the "sclo" repositories, e.g

  https://vault.centos.org/6.10/sclo/x86_64/rh/Packages/d/

and install 'devtoolset-9' to get gcc 9 on RH 6. Perhaps a rebuild using 
a new compiler fixes the segfaults you are seeing.  Most likely, 
however, you are mixing headers files from different versions of OpenSSL.


HTH,

JJK

Re: Query reg. using certificates bigger than 4k for EAP-TLS

[Jan Just Keijser]

Hi Vishal,

On 20/10/21 13:34, Vishal Sinha wrote:

Hi Matt

The certificate is not large as such. But since it's a chain, the 
overall size crosses 4k. We used BIO_set_write_buffer_size() API to 
increase the size from 4k to 8k of the BIO buffer in SSL context.





just out of curiosity: does this issue occur with pppd with EAP-TLS 
support (which I originally added) ? if so, which version of the pppd 
code are you using or which version of the ppp-eap-tls patch?


If you *are* using pppd to do the EAP-TLS handshake then let me try to 
replicate your particular issue.


HTH,

JJK



On Wed, Oct 20, 2021 at 3:26 PM Vishal Sinha > wrote:


Hi

We are using openssl 1.1.1c version on our client and server.
Client and Server are doing EAP-TLS authentication using
certificates which are more than 4k in size (using 1 root CA and 2
intermediate CAs). We noticed that the server is not able to
handle it gracefully due to insufficient buffer size during SSL
handshake and hence authentication fails. To solve this issue, we
increased the buffer size to 8k programmatically and
authentication passed. Is there any other way to solve this problem?

Regards
Vishal

Re: client/server communication with OpenSSL && with passwords or passphrase

[Jan Just Keijser]

Hi,

On 21/01/22 11:29, Matthias Apitz wrote:

Hello,

we develop a business application as client/server with TCP/IP
communication and a human readable protocol, which is encrypted by
OpenSSL. The servers are C-written on top of PostgreSQL on Linux, while
the clients are mostly Java-written and running on Win10 PCs of the
staff, talking over the network to the servers. This runs well for many
years already. The clients have no key material and "trust" the server
servers. How the keys are made is explained below in some older post
from me. The connection establishment is from the client to the server.

This only as background for the actual situation.

What we now want to have is strengthen the communication in some
directions:

1) Each client should have its own key for the OpenSSL. They must be
built central, copied to the Win PC and installed there.

2) The usage of the key and OpenSSL communication should be protected by some
passphrase (like for a SSH connection the usage of the private RSA
key).

Is there some usecase example or some tutorial for this, or any other
hints?


yes, there is plenty of information on this out there, but the tricky 
part is the fact that you are using Java on the client side. Doing 
client authentication with Java requires knowledge of how Java uses its 
local keystores. Example code can be found here:

https://docs.oracle.com/javase/10/security/sample-code-illustrating-secure-socket-connection-client-and-server.htm

You would set up a central PKI  and issue passphrase protected keys 
using it; the "openssl CA" commands are a good starting point for this, 
otherwise I'd recommend looking into tools like "easy-rsa" , which are 
essentially wrappers around the "openssl CA" commands.


On the server side you need to ensure that it will accept connections 
only coming from clients that supply a certificate signed by the CA you 
have built for this purpose.  The OpenSSL sources provide plenty of 
examples on how to do this.


You'd then copy over the resulting client-side keys+certificates to the 
Java-based client and import it into the Java keystore. That can be done 
using the PKCS12 format, as I believe you can load a Java keystore in 
that format, e.g.


|KeyStore ks = KeyStore.getInstance("pcks12");|


see https://www.baeldung.com/java-keystore for an example.

HTH,

JJK / Jan Just Keijser




- Forwarded message from Matthias Apitz  -

Date: Tue, 19 Feb 2019 09:57:11 +0100
From: Matthias Apitz 
To: openssl-users@openssl.org
Subject: understand 'openssl dhparms '


Hello,

Some years ago (in 2012) I wrote an OpenSSL server, loosely based on the example
sources 'openssl-examples-20020110' which nowadays still exist in
https://github.com/smbutton/DataCommProject/tree/master/openssl-examples-20020110/openssl-examples-20020110

There was also some guiding available about how to create the necessary
key material, which goes more or less like this:



   $ mkdir newca
   $ cd newca
   $ cp /usr/local/openssl/misc/CA.sh .
   $ ./CA.sh -newca

   will create a new CA. Remember the passphrase as you will need
   it to sign certificates.

   $ cp demoCA/cacert.pem ../root.pem

   Second step

   $ ./CA.sh -newreq

   will create a certificate and a certification request.
   Set the passphrase to 'password' as this is hard-coded in
   the examples' source code. It is important to set the
   [Common Name] to 'localhost'.


   Third step

   $ ./CA.sh -sign

   will sign your newly created certificate. Enter the password for
   your CA which you have defined in step 1.


   Fourth step

   $ cat newreq.pem newkey.pem newcert.pem > ../localhost.pem
   $ cd ..
   $ ln -s localhost.pem server.pem
   $ ln -s localhost.pem client.pem

   Maybe you also want to issue

   $ openssl dhparam 1024 -2 -out dh1024.pem -outform PEM

   in order to update the DH parameters.


...





- End forwarded message -

Re: Doubt regarding ssl options

[Jan Just Keijser]

Hi,

On 31/01/22 10:27, Srinivas, Saketh (c) wrote:

Hi,

what is the difference between  SSL_CTX_set_min_proto_version 
and SSL_set_min_proto_version.

How will they effect the SSL handsahke.

I can see two versions numbers in the PCAP files,

 1. content type is handshake , version v1.0
 2. handshake type client hello, version v1.2

what is the difference and how to modify them.




The effect of SSL_CTX_set_min_proto_version and 
SSL_set_min_proto_version is exactly the same - it sets the minimum 
TLS/SSL proto version to be used during the client/server handshake 
(exchange of "hello" messages).


The TLS/SSL version mentioned during "content type = handshake" is known 
as the record layer version number. If you read the TLS 1.2 spec 
(https://datatracker.ietf.org/doc/html/rfc5246) you will find

" Earlier versions of the TLS specification were not fully clear on
   what the record layer version number (TLSPlaintext.version) should
   contain when sending ClientHello (i.e., before it is known which
   version of the protocol will be employed).  Thus, TLS servers
   compliant with this specification MUST accept any value {03,XX} as
   the record layer version number for ClientHello.
"

Check out this snippet of code (line numbers are from openssl 1.1.1k, 
file "ssl/record/rec_layer_s3.c"):


 849 /*
 850  * Some servers hang if initial client hello is larger 
than 256 bytes

 851  * and record version number > TLS 1.0
 852  */
 853 if (SSL_get_state(s) == TLS_ST_CW_CLNT_HELLO
 854 && !s->renegotiate
 855 && TLS1_get_version(s) > TLS1_VERSION
 856 && s->hello_retry_request == SSL_HRR_NONE)
 857 version = TLS1_VERSION;
 858 SSL3_RECORD_set_rec_version(thiswr, version);

which shows that OpenSSL explicitly sets the *record* version number to 
TLS 1.0 ; one could argue whether such buggy servers still exist and 
whether there should be an option to overrule the above behaviour.


Thus, this is not affected by any calls to SSL_CTX_set_min_proto_version 
or SSL_set_min_proto_version.
However, the above is safe in terms of "it works with buggy servers" as 
well as safe in terms of "the connection *will* use tls 1.2+ if I call 
SSL_{ctx_}set_min_proto_version" so why change?


Hope this clarifies things,

JJK / Jan Just Keijser

Re: [openssl-users] Jks converted to Pem error in veirfying

[Jan Just Keijser]

Hi,

On 10/01/16 05:15, Anil Mathew wrote:

I am a novice in terms of ssl and hence have limited knowledge in this.
Please help

I have been a given a jks file that has server certificate, client
certificate and a key for the client certificate.  I need to convert it to
pem to use it in my application.

I have converted a jks file to p12 and then to pem.
However when i try to verify i get the following error.

echo |openssl verify -verbose -purpose sslclient -issuer_checks -CApath
C:\Data\Openssl\demoCA\certs -CAfile client.pem client.pem
client.pem: /CN=cn/O=o/L=L/ST=il/C= c
error 29 at 0 depth lookup:subject issuer mismatch
/CN=cn/O=o/L=L/ST=il/C= c
error 29 at 0 depth lookup:subject issuer mismatch
/CN=cn/O=o/L=L/ST=il/C= c
error 29 at 0 depth lookup:subject issuer mismatch
/CN=cn/O=o/L=L/ST=il/C= c
error 29 at 0 depth lookup:subject issuer mismatch
/CN=cn/O=o/L=L/ST=il/C= c
error 20 at 0 depth lookup:unable to get local issuer certificate


this could be a PRINTABLE_STRING  / UTF8_STRING mismatch - can you send 
me the certificates (not the key!) via private email and I will have a 
look. There are some funky options you can add to openssl to see how the 
certificate is composed.


Also, it would help to list the exact version of openssl that you are 
using (run 'openssl version').


HTH,

JJK

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

Re: [openssl-users] Certificate verification failure

[Jan Just Keijser]

Yan, Bob wrote:


Dear Sir/Madam,

I have an application which acting as SSL server. When the application 
loads the root and intermediate CA files from a CA path, the handshake 
between my application and openssl client was failed at the point when 
my application was authenticating the client’s certificate. But when I 
bound the root CA and intermediate CA into a single pem file and 
reload it from my application, the handshake is successful. Could 
anybody help me resolve this issue? Below is the sample of my 
application code for loading the CA certificates:


if (SSL_CTX_load_verify_locations(ctx, caFile, caPath) != 1) {

exit;

}

if (SSL_CTX_set_default_verify_paths(ctx) != 1) {

exit;

}

if (SSL_CTX_use_certificate_chain_file(ctx, certFile) != 1) {

exit;

}

if (SSL_CTX_use_PrivateKey_file(ctx, keyFile, SSL_FILETYPE_PEM) != 1) {

exit;

}

SSL_CTX_set_verify_depth(ctx, chainDepths);

SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | 
SSL_VERIFY_FAIL_IF_NO_PEER_CERT, callback);


SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2);



when you're using CA path , what are the contents of this CA path 
directory? In it you should have placed the root and intermediate CA 
files using special names. Instead of using "ca.pem" you need to have a 
file ".0" , where  is the output of "openssl x509 -hash 
-noout -in ca.pem" (and similarly for the intermediate CA file).


JJK

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

Re: [openssl-users] Certificate verification failure

[Jan Just Keijser]

Yan, Bob wrote:

Thanks Jan,

When I am using the CApath, I do have the symbolic hash link (with ".0" at the end hash) linked to my ca-root.pem certificate file and ca-intermediate.pem certificate. Any other issues which could cause this issue? 
  

what happens if you run
 openssl verify -CApathclient.crt

? is that certificate correctly verified?

HTH,

JJK


-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Jan 
Just Keijser
Sent: Monday, February 01, 2016 1:04 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Certificate verification failure

Yan, Bob wrote:
  

Dear Sir/Madam,

I have an application which acting as SSL server. When the application 
loads the root and intermediate CA files from a CA path, the handshake 
between my application and openssl client was failed at the point when 
my application was authenticating the client's certificate. But when I 
bound the root CA and intermediate CA into a single pem file and 
reload it from my application, the handshake is successful. Could 
anybody help me resolve this issue? Below is the sample of my 
application code for loading the CA certificates:


if (SSL_CTX_load_verify_locations(ctx, caFile, caPath) != 1) {

exit;

}

if (SSL_CTX_set_default_verify_paths(ctx) != 1) {

exit;

}

if (SSL_CTX_use_certificate_chain_file(ctx, certFile) != 1) {

exit;

}

if (SSL_CTX_use_PrivateKey_file(ctx, keyFile, SSL_FILETYPE_PEM) != 1) 
{


exit;

}

SSL_CTX_set_verify_depth(ctx, chainDepths);

SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | 
SSL_VERIFY_FAIL_IF_NO_PEER_CERT, callback);


SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2);




when you're using CA path , what are the contents of this CA path directory? In it you should have placed the root and 
intermediate CA files using special names. Instead of using "ca.pem" you need to have a file 
".0" , where  is the output of "openssl x509 -hash -noout -in ca.pem" (and 
similarly for the intermediate CA file).

JJK

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

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


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

[openssl-users] pkcs12 oddity

[Jan Just Keijser]

hi list,

we just ran into an "openssl pkcs12" oddity with various versions of 
openssl (e.g. 1.0.1e from Fedora):


$ cat usercert.pem userkey.pem | openssl pkcs12 -export -out blah.p12
Enter pass phrase:
unable to load certificates

i.e. fails, but this works:

$ cat  userkey.pem usercert.pem | openssl pkcs12 -export -out blah.p12
Enter pass phrase:
Enter Export Password:
Verifying - Enter Export Password:

this works: it seems the private key must always be listed first!
However, the man page for pkcs12 states:

   -in filename
   The filename to read certificates and private keys from, standard 
input by default.  They must all be in
   PEM format. The order doesn't matter but one private key and its 
corresponding certificate should be
   present. If additional certificates are present they will also be 
included in the PKCS#12 file.


so, what am I doing wrong here? (the command listed above is not the 
actual command we want to use, but it does bring out the problem very 
nicely)


thanks for any help and pointers,

JJK / Jan Just Keijser

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

Re: [openssl-users] How to retrieve the revoked certificate list when X509_LOOKUP_hash_dir() method used

[Jan Just Keijser]

Hi Bob,

Yan, Bob wrote:

H All,

I used the following methods to load CRL hashed-directory into a SSL_CTX object to verify the client certificate against the CRL. The code works fine and it's able to verify the client certificate against the loaded CRLs.  


   X509_STORE *x509Store = SSL_CTX_get_cert_store(sslCtx);
   X509_LOOKUP *lookup = X509_STORE_add_lookup(x509Store, 
X509_LOOKUP_hash_dir());
   X509_LOOKUP_add_dir(lookup, crlDirectory, X509_FILETYPE_PEM);

My question is that, is there any method to retrieve the CRL list or print all revoked certificate list?
  


did you try the X509_CRL_print function?

(this is what "openssl crl -text" uses)

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

Re: [openssl-users] [openssl-dev] Are you using "TLS proxy certificates"?

[Jan Just Keijser]

Hi Rich,

On 27/04/16 18:45, Salz, Rich wrote:


If so, please let us know.  Replies to me will be summarized for the 
lists.



what exactly do you mean by 'TLS proxy certificates' ?  if you mean 
RFC3820 (5280) proxy certificates, then yes, we use them extensively 
within grid computing.


regards,

JJK / Jan Just Keijser
Nikhef
Amsterdam


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

[openssl-users] s_client/s_server trouble

[Jan Just Keijser]

hi all,

I've just run into something weird with openssl 1.0.1 and s_client+s_server:

- I've downloaded and compiled a static version of openssl 1.0.1t on Linux
- I've set up a PKI with a ca.crt file and a server.crt/server.key keypair
- next , I run

  ~/src/openssl-1.0.1t/apps/openssl s_server -CAfile ca.crt -cert 
server.crt -key server.key  -dhparam dh2048.pem


- then, with s_client

  ~/src/openssl-1.0.1t/apps/openssl s_client -CAfile ca.crt -connect 
127.0.0.1:4433


and I always end up with

  Verify return code: 21 (unable to verify the first certificate)

If I either change s_server *or* s_client to use openssl 0.9.8 then the 
above commands work!


What am I missing here?


TIA,

JJK / Jan Just Keijser

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

Re: [openssl-users] s_client/s_server trouble

[Jan Just Keijser]

Hi all,

no one has seen this as well? I've seen other mails fly by on 
openssl-users after I posted this, yet no response to my query, nor to a 
previous mail I sent (about pkcs7). Should I file bug reports instead?


thx,

JJK / Jan Just Keijser

Jan Just Keijser wrote:

hi all,

I've just run into something weird with openssl 1.0.1 and 
s_client+s_server:


- I've downloaded and compiled a static version of openssl 1.0.1t on 
Linux
- I've set up a PKI with a ca.crt file and a server.crt/server.key 
keypair

- next , I run

  ~/src/openssl-1.0.1t/apps/openssl s_server -CAfile ca.crt -cert 
server.crt -key server.key  -dhparam dh2048.pem


- then, with s_client

  ~/src/openssl-1.0.1t/apps/openssl s_client -CAfile ca.crt -connect 
127.0.0.1:4433


and I always end up with

  Verify return code: 21 (unable to verify the first certificate)

If I either change s_server *or* s_client to use openssl 0.9.8 then 
the above commands work!


What am I missing here?


TIA,

JJK / Jan Just Keijser



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

Re: [openssl-users] s_client/s_server trouble

[Jan Just Keijser]

Hi all,

thanks for all the pointers - it was indeed a problem with the certificates.

cheers,

JJK / Jan Just Keijser

On 19/05/16 18:19, Viktor Dukhovni wrote:

On Thu, May 19, 2016 at 05:58:11PM +0200, Jakob Bohm wrote:


What kind (and size) of keys are in your certificates?

That sounds like the most likely issue.

Perhaps that dhparam2049.pem does not actually contain a 2048-bit
prime.  I don't recall a floor on RSA key sizes in 1.0.1.

The CHANGES file lists for 1.0.1q:

   *) Reject DH handshakes with parameters shorter than 1024 bits.
  [Kurt Roeckx]

Otherwise, I don't see any enforcement of key size floors in 1.0.1.


- I've set up a PKI with a ca.crt file and a server.crt/server.key
  keypair

Not posting the certs makes it rather difficult to offer any help.


- next , I run

  ~/src/openssl-1.0.1t/apps/openssl s_server -CAfile ca.crt -cert
server.crt -key server.key  -dhparam dh2048.pem

I don't see a "-accept 4433" in that command.


- then, with s_client

  ~/src/openssl-1.0.1t/apps/openssl s_client -CAfile ca.crt -connect
127.0.0.1:4433

What's listening on "4433"?


and I always end up with

  Verify return code: 21 (unable to verify the first certificate)

If I either change s_server *or* s_client to use openssl 0.9.8 then the
above commands work!

With 0.9.8 s_client or s_server will be able to use the default
CApath that is probably hashed with the 0.9.8-compatible hash
algorithm, allowing either or both to construct a more complete
chain,

Likely the "ca.crt" you're using is not the (immediate?) issuer
of the server certificate.



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

Re: [openssl-users] Checking for AES-NI accelration

[Jan Just Keijser]

Hi,

On 10/08/16 14:25, Nagesh shamnur wrote:


Hi Group,

I am running an application which transfers huge chunks of data every 
second (850Mbps) and the same is secured using openssl. However the 
CPU usage on windows is very high ( ~ 100%). So as a part of the 
analysis, I stumbled upon the information that, when using AES 
encryption, if the underlying hardware is Intel CPU, it can support 
AES-NI instruction set and hence make the crypto processing faster. 
So, I wanted to confirm if the same is enabled in my hardware.


So, I wanted to know how to verify if the run is able to use the 
AES-NI instruction set available in the hardware.


I have built openssl and have ensured enabling the asm in both linux 
and windows build.


For windows, to confirm if AES-NI is enabled, support of tools 
available like truecrypt, CPU-Z and blackbox were used if the same was 
enabled in OS usage. And I found that the same is disabled. Also I 
found in some blogs that the same needs to be enabled in BIOS. When 
checked the BIOS settings, the option was not be found and a BIOS 
update is required to enable the same.


However in linux I was unable to conclude if AES-NI is disabled since 
I didn’t had access to any such tools on linux. I checked "#cpuinfo | 
grep aes" and i was unable to find any line regarding AES-NI. However 
when i run the ./openssl speed -evp aes-128-gcm and 
OPENSSL_ia32cap="~0x202" ./openssl speed -elapsed -evp 
aes-128-gcm i am able to find the difference in speed. So i wanted to 
check how to confirm if my linux build has AES-NI enabled or not?


Environment Information:

CPU: E5-2620 0 @2.0GHz

OS: Windows Server 2008

Linux: Ubuntu 3.11.0-15-generic

Openssl versoin: 1.0.2h


I've got a server with that exact same CPU over here; with openssl 
1.0.2d I see the following results:


$ ./openssl  speed -evp aes-128-gcm
[...]
type 16 bytes 64 bytes256 bytes   1024 bytes 8192 bytes
aes-128-gcm 184391.41k   465791.06k   689190.61k   .65k 781295.62k

$ OPENSSL_ia32cap=0 ./openssl  speed -evp aes-128-gcm
[...]
type 16 bytes 64 bytes256 bytes   1024 bytes 8192 bytes
aes-128-gcm  43906.03k49490.24k51037.70k51554.65k 51699.71k

i.e. with AES-NI disabled performance is about ~15 times less. On this 
CPU turboboost is not working so your numbers maybe slightly different.
Another good way to test whether AES-NI is working is by comparing 
BF-CBC to AES-256-CBC: without AES-NI, BF will be faster. with AES-NI, 
AES will be faster.


HTH,

JJK

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

Re: [openssl-users] Access Mozilla NSS (shared) Database / PKCS#11 Modules via OpenSSL?

[Jan Just Keijser]

Hi,

On 08/11/16 17:33, Matthias Ballreich wrote:


Hi there,

how can i access the Mozilla NSS (shared) Database (cert8 or 
cert9d.db) / PKCS#11-Modules via OpenSSL?


I need read & write access to the NSS User Cert Database (softokn3) 
and to the Built-In Cert Database (nssckbi) under Windows.


I tried it with Libp11 this way:

int rc = 0;
PKCS11_CTX *pkcs11_ctx;
pkcs11_ctx = PKCS11_CTX_new();
PKCS11_CTX_init_args(pkcs11_ctx,
 "configdir=''C:/Users/Username/AppData/Roaming/Mozilla/Firefox/Profiles/5wzkdcjx.default' 
certPrefix='' keyPrefix='' secmod='secmod.db'");
rc = PKCS11_CTX_load(pkcs11_ctx, " C:/Program Files 
(x86)/Mozilla/Firefox/softokn3.dll ");

printf("Desc: %s\n", pkcs11_ctx->description);
if (rc)
printf("Error loading Module");

But it return every time “-1” which tells me that the loading fails. 
So is this the right way? Or should I use another library? Or is my 
code not right?


And can I edit the Trust Settings with that or another library like 
with NSS directly? Because I can’t delete the built-in certs of 
nssckbi because this is read-only I can edit the Trust-Settings for 
that certificate. Can I do that with OpenSSL in combination with a 
library, too? Or should I better use NSS instead of OpenSSL?



this is slightly off-topic for this mailinglist, but I'd try using 
p11-kit to access the NSS device; the problem with the softokn3 
pseudo-pkcs11 device is/was that it did not follow the PKCS11 standard 
completely - this made the softokn3 device unusable for tools like 
libp11 and opensc ; however, there are links on the web stating that 
p11-kit does not how to read a nssdb file, e.g.

https://wiki.gnome.org/Projects/CryptoGlue/Integration#NSS_libsoftokn3

and p11-kit has been ported to both mingw and cygwin.

HTH,

JJK

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

Re: [openssl-users] smartcard/ pkcs11 - 'bad decrypt' error after upgrade from 0.9.8 to 1.0.1

[Jan Just Keijser]

Hi,

On 10/11/16 10:49, Pawel Suwinski wrote:

Hello


After  openssl upgrade  (new  OS  version, new  machine)  I get  error
decrypting  SMIME  messages  using Alladin  eToken  SmardCard  (pkcs11
engine).

On old system (Debian 6.0 Squeeze-LTS)/ machine:
#v+
[old]$ openssl version
OpenSSL 0.9.8g 19 Oct 2007 (Library: OpenSSL 0.9.8o 01 Jun 2010)

[old]$ openssl smime -decrypt -passin pass: -inform DER -in smime.p7m -engine 
pkcs11 -inkey id_e3c5 -keyform engine > /dev/null ; echo $?
engine "pkcs11" set.
0
#v-

Now on the new system (Debian 8.6 Jessie)/ machine I get:
#v+
[new]$ openssl version
OpenSSL 1.0.1t  3 May 2016
[new]$ openssl smime -decrypt -passin pass: -inform DER -in smime.p7m -engine 
pkcs11 -inkey id_e3c5 -keyform engine > /dev/null ; echo $?
engine "pkcs11" set.
Error decrypting PKCS#7 structure
3073701564:error:06065064:digital envelope
routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:516:
4
#v-

Of course smime.p7m file and  smartcard are the same. Machines differs
but  smartcard reader  on  the new  machine seams  to  work fine,  for
example I can access smartcard data:

#v+
[new]$ pkcs11-dump dump /usr/lib/libeTPkcs11.so 0  | grep -1

 CKA_ID:
e3 c5
(...)
#v-


Config files are the same with additional pkcs11 engine section
described in libengine-pkcs11-openssl package docs:

#v+
# /etc/ssl/openssl.cnf
(...)
openssl_conf= openssl_def

[openssl_def]
engines = engine_section

[engine_section]
pkcs11 = pkcs11_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/engines/engine_pkcs11.so
MODULE_PATH = /usr/lib/libeTPkcs11.so
init = 0
(...)
#v-


I will be grateful for any hints why it does not work? Maybe I missed
something in config file?



This has little to do with openssl itself, but I am familiar with such 
issues.
I'm using the same token with the same driver on CentOS 6, 7 and Fedora 
20/22 without and issues. Your problem could be caused by numerous 
incompatibilities:

- which version of opensc is installed
- which version of engine_pkcs11 and libp11 are installed
- which *exact* version of the eTPkcs11 driver are you using?

Keep in mind that for the latest OSes you will need the SafeNet client v9

HTH,

JJK

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

Re: [openssl-users] OpenSSL Engine for TPM

[Jan Just Keijser]

Hi,

On 06/07/17 06:39, Christian Hohnstädt wrote:

The trousers project has one.
https://sourceforge.net/projects/trousers/files/OpenSSL%20TPM%20Engine/


agreed, but this engine  does not really put the keys inside the TPM - instead it sets up a local repository that is encrypted 
using a key from the TPM. If you look at the way it is designed, it is not really secure (as it's not impossible to find the 
password that was used to encrypt the keys with).




Am 5. Juli 2017 06:47:24 MESZ schrieb Devang Kubavat 
:

Hi All,

  1.  Is there any built-in OpenSSL Engine to access the TPM ?
  2.  Is there any other OpenSSL Engine to access the TPM ? If Yes, How can 
we configure in OpenSSL libraries to use that
engine ?

Please guide me. Thanks.



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

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

[Jan Just Keijser]

Hi,

On 04/10/17 10:17, lists wrote:

On 09/27/2017 11:13 PM, Ken Goldman wrote:

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.




Most smart cards (G&D, Oberthur and InCard) I've dealt with allow for external 
generation of RSA keys and import into the token.
Currently I mostly use InCard cards sold in Italy, I can't tell if the other 
brands are still easily purchaseable.


FWIW:  I've used mostly Aladdin/Safenet/Gemalto eTokens (32K, 64K, 72K) and they all support the import of RSA keys (as well as 
generation of keys, of course).


Furthermore, if you look at the libp11 library then you will find that it does just that:  generate a key in memory and then 
store it on the etoken. The source code even has a comment about this:


110 /*
111  * Generate and store a private key on the token
112  * FIXME: We should check first whether the token supports
113  * on-board key generation, and if it does, use its own algorithm
114  */
115 int
116 PKCS11_generate_key(PKCS11_TOKEN * token,
117 int algorithm, unsigned int bits, char *label, unsigned char* 
id, size_t id_len)
118 {
119 PKCS11_KEY *key_obj;
120 EVP_PKEY *pk;
121 RSA *rsa;
122 BIO *err;
123 int rc;
124
125 if (algorithm != EVP_PKEY_RSA) {
126 PKCS11err(PKCS11_F_PKCS11_GENERATE_KEY, PKCS11_NOT_SUPPORTED);
127 return -1;
128 }
129
130 err = BIO_new_fp(stderr, BIO_NOCLOSE);
131 rsa = RSA_generate_key(bits, 0x10001, NULL, err);
132 BIO_free(err);
133 if (rsa == NULL) {
134 PKCS11err(PKCS11_F_PKCS11_GENERATE_KEY, PKCS11_KEYGEN_FAILED);
135 return -1;
136 }
137
138 pk = EVP_PKEY_new();
139 EVP_PKEY_assign_RSA(pk, rsa);
140 rc = pkcs11_store_private_key(token, pk, label, id, id_len, &key_obj);



JM2CW,

JJK

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

Re: [openssl-users] ca md too weak

[Jan Just Keijser]

Hi,

On 06/10/17 17:26, Fabrice Delente wrote:

Hello,

Until two days ago I used OpenVPN to connect to my workplace, on a
non-security sensitive tunnel (just for convenience).

However, OpenSSL updated on my machine (Fedora 26), and now the
certificate is rejected:

Fri Oct  6 17:25:06 2017 OpenVPN 2.4.4 x86_64-redhat-linux-gnu [SSL
(OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on
Sep 26 2017
Fri Oct  6 17:25:06 2017 library versions: OpenSSL 1.1.0f-fips  25 May
2017, LZO 2.08
Fri Oct  6 17:25:06 2017 OpenSSL: error:140AB18E:SSL
routines:SSL_CTX_use_certificate:ca md too weak
Fri Oct  6 17:25:06 2017 Cannot load certificate file lcs/delentef.crt
Fri Oct  6 17:25:06 2017 Exiting due to fatal error

What solutions are there to this problem? Can I configure OpenSSL to
accept this certificate after all?



it's not openssl that changed, it's the way openvpn is built on Fedora:
- openvpn 2.4.3 was built and linked against openssl 1.0 , which 
supports MD5 signed certs

- openvpn 2.4.4 was built and linked against openssl 1.1, which does not

Best solution:
- upgrade your CA to use something that's actually secure
Second best:
- downgrade openvpn to 2.4.3 (and get openssl 1.0 support back).

HTH,

JJK

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

Re: [openssl-users] alert number 46:

[Jan Just Keijser]

Hi,

On 12/11/17 05:39, Simon Matthews wrote:

I have generated a new certificate for my CentOS 6/postfix server, and
it seems to work with most clients, but when I try to send email using
tls from my Android device, it always fails.

In my postfix log, I see:

warning: TLS library problem: 13671:error:14094416:SSL
routines:SSL3_READ_BYTES:sslv3 alert certificate
unknown:s3_pkt.c:1275:SSL alert number 46:

I get the same message when using the same new certificate with
dovecot, so I don't think it is a postfix issue.

To generate the certificate, I used the following commands:

openssl genrsa -out MatthewsCA2017.key 2048
openssl genrsa -des3 -out MatthewsCA2017.key 2048
openssl req -x509 -new -nodes -key MatthewsCA2017.key -sha256 -days
3000 -out MatthewsCA2017.pem
openssl genrsa -out smtp.matthews-family.org.uk.key 2048
openssl req -new -key smtp.matthews-family.org.uk.key -out
smtp.matthews-family.org.uk.csr
openssl x509 -req -in smtp.matthews-family.org.uk.csr -CA
MatthewsCA2017.pem -CAkey MatthewsCA2017.key -CAcreateserial -out
smtp.matthews-family.org.uk.crt -days 3000 -sha256

Any ideas on what might be wrong?



you seem to have generated your own (new) CA and server certificate; is 
this CA (public) cert installed in postfix correctly. More importantly, 
is this new CA distributed to all devices?

An alert 46 usually hints at SSL3_AD_CERTIFICATE_UNKNOWN

HTH,

JJK

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

Re: [openssl-users] Building OpenSSL for Intel Xeon Phi

[Jan Just Keijser]

Hi,

On 14/11/17 10:25, Richard Levitte wrote:

 From the look of that PNG, you're building in a native Windows
environment.  The ony configs available in the main source are for
Visual C, and are configured like this:

 perl Configure --prefix=D:\openssl\bin shared VC-WIN64A

If you meant to cross compile for a Linux, I do not have an answer for
you.  In that case, it would probably be better if you could build
directly on the intended box.



good catch - but that is an issue that is hard to overcome with the 
(almost obsolete) Xeon Phi COprocessors.
Normally you'd build a cross-compile for the Phi on the host system 
using the Intel C/C++ compiler, by adding a flag "-mmic" (or /mmic) to 
the CFLAGS variable.
On Linux, this is easy to do - I have built several versions of OpenSSL 
for the KNC Xeon Phi. For Windows, however, you are stuck between an 
OpenSSL environment which only supports VC and an Intel/Xeon Phi 
environment which insists that you use ICC with the flag "-mmic" .


The question asked by the original poster is better answered on the 
Intel MIC developer forum.


cheers,

JJK / Jan Just Keijser

In message <1510585954413-0.p...@n7.nabble.com> on Mon, 13 Nov 2017 08:12:34 -0700 
(MST), Miguel_Diaz  said:

doroshenkoay> Hi,
doroshenkoay> I try build OpenSSl for Intel Xeon Phi coprocessor.
doroshenkoay> So far as I understand this problem reduced to building OpenSSL 
for
doroshenkoay> "linux-generic64" as target.
doroshenkoay> (
doroshenkoay> 
https://software.intel.com/sites/default/files/article/373907/intel-r-xeon-phi-tm-cluster-configuration_1.pdf
doroshenkoay> 
<https://software.intel.com/sites/default/files/article/373907/intel-r-xeon-phi-tm-cluster-configuration_1.pdf>
doroshenkoay> )
doroshenkoay> I use next string for configure:
doroshenkoay>
doroshenkoay> /perl ./Configure --prefix=D:\openssl\bin shared linux-generic64/
doroshenkoay>
doroshenkoay> configure.png 
<http://openssl.6102.n7.nabble.com/file/t10172/configure.png>
doroshenkoay> but makefile not change.
doroshenkoay>
doroshenkoay> Please, help me build OpenSSL for Intel Xeon Phi.
doroshenkoay>
doroshenkoay> Thanks!
doroshenkoay>
doroshenkoay>
doroshenkoay>
doroshenkoay> --
doroshenkoay> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
doroshenkoay>


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

Re: [openssl-users] SSL alert number 48

[Jan Just Keijser]

Hi,

On 27/11/17 17:07, wizard2...@gmail.com wrote:

Hi there.

I'm getting this error on a TLS server&client that I'm implementing and I can't 
really understand what I'm doing wrong.

139853560931992:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert 
unknown ca:s3_pkt.c:1487:SSL alert number 48
139853560931992:error:140790E5:SSL routines:ssl23_write:ssl handshake 
failure:s23_lib.c:177:


This is the code of my server: https://pastebin.com/Fyuki8v0 and I generate the certificates this way: 
https://pastebin.com/CDRKU2Gc

And I'm testing the server this way: openssl s_client -host 127.0.0.1 -port 
 -cert client.crt -key client.key -CAfile ca.crt

If I run a server this way openssl s_server -key server.key -cert server.crt 
-CAfile ca.crt -accept 
I'm able to communicate with the same certificates and on my server code I 
always get:

Handshake Error 1
SSL_ERROR_SSL...

This is the result of openssl s_client command: https://pastebin.com/AWid1mxi

FWIW: I've downloaded and compiled your code, generated certs using your script (which generates a client and server cert with 
the same serial number, BTW) and ran the code: I can connect just fine using either openssl 1.0.1e or 1.1.0e


My bet is that when you run your code you are not loading the right ca.crt file ; another way to debug is , is to add a x509 
verify callback which prints out each cert as it is passed for verification.


HTH,

JJK

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

Re: [openssl-users] SSL alert number 48

[Jan Just Keijser]

Hi,

On 28/11/17 11:03, wizard2...@gmail.com wrote:

Hi there.

I guess my problem is really related to verify callback on SSL_CTX_set_verify 
function.
I just add to my code a dummy callback returning 1 and everything works 
properly.


int verify_callback (int ok, X509_STORE_CTX *ctx);
int verify_callback (int ok, X509_STORE_CTX *ctx)
{
printf("Verification callback OK!\n");
    return 1;
}
...
SSL_CTX_set_verify(ssl_server_ctx, SSL_VERIFY_PEER | 
SSL_VERIFY_FAIL_IF_NO_PEER_CERT, dtls_verify_callback);
...


The problem is that error don't tell much information about what's really going 
on or what's really missing.
Thanks for your help.


Now you've effectively disabled all security :)

Try adding this to the verify_callback


static int verify_callback(int ok, X509_STORE_CTX *ctx)
{
    X509   *cert = NULL;
    char   *cert_DN = NULL;

    printf("ok = %d\n", ok);
    cert    = X509_STORE_CTX_get_current_cert(ctx);
    cert_DN = X509_NAME_oneline( X509_get_subject_name( cert ), NULL, 0 );
    printf( "cert DN: %s\n", cert_DN);

}


that way, you will know whether your server is processing the right certificate 
chain.

HTH,

JJK

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

Re: [openssl-users] SSL alert number 48

[Jan Just Keijser]

Hi,

On 29/11/17 14:37, wizard2...@gmail.com wrote:

Hi JJK,

I test you function and I've got this result:

ok = 0
cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
ok = 1
cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd


Why I see this 2 time?
When I create the certificates I didn't fill with any special information, just type enter in every question that is made. Did 
you think this could cause this issue?




what you should have seen is the certificate stack, starting with the CA, and 
then the client cert, e.g.

Connection accept...
ok = 1
cert DN: /C=US/O=Cookbook 2.4/CN=Cookbook 2.4 
CA/emailAddress=open...@example.com
ok = 1
cert DN: /C=US/O=Cookbook 2.4/CN=client1


so I suspect that your ca.crt on the server side is not specified correctly.
You may also send me your ca.crt, server.{crt,key} and client.{crt,key} files privately, and I will run the same test using your 
set of certificates.


HTH,

JJK




On Wed, Nov 29, 2017 at 8:56 AM, Jan Just Keijser mailto:janj...@nikhef.nl>> wrote:

Hi,

On 28/11/17 11:03, wizard2...@gmail.com <mailto:wizard2...@gmail.com> wrote:

Hi there.

I guess my problem is really related to verify callback on 
SSL_CTX_set_verify function.
I just add to my code a dummy callback returning 1 and everything works 
properly.


int verify_callback (int ok, X509_STORE_CTX *ctx);
int verify_callback (int ok, X509_STORE_CTX *ctx)
{
printf("Verification callback OK!\n");
    return 1;
}
...
SSL_CTX_set_verify(ssl_server_ctx, SSL_VERIFY_PEER | 
SSL_VERIFY_FAIL_IF_NO_PEER_CERT, dtls_verify_callback);
...


The problem is that error don't tell much information about what's really 
going on or what's really missing.
Thanks for your help.


Now you've effectively disabled all security :)

Try adding this to the verify_callback


static int verify_callback(int ok, X509_STORE_CTX *ctx)
{
    X509   *cert = NULL;
    char   *cert_DN = NULL;

    printf("ok = %d\n", ok);
    cert    = X509_STORE_CTX_get_current_cert(ctx);
    cert_DN = X509_NAME_oneline( X509_get_subject_name( cert ), NULL, 0 );
    printf( "cert DN: %s\n", cert_DN);

}


that way, you will know whether your server is processing the right 
certificate chain.

HTH,

JJK




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

Re: [openssl-users] SSL alert number 48

[Jan Just Keijser]

Hi,

On 04/12/17 09:10, wizard2...@gmail.com wrote:

Hi ,

Please see in attach the files that I'm using.


I've just taken a look at your certificates and they've not been 
generated correctly:


$ openssl x509 -subject -issuer -noout -in ca.crt -dates -serial
subject= /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
issuer= /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
notBefore=Nov 27 11:52:34 2017 GMT
notAfter=Nov 27 11:52:34 2018 GMT
serial=A1E0F7319AAD90C0

$ openssl x509 -subject -issuer -noout -in client.crt -dates -serial
subject= /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
issuer= /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
notBefore=Nov 27 11:53:16 2017 GMT
notAfter=Nov 27 11:53:16 2018 GMT
serial=01

$ openssl x509 -subject -issuer -noout -in server.crt -dates -serial
subject= /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
issuer= /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
notBefore=Nov 27 11:52:55 2017 GMT
notAfter=Nov 27 11:52:55 2018 GMT
serial=01


that is, the subject and issuer of the CA, server and client certs are 
all the same ; also, the serial number of both client and server 
certificates are the same.
You will need to alter the way you generate your certificates so that 
there is a clear distinction between CA, server and client cert.


HTH,

JJK



I generate the certificates with the following commands:

1.
## Create CA
2.
openssl genrsa -out ca.key 4096
3.
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
4.
openssl x509 -in ca.crt -out ca.pem -outform PEM
5.

1.
## Create the Server Key and CSR
2.
openssl genrsa -out server.key 4096
3.
openssl req -new -key server.key -out server.csr
4.
openssl x509 -req -days 365 -in server.csr -CA ca.crt
-CAkey ca.key -set_serial 01 -out server.crt
5.
openssl x509 -in server.crt -out server.pem -outform PEM
6.

1.
## Create the Client Key and CSR
2.
openssl genrsa -out client.key 4096
3.
openssl req -new -key client.key -out client.csr
4.
openssl x509 -req -days 365 -in client.csr -CA ca.crt
-CAkey ca.key -set_serial 01 -out client.crt
5.
openssl x509 -in client.crt -out client.pem -outform PEM


I left the default value of each question that openssl ask when it's 
creating the certificates like Country, City, CN, etc. Like this way:


openssl req -new -key server.key -out server.csr

You are about to be asked to enter information that will be
incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished
Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-

Country Name (2 letter code) [AU]:

State or Province Name (full name) [Some-State]:

Locality Name (eg, city) []:

Organization Name (eg, company) [Internet Widgits Pty Ltd]:

Organizational Unit Name (eg, section) []:

Common Name (e.g. server FQDN or YOUR name) []:

Email Address []:

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

Thanks.
Kind regards.


On Thu, Nov 30, 2017 at 2:45 PM, Jan Just Keijser <mailto:janj...@nikhef.nl>> wrote:


Hi,

On 29/11/17 14:37, wizard2...@gmail.com
<mailto:wizard2...@gmail.com> wrote:

Hi JJK,

I test you function and I've got this result:

ok = 0
cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
ok = 1
cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd


Why I see this 2 time?
When I create the certificates I didn't fill with any special
information, just type enter in every question that is made. Did
you think this could cause this issue?



what you should have seen is the certificate stack, starting with
the CA, and then the client cert, e.g.

Connection accept...
ok = 1
cert DN: /C=US/O=Cookbook 2.4/CN=Cookbook 2.4
CA/emailAddress=open...@example.com
<mailto:CA/emailAddress=open...@example.com>
ok = 1
cert DN: /C=US/O=Cookbook 2.4/CN=client1


so I suspect that your ca.crt on the server side is not specified
correctly.
You may also send me your ca.crt, server.{crt,key} and
client.{crt,key} files privately, and I will run the same test
using your set of certificates.

HTH,

JJK





On Wed, Nov 29, 2017 at 8:56 AM, Jan Just Keijser
mailto:janj...@nikhef.nl>> wrote:

Hi,

On 28/11/17 11:03, wizard2...@gmail.com
<mailto:wizard2...@gmail.com> wrote:

Hi there.

I guess my problem is really related to verify callback
on SSL_CTX_set_verify function.
I jus

Re: [openssl-users] SSL alert number 48

[Jan Just Keijser]

Hi,

On 12/12/17 11:06, wizard2...@gmail.com wrote:

Hi.

Ok, I agree with you that the way I generate the certificates could 
not be the right one, but now I change the way and the problem remains.
Please check the way I'm creating the certificates. I create a ROOT-CA 
entity and a INTERMEDIATE-CA that is responsible to generate the 
CLIENT and SERVER certificates.
This is the script [ https://pastebin.com/bw6j5AZz ] that I'm using to 
create this small PKI example


you're changing the game as you go along -- now you want an intermediate 
CA all of a sudden ;)
Still, with the certs you've sent this time I can get it to work, with a 
minor code change: instead of using

  SSL_CTX_use_certificate_chain_file(...)
I am using
  SSL_CTX_use_certificate_chain_file(ssl_server_ctx, SSL_SERVER_RSA_CERT)

then make sure that RSA_CA_CRT points to root-ca.crt and that 
SERVER_RSA_CRT points to server.pem, which contains the intermediate CA 
as a stacked cert; on the client side, use your stacked client.pem file 
as well. In that case I can connect to your server program using
  openssl s_client -connect 127.0.0.1: -CAfile root-ca.crt -cert 
client.pem -key client.key


HTH,

JJK

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

Re: [openssl-users] [EXTERNAL] Certificate gets verified OK over SSL-CLI, but not when using SSL-API

[Jan Just Keijser]

Hi,

On 22/12/17 11:14, Manuel Wagesreither wrote:

Unfortunately this didn't work either. The end result is the same; OpenSSL still emits a 
"certificate signature failure" with an error depth of 0.


here's a stripped down version of my 'grid-proxy-verify.c' that verifies 
a certificate loaded from memory. My cert is included in the file. The 
CA used to verify the certificate is loaded from a directory, but the 
principle for reading a CA file from memory is the same:


char CAdata[] = "";

if ( !(CA_bio = BIO_new_mem_buf(CAdata, -1) ) ) return ERR_get_error();

etc.
This code is a bit overkill - it will verify a stack of certificates, 
not just a single one, but I am sure you can rework it just to verify a 
single cert ;)



HTH,

JJK



#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 

#include 
#include 

#define L_ERROR  0  /* errors */
#define L_WARN   1  /* all unusual */
#define L_INFO   2  /* all status changes etc. */
#define L_DEBUG  3  /* all, including trace */

intlog_level = 1;

void Log( int msg_level, const char *msg, ...)
{
va_list argp;

if ( log_level >= msg_level )
{
if (msg_level == L_WARN )  fprintf( stderr, "Warning: " );
if (msg_level == L_INFO )  fprintf( stderr, "Info:" );
if (msg_level == L_DEBUG ) fprintf( stderr, "Debug:   " );
va_start( argp, msg );
vfprintf( stderr, msg, argp );
va_end( argp );
fprintf( stderr, "\n" );
}
}

void Error( const char *operation, const char *msg, ...)
{
va_list argp;

fprintf( stderr, "ERROR:  %s: ", operation );
va_start( argp, msg );
vfprintf( stderr, msg, argp );
va_end( argp );
fprintf( stderr, "\n" );
}


unsigned long read_memCert( STACK_OF(X509) **certstack )
{
char*oper = "Reading mem";

STACK_OF(X509_INFO) *sk  = NULL;
BIO *certbio = NULL;
X509_INFO   *xi;
unsigned longerr;

char data[] = "\n\
-BEGIN CERTIFICATE-\n\
MIIE7zCCA9egAwIBAgICFF8wDQYJKoZIhvcNAQELBQAwUjELMAkGA1UEBhMCTkwx\n\
DzANBgNVBAoTBk5JS0hFRjEyMDAGA1UEAxMpTklLSEVGIG1lZGl1bS1zZWN1cml0\n\
eSBjZXJ0aWZpY2F0aW9uIGF1dGgwHhcNMTcwNTMxMDAwMDAwWhcNMTgwNTMxMTQ1\n\
NzQwWjBQMRIwEAYDVQQKEwlkdXRjaGdyaWQxDjAMBgNVBAoTBXVzZXJzMQ8wDQYD\n\
VQQKEwZuaWtoZWYxGTAXBgNVBAMTEEphbiBKdXN0IEtlaWpzZXIwggEiMA0GCSqG\n\
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUgM6fRU95Qs/qiquRpLqtLFX2EEooIFFm\n\
Jo0IxwpISgIq37HUgfbNBB97ZXaMDtrWrcJt1PbXIj7NCXsDJ4V6zueKwx3Dsr2W\n\
H5V9FvK6bj+vz3S1bOvG1EJUpnS81/Fmlawkd7bK7dXwuZVbUp7QcmzGuwmFO3/3\n\
h2sX5a1z7gkb3VZXIyFk2lz1W+bt4bgb6WNvcOZuXwbawsF4F6LZkaHJ6JwsuZMc\n\
/gIOhQYXD4+KPOG96/PRgpC7BBWcwfmg9fPNxp09QD6q9XEM9MN307BYQ7BWAgrq\n\
yUvhL69/+DIBCwkcUnzWxeZbcsfziHx/HUR251NybNsp6Mu+IdjJAgMBAAGjggHP\n\
MIIByzAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggr\n\
BgEFBQcDAgYIKwYBBQUHAwQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NhLmR1\n\
dGNoZ3JpZC5ubC9tZWRpdW0vY2FjcmwuZGVyMCgGA1UdIAQhMB8wDwYNKwYBBAHR\n\
QgQCAgEDAjAMBgoqhkiG90wFAgIBMB8GA1UdIwQYMBaAFFsFOpnG1SK9/ZSA/BGo\n\
0PFx1kukMB0GA1UdDgQWBBRrObKYCp8RcKwXn4kcHa6zFXpU7DARBglghkgBhvhC\n\
AQEEBAMCBaAwNAYJYIZIAYb4QgEIBCcWJWh0dHA6Ly9jYS5kdXRjaGdyaWQubmwv\n\
bWVkaXVtL3BvbGljeS8wgZ4GCWCGSAGG+EIBDQSBkBaBjUVFQyBpc3N1ZWQgdW5k\n\
ZXIgcG9saWN5IHZlcnNpb24gMy4yIC0gbGltaXRlZCBsaWFiaWxpdGllcyBhcHBs\n\
eSwgc2VlIGh0dHA6Ly9jYS5kdXRjaGdyaWQubmwvbWVkaXVtL3BvbGljeS8gLSBD\n\
ZXJ0aWZpY2F0ZSBUYWc6IDY5MDRhMTdkLTk0ODBjZTANBgkqhkiG9w0BAQsFAAOC\n\
AQEAeLFnQAYF4FWHJ0y+7T9bUtFoQLv6ZsqBlaSwlzuhpSMlOVvzOLvqlmLVdbk5\n\
nkEBu008FBTA2r9UysIhB00MxhypAxkhzIXxfslZBwtxdmZ0s0MBoIwLb6Lo3Td5\n\
ktFKra31KOlwdiAFZxmsi5Du4p+sY5uW5RNIsa9dxqccOd0+TOglARF/sF5xliHv\n\
x8y+qvVmiMBa0nZmvqO0OQfTb4oNbByGeeH6yQyQqxWpJwwdXx+Q4JJhZhXAJIOt\n\
Ze52sXps/K/1R3laqXaEW7xYZbragtgimbkMkPCHr6624ajslViyqI2efwlI1+em\n\
ueVU4EK03fp65Egd6Qs9yx5+VA==\n\
-END CERTIFICATE-\n\
";

Log( L_DEBUG, "--- Welcome to the read_memCert function ---");

*certstack = sk_X509_new_null();
if (*certstack == NULL) return ERR_get_error();

if ( !(certbio = BIO_new_mem_buf(data, -1) ) ) return ERR_get_error();

Log( L_DEBUG, "Reading X509_INFO records" );
if ( !(sk=PEM_X509_INFO_read_bio(certbio, NULL, NULL, NULL)) )
{
err = ERR_get_error();
Error( oper, "No X509 records found" );
BIO_free(certbio);
sk_X509_INFO_free(sk);
sk_X509_free(*certstack);
*certstack = NULL;
return err;
}

while (sk_X509_INFO_num(sk))
{
xi=sk_X509_INFO_shift(sk);
if (xi->x509 != NULL)
{
sk_X509_push(*certstack, xi->x509);
xi->x509=NULL;
}
X509_INFO_free(xi);
}

if (!sk_X509_num(*certstack))
{
err = ERR_get_error();
Error( oper, "No certificates found" );
BIO_free(certbio);
sk_X509_INFO_free

Re: [openssl-users] database openssl

[Jan Just Keijser]

Hi,

On 29/05/18 09:47, Sampei wrote:
I'm using Linux server to create temporary CA and I know openssl maintains a text database of issued certificates and their 
status.

Now I need to migrate this server to another one, so I ask myself how can I 
export this db.
thanks



the openssl CA "database" usually consists of two files. The location of these files is specified in the openssl.cnf file. The 
files are

  serial   - containing the last issued serial number
  index.txt  - containing the list of all issued, expired and revoked 
certificates.

As I said, the location of these files is depending on how you set up your 
temporary CA.

HTH,

JJK

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

Re: [openssl-users] 2 openssl installed?

[Jan Just Keijser]

Hi,

On 07/06/18 06:14, Sampei wrote:


t’s a server installed many many years ago and there are applications 
which are no used.
Server is too late and I have new server (latest Centos 6) for 
migrating where I installed latest version.
I’d like to take to new server all certificate database (certificated 
included) which I created.

Openssl is only tool to create test certificates.
I don’t know if there are apps which are using the e configs, but I 
think no.


this has little to do with OpenSSL itself and more with PKI management. 
Basically, your problem seems to be that you have an older server and 
you don't know where the certificates and private keys (i.e. the PKI) 
were stored. What you need to do, is find out where the certifcates are 
held, together with the index.txt file. In order to do so, you could use 
something like

  find / -name '*.pem'
or
  find / -name index.txt
and check all directories where such files are found. This will be a 
lengthy process, as the find command has to traverse the entire filesystem.


good luck,

JJK

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

Re: [openssl-users] Add OpenSSL-support to a project

[Jan Just Keijser]

On 05/11/18 23:58, Thomas Schmiedl wrote:

Hello,

I use xupnpd2-mediaserver (http://xupnpd.org/xupnpd2_en.html) on my router to 
display HLS-streams on my TV.

Some HLS-streams require a https-connection. I contacted the xupnpd2-author several times but I didn't get a reply. Since some 
days, he published the source (https://github.com/clark15b/xupnpd2).


I'm not a developer, but I hope that someone in this mailinglist could 
integrate the OpenSSL/https-support to the xupnpd2 source.



I hate to be blunt, but
1) really, wrong forum to ask: the openssl users list is not a place to ask for 
"please add OpenSSL support to XXX"
2) when I look at the sources for xupnpd2, it already *HAS* openssl support - 
simply rebuild it to get openssl support
3) you are not mentioning anything about the OS of your TV - most likely you will need to set up a special build environment to 
build apps for your TV.  Again, this would not be the right forum to ask for support on that.



regards,

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

Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list

[Jan Just Keijser]

Hi,

On 03/12/18 21:40, Viktor Dukhovni wrote:

On Dec 3, 2018, at 3:35 PM, Charles Mills  wrote:

OCSP and OCSP stapling are currently higher on my wish list than this.

Good luck with OCSP, the documentation could definitely be better, and
various projects get it wrong.  IIRC curl gets OCSP right, so you
could look there for example code, some other projects go through the
motions, but don't always achieve a robust result.

[ FWIW, I don't care much for OCSP, it's often not required, so it is
   then not clear what security properties it provides. ]


the only reason to use OCSP I currently have is in Firefox:  if you turn 
off "Query OCSP responder servers" in Firefox then EV certificates will 
no longer show up with their owner/domain name. Now the question is:   
does Firefox get OCSP "right" ;) ?


cheers,

JJK / Jan Just Keijser

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

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Jan Just Keijser]

Hi,

On 04/03/19 09:08, Wolfgang Knauf wrote:


Hi,

I first asked this question in the OpenVPNGui forum, and they redirected me to here: OpenVPNGui 2.4.6 works with a customers 
server certificate, but it fails when using 2.4.7.


Here is the thread in the OpenVPNGui forum: https://forums.openvpn.net/viewtopic.php?f=24&t=27976 
<https://forums.openvpn.net/viewtopic.php?f=24&t=27976>


The error is:

Thu Feb 28 08:48:50 2019 VERIFY ERROR: depth=0, error=*format error in certificate's notAfter field*: C=de, L=Dortmund, 
O=Versatel, CN=ASG_1, emailAddress=...


The certificate has those fields:

    Validity

    Not Before: Oct 22 13:28:29 2009 GMT

    Not After : Mar  8 13:28:29 2037 GMT

The customer provided us with a „…..ca.crt“ file, a „….user.crt“ file and a „user.key“ file. But I fear it is not smart to 
post those files in the internet ;-).




you can safely post the client.crt file - it is public info and useless without 
the key file.

Having said that, I just created a certificate set to expire on Mar 9 2037 and 
it passed the following command:
  c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in 
mycert.crt

can you run the same command on the failing certificate?

HTH,

JJK / Jan Just Keijser

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Jan Just Keijser]

Hi Richard,

On 04/03/19 10:27, Richard Levitte wrote:

On Mon, 04 Mar 2019 10:06:54 +0100,
Jan Just Keijser wrote:
...

Having said that, I just created a certificate set to expire on Mar 9 2037 and 
it passed the
following command:
   c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in 
mycert.crt

can you run the same command on the failing certificate?

That's a poor test.  'openssl x509' doesn't verify the certificate,
and the error comes up during verification.  To verify, use 'openssl
verify'.  Here's an example with OpenSSL test files:

 openssl verify -trusted test/certs/root-cert.pem test/certs/ca-cert.pem

So in Wolfgang's case, I suspect something like this would say more:

 openssl verify -trusted .ca.crt .user.crt



you were one step ahead of me :)
I fully agree that it is a poor test, I was just wondering if there was 
an encoding error in the cert itself, esp as the EndDate approaches the 
32bit epoch...


Wolfgang, can you send me both the client cert and the CA cert that goes 
with it? both are public info.


cheers,

JJK / Jan Just Keijser

Re: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Jan Just Keijser]

On 04/03/19 10:21, Wolfgang Knauf wrote:

Hi,

the output is this:

C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in 
..\config\ssl_h...@l1139218.vt-security.de\l1139218.vt-security.de.user.crt
Error: offset too large

Would it be OK if I send the crt file to only your mail adress? I don't feel 
save by posting it to the mailing list ;-)?


I ran into the "offset too large" problem myself with my own certs as 
well. It turns out the 'asn1parse' util only likes PEM blobs, i.e. the 
parts starting with --BEGIN CERTIFICATE--


You can use
  openssl x509 -in l1139218.vt-security.de.user.crt -out | openssl 
ans1parse

to work around this.
For your certificates this results in

    0:d=0  hl=4 l= 942 cons: SEQUENCE
    4:d=1  hl=4 l= 791 cons: SEQUENCE
    8:d=2  hl=2 l=   3 cons: cont [ 0 ]
   10:d=3  hl=2 l=   1 prim: INTEGER   :02
   13:d=2  hl=2 l=   9 prim: INTEGER   :C604316CD0321FA1
   24:d=2  hl=2 l=  13 cons: SEQUENCE
   26:d=3  hl=2 l=   9 prim: OBJECT :sha256WithRSAEncryption
   37:d=3  hl=2 l=   0 prim: NULL
[...]
  155:d=2  hl=2 l=  30 cons: SEQUENCE
  157:d=3  hl=2 l=  13 prim: UTCTIME   :160418140054Z
  172:d=3  hl=2 l=  13 prim: UTCTIME   :370308132808Z
  187:d=2  hl=2 l=  88 cons: SEQUENCE
  189:d=3  hl=2 l=  11 cons: SET
  191:d=4  hl=2 l=   9 cons: SEQUENCE
  193:d=5  hl=2 l=   3 prim: OBJECT    :countryName
  198:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :de

In other words, the dates look OK to me.
Also, I've thrown my own verification code against the certificate and 
everything checks out OK.

I'll see if I can reproduce the issue in my own OpenVPN setup.

HTH,

JJK / Jan Just Keijser

Re: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Jan Just Keijser]

Hi Matt,

On 04/03/19 14:24, Matt Caswell wrote:


On 04/03/2019 13:16, Jan Just Keijser wrote:

On 04/03/19 10:21, Wolfgang Knauf wrote:

Hi,

the output is this:

C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in
..\config\ssl_h...@l1139218.vt-security.de\l1139218.vt-security.de.user.crt
Error: offset too large

Would it be OK if I send the crt file to only your mail adress? I don't feel
save by posting it to the mailing list ;-)?



I ran into the "offset too large" problem myself with my own certs as well. It
turns out the 'asn1parse' util only likes PEM blobs, i.e. the parts starting
with --BEGIN CERTIFICATE--

asn1parse will expect PEM by default but is perfectly capable of processing raw
DER too. Just use the "-inform DER" option.


100% true but that is not what I was referring to; my certs usually look 
like this:


Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number: 5338 (0x14da)
    Signature Algorithm: sha256WithRSAEncryption
[...]
-BEGIN CERTIFICATE-
MIIEmjCCA4KgAwIBAgICFNowDQYJKoZIhvcNAQELBQAwUjELMAkGA1UEBhMCTkwx


it's that part *before* the --BEGIN CERTIFICATE--  on which the 
asn1parse command chokes. You can feed it either a DER file or a PEM 
blob - but not a certificate file with the certificate info listed in it.


JJK

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Jan Just Keijser]

eed contain a poorly formatted 
date:


$ openssl asn1parse -in server.crt | grep UTC
  157:d=3  hl=2 l=  13 prim: UTCTIME   :091022132829Z
  172:d=3  hl=2 l=  17 prim: UTCTIME   :370308132808+

OpenSSL 1.0.x groks this, 1.1+ does not.

cheers,

JJK / Jan Just Keijser

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Jan Just Keijser]

Hi all,

On 06/03/19 16:36, Jakob Bohm via openssl-users wrote:

On 06/03/2019 16:17, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On 
Behalf Of

Richard Levitte
Sent: Wednesday, March 06, 2019 03:07

On Wed, 06 Mar 2019 10:52:44 +0100,
Jan Just Keijser wrote:

as a follow-up:  Richard's analysis/suspicion was spot on.
However, it was the *server* side certificate that was causing the
error, and the server certificate does indeed contain a poorly
formatted date:

$ openssl asn1parse -in server.crt | grep UTC
   157:d=3  hl=2 l=  13 prim: UTCTIME :091022132829Z
   172:d=3  hl=2 l=  17 prim: UTCTIME :370308132808+

I'm glad I could help find the answer.


OpenSSL 1.0.x groks this, 1.1+ does not.

Yup, 1.1+ is stricter regarding these things.
I would have expected 1.0.2p and later to have rejected this as well, 
since the RFC 5280 restrictions on validity date attributes were 
included in that release. There was some discussion about it on the 
OpenSSL lists, with some people suggesting that a change to insist on 
the letter of the standard which broke compatibility with 
certificates generated by some other implementations was not a great 
idea. (I am sympathetic to this argument myself, and feel there 
should at least be an option to relax these restrictions.)


See for example: 
https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html


It's interesting to note that back in 2009 when GeneralizedTime 
support for X.509 dates was added to OpenSSL, Erwann Abalea pointed 
out that RFC 5280 is only a profile of X.509, and X.509 itself allows 
timezone offsets and fracttional seconds, and so arguably OpenSSL 
ought to allow them too (presumably for use by non-TLS X.509 
applications). (See e.g. 
http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.) 
Personally, I find that argument persuasive too, and think that it 
would be appropriate to have a mechanism to disable the 5280 checks.


Maybe I'll put together a PR, though I don't know if it has much 
chance of being accepted.




RFC5280 etc. is not even a requirement for SSL/TLS (it certainly
can't be for SSL versions before it), only for the publicly
trusted certificates used on the global Internet.  So arguably,
it should not apply to running TLS between closely related
parties (as is the traditional use case for something
like OpenVPN).

Running a private protocol over TLS between my server in one
building and my server in another building doesn't involve
the WebPKI.

It is of cause prudent for libraries to produce RFC5280
compliant certificates by default, and for test tools
(such as the "openssl x509" and "openssl validate"
commands) to warn when a certificate is outside the
standards for public certificates.


so to recapitulate:
- OpenSSL 1.1+ (and possible 1.0.2) introduced stricter RFC5280 
checks when doing certificate validation
- This causes certificates that contain fields that are not fully 
RFC5280 compliant to fail validation
- However, as Jakob states, there is no requirement in TLS for RFC5280 
compliance


Should this be considered a bug in OpenSSL then? If this is not 
considered a bug, shouldn't OpenSSL then state this as a requirement for 
certificate creaton?


Of course, the easy solution is to tell people to create and use RFC5280 
compliant certificates, but what if someone has a legitimate use case 
for not being able or wanting to do so?
Is there a way to loosen the verification checks (apart from writing a 
custom verify_callback) ?


thanks for any advice,

JJK / Jan Just Keijser

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Jan Just Keijser]

Hi Erwann,

On 07/03/19 11:35, Erwann Abalea via openssl-users wrote:

Bonjour,

Here, reject the certificate is the correct behaviour, IMO.

UTCTime/GeneralizedTime are defined in X.680.

UTCTime:
  - can have no timezone information, or have Z, of have a timezone offset 
(with hours and minutes)
  - can be precise up to the second, or be precise up to the minute
  - cannot have fractional seconds or minutes
  - cannot have second 60 (think of leap seconds)
  - is not subject to ISO8601 rules

GeneralizedTime:
  - can have no timezone information, or have Z, of have a timezone offset 
(either hours, or hours and minutes)
  - can be precise up to the second with optional fractional seconds, or be 
precise up to the minute and have fractional minutes, or be precise up to the 
hour and have fractional hours (any number of decimal places)
  - shall follow ISO8601 rules (including leap seconds)
  - cannot support the "midnight at end of day" (24)



thanks for the clarification and note that either way it's fine with me 
- I just wanted to know what message to tell to OpenVPN users who run 
into this issue. The 'correct' answer seems to be:


"Your certificate is invalid and was always invalid, but up til now 
OpenSSL grokked it.  OpenSSL (and therefore OpenVPN) no longer likes 
your cert, so get a new one"


cheers,

JJK / Jan Just Keijser

Re: Reg slowness seen in openssl 1.1.1

[Jan Just Keijser]

On 10/05/19 03:16, ramakrushna mishra wrote:

Hi ,

The results on a AIX machine looks more bad If I am interpreting them 
correctly.


openssl 1.1.0e :
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes  1024 bytes   8192 
bytes  16384 bytes
sha1             65019.16k   151552.49k   266107.41k  337113.93k  
 360792.93k   364102.89k



openssl 1.1.1 :
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes  1024 bytes   8192 
bytes  16384 bytes
sha1             10641.28k    21433.09k    38464.85k 48496.92k    
49381.38k    51755.48k



the numbers for openssl 1.1.1 seem wrong - I've ran a similar test on a 
POWER8 and POWER9 box and the results for a "out of the box compiled" 
openssl 1.1.0 vs openssl 1.1.1 are much closer.
The only difference I did see was the (obsolete) sha1 test on Power8:  
openssl 1.1.1 seems to be a bit slower than 1.1.0, but not by a factor 
of 7 as shown above.


Also, on both POWER8 and POWER9, there does not appear to be a major 
difference in blowfish or aes-256 speed.


As for your code: I would check that you are not using a no-asm build 
for openssl 1.1.1.


HTH,

JJK

Re: Reg slowness seen in openssl 1.1.1

[Jan Just Keijser]

Hi,

On 10/05/19 02:29, ramakrushna mishra wrote:

Hi,

Could anyone please help me wth it.

Following are sslc speed results for SHA1.

[...]
OpenSSL 1.1.0e  16 Feb 2017
type             16 bytes     64 bytes    256 bytes   1024 bytes  
 8192 bytes  16384 bytes
sha1             90515.06k   301813.93k   551106.78k  701554.35k  
 729893.50k   832176.13k


[...]


OpenSSL 1.1.1  11 Sep 2018type             16 bytes  64 bytes    256 
bytes   1024 bytes   8192 bytes  16384 bytes
sha1             90645.60k   245118.29k   455184.27k  684999.34k  
 752292.25k   822811.06k




I have a lot of experience running 'openssl speed' tests and these 
numbers would not worry me too much - if you were to run each of these 
tests 10 times **on an empty system** , then average the results , then 
most likely you will find that the results are within 5% of each other.


IOW, OpenSSL 1.1.1 is just as fast/slow on this purely artificial speed 
test as 1.1.0


HTH,

JJK

Re: OpenSSL 1.1.1 RPM for CentOS 7

[Jan Just Keijser]

On 02/07/19 23:52, Dennis Clarke wrote:

On 7/2/19 12:12 PM, Karel de Henks wrote:

Hi,

I'm searching on the internet for an OpenSSL version 1.1.1. RPM package for 
CentOS 7.
However, I cannot find this. Perhaps one of the users in the mailing list has 
this package already available.




On CentOS or RHEL 7 it should be totally trivial to just build it from
the sources and install into /usr/local.  Why do you ( and others ) feel
you *need* a package from some mystery person ?


added to that : it is not possible (or at the least not worth the effort) to replace the system openssl package (1.0.2k) with a 
v1.1.1 package, as you would break almost *every* RPM that depends on it.


JM2CW,

JJK

Re: Errors building 1.1.1 on RHEL 7

[Jan Just Keijser]

FWIW:

I just downloaded openssl 1.1.1c, untarred it on my CentOS 7 box, then ran
  ./config
  make
  make test

The tests passed with the following output (the "ok" tests stripped out):

...
../test/recipes/05-test_md2.t .. skipped: md2 is not 
supported by this OpenSSL build

...
../test/recipes/05-test_rc5.t .. skipped: rc5 is not 
supported by this OpenSSL build

...
../test/recipes/30-test_afalg.t  skipped: test_afalg 
not supported for this build

...
../test/recipes/90-test_gost.t . skipped: No test 
GOST engine found

...
../test/recipes/90-test_overhead.t . skipped: Only 
supported in no-shared builds

...
../test/recipes/95-test_external_boringssl.t ... skipped: No 
external tests in this configuration
../test/recipes/95-test_external_krb5.t  skipped: No 
external tests in this configuration
../test/recipes/95-test_external_pyca.t  skipped: No 
external tests in this configuration

...
All tests successful.
Files=155, Tests=1452, 66 wallclock secs ( 1.44 usr  0.11 sys + 62.90 
cusr 13.51 csys = 77.96 CPU)

Result: PASS
make[1]: Leaving directory `/home/janjust/src/openssl-1.1.1c'


Share and enjoy,

JJK

On 17/07/19 00:27, Mark Richter wrote:

I removed the directory, re-untarred the source, ran 'make clean', then 'make', 
then 'make TESTS=test_dsa V=1 test':

[root@sfsdr220d openssl-1.1.1]# make TESTS=test_dsa V=1 test
make depend && make _tests
make[1]: Entering directory `/tmp/openssl-1.1.1'
make[1]: Leaving directory `/tmp/openssl-1.1.1'
make[1]: Entering directory `/tmp/openssl-1.1.1'
( cd test; \
   mkdir -p test-runs; \
   SRCTOP=../. \
   BLDTOP=../. \
   RESULT_D=test-runs \
   PERL="/usr/bin/perl" \
   EXE_EXT= \
   OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \
   OPENSSL_DEBUG_MEMORY=on \
 /usr/bin/perl .././test/run_tests.pl test_dsa )
/tmp/openssl-1.1.1/test
../test/recipes/15-test_dsa.t ..
1..6
ok 1 - require '../../test/recipes/tconversion.pl';
 # Subtest: ../../test/dsatest
 1..1
 ok 1 - dsa_test
../../util/shlib_wrap.sh ../../test/dsatest => 0
ok 2 - running dsatest
 # Subtest: ../../test/dsa_no_digest_size_test
 1..3
 ok 1 - dsa_exact_size_test
 ok 2 - dsa_small_digest_test
 ok 3 - dsa_large_digest_test
../../util/shlib_wrap.sh ../../test/dsa_no_digest_size_test => 0
ok 3 - running dsa_no_digest_size_test
 1..10
 ok 1 - initializing
read DSA key
writing DSA key
../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-fff.p -inform p -out 
dsa-f.d -outform d => 0
 ok 2 - p -> d
read DSA key
writing DSA key
../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-fff.p -inform p -out 
dsa-f.p -outform p => 0
 ok 3 - p -> p
read DSA key
writing DSA key
../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.d -inform d -out 
dsa-ff.dd -outform d => 0
 ok 4 - d -> d
read DSA key
writing DSA key
../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.p -inform p -out 
dsa-ff.pd -outform d => 0
 ok 5 - p -> d
read DSA key
writing DSA key
../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.d -inform d -out 
dsa-ff.dp -outform p => 0
 ok 6 - d -> p
read DSA key
writing DSA key
../../util/shlib_wrap.sh ../../apps/openssl dsa -in dsa-f.p -inform p -out 
dsa-ff.pp -outform p => 0
 ok 7 - p -> p
 ok 8 - comparing orig to p
 ok 9 - comparing p to dp
 ok 10 - comparing p to pp
ok 4 - dsa conversions -- private key
 1..10
../../util/shlib_wrap.sh ../../apps/openssl pkey -in ../../test/testdsa.pem -out 
dsa-fff.p => 0
 ok 1 - initializing
../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-fff.p -inform p -out 
dsa-f.d -outform d => 0
 ok 2 - p -> d
../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-fff.p -inform p -out 
dsa-f.p -outform p => 0
 ok 3 - p -> p
../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.d -inform d -out 
dsa-ff.dd -outform d => 0
 ok 4 - d -> d
../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.p -inform p -out 
dsa-ff.pd -outform d => 0
 ok 5 - p -> d
../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.d -inform d -out 
dsa-ff.dp -outform p => 0
 ok 6 - d -> p
../../util/shlib_wrap.sh ../../apps/openssl pkey -in dsa-f.p -inform p -out 
dsa-ff.pp -outform p => 0
 ok 7 - p -> p
 ok 8 - comparing orig to p
 ok 9 - comparing p to dp
 ok 10 - comparing p to pp
ok 5 - dsa conversions -- private key PKCS\#8
 1..20
 ok 1 - initializing
read DSA key
writing DSA key
../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-fff.p 
-inform p -out msb-f.d -outform d => 0
 ok 2 - p -> d
read DSA key
writing DSA key
../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-fff.p 
-inform p -out msb-f.p -outform p => 0
 ok 3 - p -> p
read DSA key
writing DSA key
../../util/shlib_wrap.sh ../../apps/openssl dsa -pubin -pubout -in msb-fff.p 
-inform p -o

Re: Error building app on RHEL 7 with openssl 1.1.1

[Jan Just Keijser]

Hi Mark,

On 20/07/19 00:13, Mark Richter wrote:

I figured out the variant issue and built, but the tests are failing - see 
https://gist.github.com/sf-mrichter/2c5c653b3800708c1a67ba41e4992129.

Still not sure how to link an app to the new ssl that uses libraries that were 
built with the default.


this is not an OpenSSL, but a Curl issue; I just downloaded curl 7.53.6  
(the latest) and tried compiling and linking it against OpenSSL 1.1.1 ; 
that took quite some effort, as the curl 'configure' script incorrectly 
detects the availability of RAND_egd *and* it assumes that the libraries 
are always present in a library /lib


However, after fixing those errors , I was able to compile & link 
libcurl and curl against OpenSSL 1.1.1 and I was able to verify that 
that curl-build can now do TLS 1.3


Also, note that the default built of curl on RHEL/CentOS 7 uses nss, not 
openssl.

You can contact me for further details.

HTH,

JJK

PS as for the libcurl symbols: as Viktor said, use  'objdump T libcurl.so.4'


-Original Message-
From: openssl-users  On Behalf Of Mark 
Richter
Sent: Friday, July 19, 2019 11:04 AM
To: openssl-users@openssl.org
Subject: RE: Error building app on RHEL 7 with openssl 1.1.1

I've been poking around in the Configurations/* and all the README* files, and 
on the web, and it is not at all clear to me how/where to specify the 
inherit_from and shlib_variant options (probably not the right term, but...) or 
how the resulting libraries are distinguished from the system defaults from the 
app Makefile and resulting application's point of view, particularly w.r.t. how 
our app can use 1.1.1 while libraries we also link will use the system default 
(1.0.2).

Do I copy an existing .conf file to a new name and edit that?  If so, what am I 
editing from/to?  What's the best way to choose the name for the new file?

How do I get config (or Configure) to use the new conf file, or is that automatic?  If it 
is automatic, how does that work for "my" platform?

Assuming I use both, do I need to change my source to make use of the new 
libraries or just my Makefile (and how)?

Our app links to both crypto/ssl and other shared libraries that use the system 
default.  How do I tell my Makefile which one to use for both our app and the 
other libraries which need to use the system default openssl crypto/ssl libs?  
Do I tack the variant at the front or back end of the -L/-l spec lines?  What 
about our -I specs (I guess that a -I for the custom 1.1.1 build is all our app 
needs since we don't care what the other libraries use for compiling)?

As I mentioned, this is all quite new to me.

My apologies if this is as painful for you as it has been for me.

Many, many thanks in advance.  I deeply appreciate all your assistance.

Mark

-Original Message-
From: openssl-users  On Behalf Of Viktor 
Dukhovni
Sent: Thursday, July 18, 2019 10:19 PM
To: openssl-users@openssl.org
Subject: Re: Error building app on RHEL 7 with openssl 1.1.1


On Jul 18, 2019, at 4:34 PM, Mark Richter  wrote:

cc -DLOG_LEVEL=LOG_INFO -Wall -Werror -D__ci_driver__ -D__ci_ul_driver__ -D_GNU_SOURCE 
-DWITH_MCDI_V2 -DWITH_TLS12=0 -DSOLAR_SECURE_VERSION="1.0.3.1020 (3bf2875895d5+ Thu 
Jul 18 13:27:17 PDT 2019)" -Isrc/include -I/opt/openssl1.1/include 
-Isrc/tools/mc-comms -Isrc/tools/mc-comms/include -Isrc/emulators/mbedtls/include 
-I/usr/include/json-c   -g3 -fno-omit-frame-pointer -Isrc/cntlr build/src/cntlr/cntlr.o 
-o build/bin/cntlr  -Lbuild/lib -L/opt/openssl1.1/lib -Wl,-rpath,/opt/openssl1.1/lib 
-lsf_core -lcm -lss -lcrypto  -lpci -lcurl -lpthread -lrt -lssl -luuid -ljson-c
/usr/bin/ld: /opt/openssl1.1/lib/libcrypto.a(dso_dlfcn.o): undefined reference 
to symbol 'dlclose@@GLIBC_2.2.5'
/usr/lib64/libdl.so.2: error adding symbols: DSO missing from command
line
collect2: error: ld returned 1 exit status
make: *** [build/bin/cntlr] Error 1

While dlopen issue can be resolved by including "-ldl" in your linker options.

If you have not managed to get "shlib_variant" working, the above can't 
possibly work because the libcurl you're linking with likely expects the OpenSSL 1.0.2 
ABI.  If the same symbols are found in your the 1.1.1 library in /opt, libcurl will 
likely crash.

If however, the /opt/openssl1.1/lib/lib{ssl,crypto} have the shlib_variant 
SONAMEs and symbol variants, it should work. In that case libcurl will find its 
symbols in something like:

/usr/lib/libssl.1.0.so

While your application can directly use the OpenSSL 1.1.1 API.
If your use of OpenSSL is entirely via libcurl, then the custom OpenSSL will do 
you no good, unless you also built a custom libcurl linked against the custom 
OpenSSL.

Perhaps you're looking for "Nix", or similar where multiple versions of 
dependents and dependencies coëxist more broadly on the same system (though still likely 
not multiple versions of the same library in the same address spaces as with the 
shlib_variant approach), but that's really not RHEL anymore.

--
Vi