Re: Establishing connection errors

[Jason Schultz]

To clarify, I will probably just use the API you suggested to make it more 
simple. Was distracted by my obvious oversight.



From: openssl-users  on behalf of Jason 
Schultz 
Sent: Friday, November 5, 2021 1:59 PM
To: Tomas Mraz ; openssl-users@openssl.org 

Subject: Re: Establishing connection errors

Sorry, accidentally skipped that part, which was sort of important. I think I 
can use the same fix because the part I skipped is the problem:

X509  *cert;
cert = PEM_read_X509(fp, NULL, 0, NULL);
status = X509_STORE_add_cert(trusted_store,cert);

So, I need to this sequence:

X509 *empty_X509;
empty_X509 = X509_new_ex(non_fips_libctx, NULL);
mycert = PEM_read_X509(fp, _X509, 0, NULL);

To set things up correct, with the appropriate library context.

My apologies, thanks for pointing out my small brain.

This could lead to some tricky changes as currently I set up the trust store 
before I know if the user wants FIPS or not. I may just set up two stores, or I 
need to change the order of how I do things.

Thanks,

Jason



From: Tomas Mraz 
Sent: Friday, November 5, 2021 1:52 PM
To: Jason Schultz ; openssl-users@openssl.org 

Subject: Re: Establishing connection errors

On Fri, 2021-11-05 at 13:48 +, Jason Schultz wrote:
> For setting up the trusted store, when the application starts, it
> calls:
>
> ssl_trusted_certs = X509_STORE_new()
>
> ...and then reads all of the certificates in /etc/ssl/certs/ calling

> X509_STORE_add_cert(trusted_store,cert);
>
> ..for each one.

How do you read the certs? They need to be loaded with the appropriate
libctx.

Or you can use for example X509_STORE_load_file_ex() function to load a
file directly with an libctx.

--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

Re: Establishing connection errors

[Jason Schultz]

Sorry, accidentally skipped that part, which was sort of important. I think I 
can use the same fix because the part I skipped is the problem:

X509  *cert;
cert = PEM_read_X509(fp, NULL, 0, NULL);
status = X509_STORE_add_cert(trusted_store,cert);

So, I need to this sequence:

X509 *empty_X509;
empty_X509 = X509_new_ex(non_fips_libctx, NULL);
mycert = PEM_read_X509(fp, _X509, 0, NULL);

To set things up correct, with the appropriate library context.

My apologies, thanks for pointing out my small brain.

This could lead to some tricky changes as currently I set up the trust store 
before I know if the user wants FIPS or not. I may just set up two stores, or I 
need to change the order of how I do things.

Thanks,

Jason



From: Tomas Mraz 
Sent: Friday, November 5, 2021 1:52 PM
To: Jason Schultz ; openssl-users@openssl.org 

Subject: Re: Establishing connection errors

On Fri, 2021-11-05 at 13:48 +, Jason Schultz wrote:
> For setting up the trusted store, when the application starts, it
> calls:
>
> ssl_trusted_certs = X509_STORE_new()
>
> ...and then reads all of the certificates in /etc/ssl/certs/ calling

> X509_STORE_add_cert(trusted_store,cert);
>
> ..for each one.

How do you read the certs? They need to be loaded with the appropriate
libctx.

Or you can use for example X509_STORE_load_file_ex() function to load a
file directly with an libctx.

--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

Re: Establishing connection errors

[Jason Schultz]

Setup of the non_fips_libctx (after help from this list a week or two ago):

non_fips_libctx = OSSL_LIB_CTX_new();
defp = OSSL_PROVIDER_load(non_fips_libctx, "default");

I also call

OSSL_PROVIDER_available(non_fips_libctx, "default")

...to verify this worked. I only load the default provider in the non-FIPS 
non-default library context.

In case you need this info, for the fips library context, I call:

OSSL_LIB_CTX_load_config(fips_libctx, "/usr/local/ssl/openssl-fips.cnf")

With the following relevant info in openssl-fips-cnf:

.include /usr/local/ssl/fipsmodule.cnf

[openssl_init]
providers = provider_sect

# List of providers to load
[provider_sect]
default = default_sect
# The fips section name should match the section name inside the
# included fipsmodule.cnf.
fips = fips_sect
base = base_sect

# If no providers are activated explicitly, the default one is activated 
implicitly.
# See man 7 OSSL_PROVIDER-default for more details.
#
# If you add a section explicitly activating any other provider(s), you most
# probably need to explicitly activate the default provider, otherwise it
# becomes unavailable in openssl.  As a consequence applications depending on
# OpenSSL may not work correctly which could lead to significant system
# problems including inability to remotely access the system.
[default_sect]
# activate = 1

[base_sect]
activate = 1

And in fipsmodule.cnf:

[fips_sect]
activate = 1
conditional-errors = 1
security-checks = 1
module-mac = 
E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9

Also verifying this worked with the following:

OSSL_PROVIDER_available(fips_libctx, "base")
OSSL_PROVIDER_available(fips_libctx, "fips")


For setting up the trusted store, when the application starts, it calls:

ssl_trusted_certs = X509_STORE_new()

...and then reads all of the certificates in /etc/ssl/certs/ calling

X509_STORE_add_cert(trusted_store,cert);

..for each one.

Then, I make the following calls to set up intermediate certs in the trust 
store to be treated as trust-anchors:

param = X509_VERIFY_PARAM_new();
X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_PARTIAL_CHAIN);
X509_STORE_set1_param(ssl_trusted_certs, param);
X509_VERIFY_PARAM_free(param);

Then I set the store for verifying peer certs to this "global" store I created 
above:

status = SSL_CTX_set1_verify_cert_store(ctx,ssl_trusted_certs);

For the sake of completeness, I also call:

status = SSL_CTX_set1_chain_cert_store(ctx, ssl_trusted_certs);

...to ensure OpenSSL has access to the entire store for forming a certificate 
chain to present to the peer in a handshake. My application can act as a client 
and/or a server, and in this case, it's acting as both the client and the 
server, with the same SSL_CTX. Also, this code has always worked with OpenSSL 
1.1.1, which is why I was suspicious of either my library context/provider 
setup, or 3.0.

Let me know if you need more info.

Thanks,

Jason



From: Tomas Mraz 
Sent: Friday, November 5, 2021 1:19 PM
To: Jason Schultz ; openssl-users@openssl.org 

Subject: Re: Establishing connection errors

On Fri, 2021-11-05 at 13:04 +, Jason Schultz wrote:
> I know I've been raising a lot of issues this week, because of
> varying reasons, but I've hit another one that seems like either an
> OpenSSL problem, or something new/different I need to do with OpenSSL
> 3.0 in connection establishment.
>
> To recap, I'm using two non-default library contexts, one for FIPS,
> one for non-FIPS. There is an open issue in github regarding the call
> to SSL_CTX_build_cert_chain(), but since the purpose of that call is
> to have the server not include the root certificate when sending the
> chain, I have left that out of my code for now, in order to continue
> testing. It shouldn't affect what I'm trying to do.
>
> As far as connection set up, based on whether or not the user wants
> FIPS (not using FIPS for this test), I call:
>
> ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());
>
> ...to set up my SSL_CTX. My understanding is that all SSL objects,
> etc., created based on that SSL_CTX will use the appropriate library
> context/providers. So beyond the providers and library context setup
> and using SSL_CTX_new_ex(), I haven't changed any code to establish
> TLS connections. I've tried to establish connections using both RSA
> and ECDSA certificates/keys, self-signed, or a server cert that's
> part of a chain. I'm just establishing a connection to myself, not
> between two systems, just to try to get something working. I'll post
> all of the handshake messages at the end of this message, but here
> are the error messages I get when the client side receives the server
> certificate (in this case it's a self signed RSA cer

Establishing connection errors

[Jason Schultz]

I know I've been raising a lot of issues this week, because of varying reasons, 
but I've hit another one that seems like either an OpenSSL problem, or 
something new/different I need to do with OpenSSL 3.0 in connection 
establishment.

To recap, I'm using two non-default library contexts, one for FIPS, one for 
non-FIPS. There is an open issue in github regarding the call to 
SSL_CTX_build_cert_chain(), but since the purpose of that call is to have the 
server not include the root certificate when sending the chain, I have left 
that out of my code for now, in order to continue testing. It shouldn't affect 
what I'm trying to do.

As far as connection set up, based on whether or not the user wants FIPS (not 
using FIPS for this test), I call:

ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());

...to set up my SSL_CTX. My understanding is that all SSL objects, etc., 
created based on that SSL_CTX will use the appropriate library 
context/providers. So beyond the providers and library context setup and using 
SSL_CTX_new_ex(), I haven't changed any code to establish TLS connections. I've 
tried to establish connections using both RSA and ECDSA certificates/keys, 
self-signed, or a server cert that's part of a chain. I'm just establishing a 
connection to myself, not between two systems, just to try to get something 
working. I'll post all of the handshake messages at the end of this message, 
but here are the error messages I get when the client side receives the server 
certificate (in this case it's a self signed RSA certificate):

211105074132.795:info_cb:SSL_connect error in SSLv3/TLS read server certificate
211105074132.795:SSL_process_hs: SSL_ERROR_SSL on SSL_do_handshake
   Socket: 20  SSL flag: 2  HS role: 0
211105074132.795:SSL_process_hs: SSL_ERROR_SSL ERR_get_error error string:
   error:0308010C:digital envelope routines::unsupported
211105074132.795:SSL_process_hs: SSL_ERROR_SSL ERR_get_error error string:
   error:0372:digital envelope routines::decode error
211105074132.795:SSL_process_hs: SSL_ERROR_SSL ERR_get_error error string:
   error:0372:digital envelope routines::decode error
211105074132.795:SSL_process_hs: SSL_ERROR_SSL ERR_get_error error string:
   error:0372:digital envelope routines::decode error
211105074132.795:SSL_process_hs: SSL_ERROR_SSL ERR_get_error error string:
   error:0372:digital envelope routines::decode error
211105074132.795:SSL_process_hs: SSL_ERROR_SSL ERR_get_error error string:
   error:0580006C:x509 certificate routines::unable to get certs public key

Some of those errors are pretty generic, but when searching the 3.0 source for 
the "unable to get certs public key" error, some familiar functions pop up, for 
example, here:

int X509_self_signed(X509 *cert, int verify_signature)
{
EVP_PKEY *pkey;

if ((pkey = X509_get0_pubkey(cert)) == NULL) { /* handles cert == NULL */
ERR_raise(ERR_LIB_X509, X509_R_UNABLE_TO_GET_CERTS_PUBLIC_KEY);
return -1;
}
if (!ossl_x509v3_cache_extensions(cert))
return -1;
if ((cert->ex_flags & EXFLAG_SS) == 0)
return 0;
if (!verify_signature)
return 1;
return X509_verify(cert, pkey);
}

and here:

/* Copy any missing public key parameters up the chain towards pkey */
int X509_get_pubkey_parameters(EVP_PKEY *pkey, STACK_OF(X509) *chain)
{
EVP_PKEY *ktmp = NULL, *ktmp2;
int i, j;

if (pkey != NULL && !EVP_PKEY_missing_parameters(pkey))
return 1;

for (i = 0; i < sk_X509_num(chain); i++) {
ktmp = X509_get0_pubkey(sk_X509_value(chain, i));
if (ktmp == NULL) {
ERR_raise(ERR_LIB_X509, X509_R_UNABLE_TO_GET_CERTS_PUBLIC_KEY);
return 0;
}
if (!EVP_PKEY_missing_parameters(ktmp))
break;
ktmp = NULL;
}


>From issue #16966, we know the X509_get_pubkey() call can have issues with 
>library contexts. I don't know the internals of OpenSSL enough to know if this 
>is a similar issue.

I can open an Issue in github if Matt, Tomas, or others think it's appropriate.

Thanks,

Jason

PS: Here is the full handshake capture (there are a few logs from my 
application mixed in):

211105074132.786:info_cb:0x89c330 SSL_accept:before SSL initialization
211105074132.786:SSLEvent(4): Matching session table found for port/addr 
2110/10.61.152.77
211105074132.786:info_cb:SSL_accept error in before SSL initialization
211105074132.786:SSL_process_hs: SSL_ERROR_WANT_READ on SSL_do_handshake
Socket: 21  SSL flag: 1  HS role: 1
Socket should be put back on read list to be polled again
211105074132.786:AllocateTcpRecvBuffers(4):call InsertWaitObject() for socket 
20 returned: 0
211105074132.786:info_cb:0x8ae0b0 SSL_connect:before SSL initialization
211105074132.787:msg_cb:0x8ae0b0 >>> TLS 1.0  [length 0005]
211105074132.787:16 03 01 00 d8
211105074132.787:msg_cb:0x8ae0b0 >>> TLS 1.3 Handshake [length 00d8], 
ClientHello
211105074132.787:01 00 00 d4 03 03 56 75 bc 

Re: X509_get_pubkey() in OpenSSL 3.0?

[Jason Schultz]

Unfortunately, the short answer is I can't avoid the problem. The application 
is complicated, and can be thought of as many applications, all of which have 
different needs. I don't think combining a certificate chain into one file 
eliminates the need for all of the calls I'm making, just some of them. I wish 
it were that easy, but I need to do this set up at run time.

I'll see what I can find, and try a few other things to attempt to isolate the 
cause. If I run out of ideas, I'll probably start a new thread since it may get 
more attention.

Thanks for your answers once again.

Jason



From: openssl-users  on behalf of Viktor 
Dukhovni 
Sent: Wednesday, November 3, 2021 9:25 PM
To: openssl-users@openssl.org 
Subject: Re: X509_get_pubkey() in OpenSSL 3.0?

On Wed, Nov 03, 2021 at 08:32:43PM +, Jason Schultz wrote:

> To summarize, at application start time I read in all of the
> certificates in /etc/ssl/certs/ to a trusted store created with
> X509_STORE_new().
>
> When getting ready to "start" a server (again, leaving a lot of
> specifics out to avoid getting bogged down in details), I'm doing the
> processing in the previous messages on this thread. Here are the API
> calls again, with the changes previously discussed:
>
> ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());
> SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);
> SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);
> SSL_CTX_check_private_key(ctx);
> mycert = SSL_CTX_get0_certificate(ctx);
> pkey = X509_get_pubkey(mycert);
>
>  After that's done, I make several OpenSSL calls to get things set up the way 
> I want:
>
> param = X509_VERIFY_PARAM_new();
> X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_PARTIAL_CHAIN);
> X509_STORE_set1_param(ssl_trusted_certs, param);
> X509_VERIFY_PARAM_free(param);
>
> I call these to treat intermediate certs as trust-anchors, so I can
> trust an intermediate certificate; ssl_trusted_certs is the
> aforementioned X509_STORE.

I am puzzled as to you working so hard (writing a bunch of low-level
trust-store and chain construction code) to construct at runtime, what
could be created statically at chain file construction time.  Especially
if you stick with best practice and keep certificate lifetimes
reasonably short (~90 days or less, not years).  The certificate chain
file constructed at the time the certificate is issued should work
unchanged for the lifetime of the certificate, and the server
applications can avoid having to execute any chain construction or
verification code.

Yes, you're asking somewhat "interesting" questions, in that, e.g., I am
not up to speed on all the changes in 3.0.0, and perhaps there are
indeed some issues around legacy SHA1 signatures, but I do suspect that
a more productive use of your time is likely to reconsider the decision
to work at such a low layer.  It may be wiser to find a way to "unask"
the question, i.e. make it moot, by avoiding rather than solving the
problem.

> I'm not clear on if the calls I've added to
> SSL_CTX_get0_certificate(ctx) and X509_get_pubkey(), the latter of
> which was being used before, are what's causing the problem. The
> OpenSSL error queue shows the following on the
> SSL_CTX_build_cert_chain() failure:
>
> 00B741558E7F:error:0308010C:digital envelope routines:(unknown 
> function):unsupported:crypto/evp/evp_fetch.c:346:Global default library 
> context, Algorithm (SHA1 : 96), Properties ()
> 00B741558E7F:error:0372:digital envelope routines:(unknown 
> function):decode error:crypto/x509/x_pubkey.c:444:
> 00B741558E7F:error:0372:digital envelope routines:(unknown 
> function):decode error:crypto/x509/x_pubkey.c:444:
> 00B741558E7F:error:0580006C:x509 certificate routines:(unknown 
> function):unable to get certs public key:crypto/x509/x509_vfy.c:1986:
> 00B741558E7F:error:0A86:SSL routines:(unknown function):certificate 
> verify failed:ssl/ssl_cert.c:905:Verify error:unspecified certificate 
> verification error

I haven't seen these before, your guess is as good as mine.

--
Viktor.

Re: X509_get_pubkey() in OpenSSL 3.0?

[Jason Schultz]

Victor-

Since the only code that's changed from this working with OpenSSL 1.1.1 is the 
code we've been talking about in this thread, it's possible that this is 
causing the problem.

I should explain more what I am doing and how, and also mention that you helped 
me with this when I was trying to sort things out when porting from 1.0.2 to 
1.1.1 over a year ago:

https://www.mail-archive.com/openssl-users@openssl.org/msg87754.html

To summarize, at application start time I read in all of the certificates in 
/etc/ssl/certs/ to a trusted store created with X509_STORE_new().

When getting ready to "start" a server (again, leaving a lot of specifics out 
to avoid getting bogged down in details), I'm doing the processing in the 
previous messages on this thread. Here are the API calls again, with the 
changes previously discussed:


ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());
SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);
SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);
SSL_CTX_check_private_key(ctx);
mycert = SSL_CTX_get0_certificate(ctx);
pkey = X509_get_pubkey(mycert);

 After that's done, I make several OpenSSL calls to get things set up the way I 
want:

param = X509_VERIFY_PARAM_new();
X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_PARTIAL_CHAIN);
X509_STORE_set1_param(ssl_trusted_certs, param);
X509_VERIFY_PARAM_free(param);

I call these to treat intermediate certs as trust-anchors, so I can trust an 
intermediate certificate; ssl_trusted_certs is the aforementioned X509_STORE.

Another call:

status = SSL_CTX_set1_verify_cert_store(ctx,ssl_trusted_certs);

...is to set the store for verifying peer certificates (in the case of client 
authentication) to the entire trusted store.

Then this API:

status = SSL_CTX_set1_chain_cert_store(ctx, ssl_trusted_certs);

...makes sure OpenSSL has access to that entire store to form a full 
certificate chain to a peer in a handshake. Our certificates are stored one per 
file, we do not store a full or partial chains in a single file.

Then, the final two calls before I hit the error:

status = SSL_CTX_set_mode(ctx, SSL_MODE_NO_AUTO_CHAIN);
status = SSL_CTX_build_cert_chain(ctx, SSL_BUILD_CHAIN_FLAG_NO_ROOT);

The purpose of the first is to allow self signed certificates to be used by the 
server. (This is only for testing purposes, but in this particular case where 
SSL_CTX_build_cert_chain() is throwing errors, I am using a self-signed 
certificate.) The second is to tell OpenSSL to (even though we have access to 
the entire chain, including the root) not include the root certificate when 
building the chain to send during a handshake.

I'm not clear on if the calls I've added to SSL_CTX_get0_certificate(ctx) and 
X509_get_pubkey(), the latter of which was being used before, are what's 
causing the problem. The OpenSSL error queue shows the following on the 
SSL_CTX_build_cert_chain() failure:

00B741558E7F:error:0308010C:digital envelope routines:(unknown 
function):unsupported:crypto/evp/evp_fetch.c:346:Global default library 
context, Algorithm (SHA1 : 96), Properties ()
00B741558E7F:error:0372:digital envelope routines:(unknown 
function):decode error:crypto/x509/x_pubkey.c:444:
00B741558E7F:error:0372:digital envelope routines:(unknown 
function):decode error:crypto/x509/x_pubkey.c:444:
00B741558E7F:error:0580006C:x509 certificate routines:(unknown 
function):unable to get certs public key:crypto/x509/x509_vfy.c:1986:
00B741558E7F:error:0A86:SSL routines:(unknown function):certificate 
verify failed:ssl/ssl_cert.c:905:Verify error:unspecified certificate 
verification error

I'm using the non-FIPS library context in this case, and the first error makes 
me think I need to load the legacy provider for my non FIPS library context if 
there are any SHA1 certificates in the X509_store? The one I am using for the 
server cert is not SHA1, but there are probably some SHA1 certs in 
/etc/ssl/certs/. I don't see errors when adding those certificates to the store 
though. I also don't see SHA1 in the list of algorithms provided by the legacy 
provider in the Wiki.

The next two errors are the same ones that I was getting when attempting to 
call X509_get_pubkey() before changing the code to get it to work, which is 
interesting.

Maybe this is what you were trying to explain in your email, but I'm not 
understanding?

Jason



From: openssl-users  on behalf of Viktor 
Dukhovni 
Sent: Wednesday, November 3, 2021 4:47 PM
To: openssl-users@openssl.org 
Subject: Re: X509_get_pubkey() in OpenSSL 3.0?

On Wed, Nov 03, 2021 at 12:38:51PM +0000, Jason Schultz wrote:

> In any case, things appear to be working now, but I'm hitting an issue
> later on when calling SSL_CTX_build_cert_chain(). I working on
> debugging that, I may have to start yet another thread later.

Your mistake is 

Re: X509_get_pubkey() in OpenSSL 3.0?

[Jason Schultz]

Victor-

Thanks for the info. I think I'm going to use:

X509 *SSL_CTX_get0_certificate(const SSL_CTX *ctx)
EVP_PKEY pkey = X509_get_pubkey(cert);

(also suggested by Selva) The reason is, and to answer some of your questions, 
all of this is taking place well before any handshakes, so the SSL object 
doesn't come into play at this point. We do allow users to specify both an RSA 
and EC cert/key pair, but the order in which we set them up will work since 
these functions operate on the last one to load. If the certificate loads, 
that's great, but we also tell our users if they specified an RSA cert if it's 
really a EC cert, etc. We also do some checks on the certificate, like if it's 
expired, or not valid yet; that's why I chose SSL_CTX_get0_certificate() above, 
so I have the X509 certificate object to make those checks, with 
X509_get0_notBefore(), etc.

In any case, things appear to be working now, but I'm hitting an issue later on 
when calling SSL_CTX_build_cert_chain(). I working on debugging that, I may 
have to start yet another thread later.

Thanks,

Jason


From: openssl-users  on behalf of Viktor 
Dukhovni 
Sent: Tuesday, November 2, 2021 9:01 PM
To: openssl-users@openssl.org 
Subject: Re: X509_get_pubkey() in OpenSSL 3.0?

On Tue, Nov 02, 2021 at 08:28:01PM +, Jason Schultz wrote:
> Victor-
>
> I can't seem to find any documentation on SSL_CTX_get0_privatekey(),
> but by the name of it, it sounds like it's getting the private key;
> I'm trying to get the public key.

It does appear to be "under-documented" (i.e. not at all), perhaps
that could be addressed.  Note that you can get a public key from
the private key.

> That said, I should probably explain more of why I'm doing what I'm
> doing, because there may be an easier way all together. Basically, we
> allow configuring RSA or EC certificates/keys, and I want to get the
> public key so I can check the type of key with a call to:
>
>  EVP_PKEY_base_id(pubkey);

Which you can equally get from the private key, but there's also:

SSL_CTX_get0_certificate(sadly also "under-documented")

which means that you certainly don't need to read the PEM file again.

> So maybe there's a better way? After I call:
>
>  SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);
>
> Is there an API I can call passing the ctx that will tell me what type
> of certificate is in use for that ctx? Or something else along those
> lines?

Also once you have an (SSL *) handle you can call SSL_get_certificate(3)
which is documented, and proceed from there.

> It's very possible I'm overcomplicating things with the fopen(),
> PEM_read_X509(), X509_get_pubkey() sequence, so any suggestions on how
> to better accomplish this verification are welcome.

Yes.  Query the data you already have in memory.

Note that a context can be configured with *both* an RSA certificate
chain *and* an EC certificate chain.  The above functions return the one
most recently loaded, but a handshake with a peer may select one of
the other chains.

Most applications only load keys for just one algorithm, but in general
more may be present.

It is surprising that you care which algorithm is in cert/keys.  So
long as it loads, why does it matter?

If you want to log data for each handshake, at that point you can use
SSL_get_certificate(3) for the cert actually selected by this handshake
on the local end:


https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_misc.c#L950-L953

--
Viktor.

Re: X509_get_pubkey() in OpenSSL 3.0?

[Jason Schultz]

Victor-

I can't seem to find any documentation on SSL_CTX_get0_privatekey(), but by the 
name of it, it sounds like it's getting the private key; I'm trying to get the 
public key.

That said, I should probably explain more of why I'm doing what I'm doing, 
because there may be an easier way all together. Basically, we allow 
configuring RSA or EC certificates/keys, and I want to get the public key so I 
can check the type of key with a call to:

 EVP_PKEY_base_id(pubkey);

I check the return value from that against, for example, EVP_PKEY_EC to verify 
an EC certificate was configured, as opposed to RSA. That's the gist of it, 
without going into too many application specific details.

So maybe there's a better way? After I call:

 SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);

Is there an API I can call passing the ctx that will tell me what type of 
certificate is in use for that ctx? Or something else along those lines?

It's very possible I'm overcomplicating things with the fopen(), 
PEM_read_X509(), X509_get_pubkey() sequence, so any suggestions on how to 
better accomplish this verification are welcome.

Regards,

Jason


> I thought I should start a new thread since this question was buried in my 
> "FIPS" thread and I dont' think it has anything to do with FIPS and OpenSSL 
> providers. I'm hitting another problem that I think is related to the 
> migration to OpenSSL 3.0, as this code works with OpenSSL 1.1.1 (and 1.0.2 
> before it). When looking at the documentation pages for 1.1.1 vs 3.0, I'm not 
> seeing any differences between the OpenSSL APIs I'm calling in the 2 
> different release levels.
>
> Here is the sequence, I'm basically setting up my certificate and private 
> key, both in PEM format, for the server, then I need to extract some 
> information from them:
>
> ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());
> SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);
> SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);
> SSL_CTX_check_private_key(ctx);
> fp = fopen(, "r");
> mycert = PEM_read_X509(fp, NULL, 0, NULL);
> pkey = X509_get_pubkey(mycert);

Without addressing the question of why you're unable to get the public
key handle from the certificate, why not just:

 pkey = SSL_CTX_get0_privatekey(ctx){

and skip reading the cert again?

--
Viktor.

Re: X509_get_pubkey() in OpenSSL 3.0?

[Jason Schultz]

Sorry, I send this before finishing the Aside. I ended up calling these APIs:

DECODER_ctx = OSSL_DECODER_CTX_new_for_pkey(EVP_PKEY **pkey,
   const char *input_type,
   const char *input_struct,
   const char *keytype, int selection,
   OSSL_LIB_CTX *libctx, const char *propquery);

OSSL_DECODER_from_fp(dctx, fp);

SSL_CTX_set0_tmp_dh_pkey(ctx, dh_pkey);

To get the DH set up. I can't test this until I get past the intial problem, 
but I tried using the above functions for getting the public key from the 
certificate file, and the problem is still the same.

An example of a certificate I'm using that is failing is below:

# openssl x509 -noout -text -in /etc/ssl/certs/servercert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 286 (0x11e)
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = US, ST = PA, L = City, O = Example, OU = Networking, CN = 
JCS-EC-CA, emailAddress = joe@example.com
Validity
Not Before: Mar  3 18:15:13 2021 GMT
Not After : Nov 28 18:15:13 2023 GMT
Subject: C = US, ST = PA, L = City, O = Example, OU = Networking, CN = 
JCS-EC-server, emailAddress = joe1@example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:c2:1a:0c:76:dc:d9:b9:3d:49:f6:60:72:fa:18:
c2:e9:31:bc:64:42:24:02:61:06:80:e0:69:2c:5a:
c3:0e:e4:09:ce:79:64:f8:fd:b0:65:63:e1:e9:35:
34:ff:48:58:aa:72:21:20:c1:ce:f2:7a:90:2b:c7:
e7:b7:76:ad:88
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
EF:1E:DA:81:3A:43:AA:12:E4:53:B6:4B:E5:A0:3D:AB:CD:30:6B:2F
X509v3 Authority Key Identifier:
60:A2:DC:A3:7A:FB:78:A9:92:5F:88:B5:1A:03:65:9C:F4:10:CD:38
Signature Algorithm: ecdsa-with-SHA256
Signature Value:
30:46:02:21:00:dc:fc:69:9c:a6:54:e1:fa:3c:e7:65:9f:cc:
d5:a4:a2:3a:a7:b1:37:79:60:d0:61:9e:87:15:79:09:0f:34:
14:02:21:00:fd:29:34:bf:bb:c5:02:0d:9a:04:44:6e:94:22:
52:b4:0e:ab:1f:3d:15:5c:07:47:eb:76:68:80:f9:72:96:f6



From: openssl-users  on behalf of Jason 
Schultz 
Sent: Tuesday, November 2, 2021 7:42 PM
To: openssl-users@openssl.org 
Subject: X509_get_pubkey() in OpenSSL 3.0?

I thought I should start a new thread since this question was buried in my 
"FIPS" thread and I dont' think it has anything to do with FIPS and OpenSSL 
providers. I'm hitting another problem that I think is related to the migration 
to OpenSSL 3.0, as this code works with OpenSSL 1.1.1 (and 1.0.2 before it). 
When looking at the documentation pages for 1.1.1 vs 3.0, I'm not seeing any 
differences between the OpenSSL APIs I'm calling in the 2 different release 
levels.

Here is the sequence, I'm basically setting up my certificate and private key, 
both in PEM format, for the server, then I need to extract some information 
from them:

ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());
SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);
SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);
SSL_CTX_check_private_key(ctx);
fp = fopen(, "r");
mycert = PEM_read_X509(fp, NULL, 0, NULL);
pkey = X509_get_pubkey(mycert);

All functions return good statuses or non-NULL pointers until the last one, 
X509_get_pubkey() returns NULL. I have tried this with RSA and Elliptic Curve 
cert/key pairs. I have tried with pairs created with OpenSSL 1.1.1 as well as 
3.0 via the command line.

This seems like a pretty straightforward operation, but it appears that 
key->pkey is NULL in the code below:

EVP_PKEY *X509_PUBKEY_get0(const X509_PUBKEY *key)
{
if (key == NULL) {
ERR_raise(ERR_LIB_X509, ERR_R_PASSED_NULL_PARAMETER);
return NULL;
}

if (key->pkey == NULL) {
/* We failed to decode the key when we loaded it, or it was never set */
ERR_raise(ERR_LIB_EVP, EVP_R_DECODE_ERROR);
return NULL;
}

return key->pkey;
}

I got to this code from the error information I dumped from OpenSSL:

00079FF8647F:error:0372:digital envelope routines:(unknown 
function):decode error:crypto/x509/x_pubkey.c:444:

I can paste certificates if anyone thinks it will help, but I've tried several 
types of cert/key pairs, and using the command line to do "openssl x509 
-pubkey..." displays the public key just fine with the certificate file in 
question.

Here is an example of the openssl command line to create one of t

X509_get_pubkey() in OpenSSL 3.0?

[Jason Schultz]

I thought I should start a new thread since this question was buried in my 
"FIPS" thread and I dont' think it has anything to do with FIPS and OpenSSL 
providers. I'm hitting another problem that I think is related to the migration 
to OpenSSL 3.0, as this code works with OpenSSL 1.1.1 (and 1.0.2 before it). 
When looking at the documentation pages for 1.1.1 vs 3.0, I'm not seeing any 
differences between the OpenSSL APIs I'm calling in the 2 different release 
levels.

Here is the sequence, I'm basically setting up my certificate and private key, 
both in PEM format, for the server, then I need to extract some information 
from them:

ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());
SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);
SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);
SSL_CTX_check_private_key(ctx);
fp = fopen(, "r");
mycert = PEM_read_X509(fp, NULL, 0, NULL);
pkey = X509_get_pubkey(mycert);

All functions return good statuses or non-NULL pointers until the last one, 
X509_get_pubkey() returns NULL. I have tried this with RSA and Elliptic Curve 
cert/key pairs. I have tried with pairs created with OpenSSL 1.1.1 as well as 
3.0 via the command line.

This seems like a pretty straightforward operation, but it appears that 
key->pkey is NULL in the code below:

EVP_PKEY *X509_PUBKEY_get0(const X509_PUBKEY *key)
{
if (key == NULL) {
ERR_raise(ERR_LIB_X509, ERR_R_PASSED_NULL_PARAMETER);
return NULL;
}

if (key->pkey == NULL) {
/* We failed to decode the key when we loaded it, or it was never set */
ERR_raise(ERR_LIB_EVP, EVP_R_DECODE_ERROR);
return NULL;
}

return key->pkey;
}

I got to this code from the error information I dumped from OpenSSL:

00079FF8647F:error:0372:digital envelope routines:(unknown 
function):decode error:crypto/x509/x_pubkey.c:444:

I can paste certificates if anyone thinks it will help, but I've tried several 
types of cert/key pairs, and using the command line to do "openssl x509 
-pubkey..." displays the public key just fine with the certificate file in 
question.

Here is an example of the openssl command line to create one of the cert/key 
pairs that hits this error:

openssl req -new -x509 -nodes -newkey ec:<(openssl ecparam -name secp384r1) 
-keyout threecert.key -out threecert.crt -days 365

Aside: While I was waiting for an answer on this, I started working on removing 
some of the deprecated functions in my code, for example, PEM_read_DHparams(). 
I ended up finding the DECODER functions and plan on doing something like:


Thanks,

Jason

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Thanks to everyone for the help so far. I think I have things set up correctly 
as far as FIPS, providers, and library contexts. I'm hitting another problem 
that I think is related to the migration to OpenSSL 3.0, as this code works 
with OpenSSL 1.1.1 (and 1.0.2 before it). When looking at the documentation 
pages for 1.1.1 vs 3.0, I'm not seeing any differences between the OpenSSL APIs 
I'm calling in the 2 different release levels.

Here is the sequence, I'm basically setting up my certificate and private key, 
both in PEM format, for the server, then I need to extract some information 
from them:

ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());
SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);
SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);
SSL_CTX_check_private_key(ctx);
fp = fopen(, "r");
mycert = PEM_read_X509(fp, NULL, 0, NULL);
pkey = X509_get_pubkey(mycert);

All functions return good statuses or non-NULL pointers until the last one, 
X509_get_pubkey() returns NULL. I have tried this with RSA and Elliptic Curve 
cert/key pairs. I have tried with pairs created with OpenSSL 1.1.1 as well as 
3.0 via the command line.

This seems like a pretty straightforward operation, but it appears that 
key->pkey is NULL in the code below:

EVP_PKEY *X509_PUBKEY_get0(const X509_PUBKEY *key)
{
if (key == NULL) {
ERR_raise(ERR_LIB_X509, ERR_R_PASSED_NULL_PARAMETER);
return NULL;
}

if (key->pkey == NULL) {
/* We failed to decode the key when we loaded it, or it was never set */
ERR_raise(ERR_LIB_EVP, EVP_R_DECODE_ERROR);
return NULL;
}

return key->pkey;
}

I got to this code from the error information I dumped from OpenSSL:

00079FF8647F:error:0372:digital envelope routines:(unknown 
function):decode error:crypto/x509/x_pubkey.c:444:

I can paste certificates if anyone thinks it will help, but I've tried several 
types of cert/key pairs, and using the command line to do "openssl x509 
-pubkey..." displays the public key just fine with the certificate file in 
question.

Here is an example of the openssl command line to create one of the cert/key 
pairs that hits this error:

openssl req -new -x509 -nodes -newkey ec:<(openssl ecparam -name secp384r1) 
-keyout threecert.key -out threecert.crt -days 365

I kept this on the same "FIPS OpenSSL 3.0" thread because I'm not 100% sure 
it's unrelated.

What am I missing here?

Thanks,

Jason



From: Matt Caswell 
Sent: Thursday, October 28, 2021 6:03 PM
To: Jason Schultz ; Dr Paul Dale ; 
openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0 FIPS questions



On 28/10/2021 18:33, Jason Schultz wrote:
> Thanks Matt. I think I have what I need as far as loading providers. I
> also did the test you suggested with EVP_MD_fetch() and things failed as
> expected, the fetch did not work.
>
> One other question on providers, given how I load everything, it seems
> like before application exit, the cleanup should be the following:
>
>  OSSL_LIB_CTX_free(fips_libctx);
>  OSSL_LIB_CTX_free(non_fips_libctx);
>  OSSL_PROVIDER_unload(defp);

Yes, but I would recommend unloading the default provider before freeing
the libctx it is associated with. Otherwise bad things might happen.

>
> Since I didn't "explicitly" load the fips and base providers with API
> calls, I only need to unlead the default provider, as well as free both
> library contexts.

Correct.

>
> Also, when I did try to unload the fips and base providers, the call to
> OSSL_PROVIDER_unload() hung, with the following backtrace:

Yeah. Don't do that. :-)

Matt

>
> #1  0x7fb37f51d709 in CRYPTO_THREAD_read_lock () from
> /lib64/libcrypto.so.3
> #2  0x7fb37f50c068 in ossl_lib_ctx_get_data () from
> /lib64/libcrypto.so.3
> #3  0x7fb37f519482 in get_provider_store () from /lib64/libcrypto.so.3
> #4  0x7fb37f519af9 in provider_deactivate () from /lib64/libcrypto.so.3
> #5  0x7fb37f51b813 in ossl_provider_deactivate () from
> /lib64/libcrypto.so.3
> #6  0x7fb37f518399 in OSSL_PROVIDER_unload () from /lib64/libcrypto.so.3
>
> Thanks,
>
> Jason
>
>
> --------
> *From:* Matt Caswell 
> *Sent:* Thursday, October 28, 2021 2:00 PM
> *To:* Jason Schultz ; Dr Paul Dale
> ; openssl-users@openssl.org 
> *Subject:* Re: OpenSSL 3.0 FIPS questions
>
>
> On 28/10/2021 14:49, Jason Schultz wrote:
>> A call to OSSL_PROVIDER_available() says the "default" provider is
>> available;  however, I'm wondering if I should be loading the default
>> provider via *load_config() as well? I would have to uncomment the
>> "activate = 1" in the default section of my config though.
>
> This

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Thanks Matt. I think I have what I need as far as loading providers. I also did 
the test you suggested with EVP_MD_fetch() and things failed as expected, the 
fetch did not work.

One other question on providers, given how I load everything, it seems like 
before application exit, the cleanup should be the following:

OSSL_LIB_CTX_free(fips_libctx);
OSSL_LIB_CTX_free(non_fips_libctx);
OSSL_PROVIDER_unload(defp);

Since I didn't "explicitly" load the fips and base providers with API calls, I 
only need to unlead the default provider, as well as free both library contexts.

Also, when I did try to unload the fips and base providers, the call to 
OSSL_PROVIDER_unload() hung, with the following backtrace:

#1  0x7fb37f51d709 in CRYPTO_THREAD_read_lock () from /lib64/libcrypto.so.3
#2  0x7fb37f50c068 in ossl_lib_ctx_get_data () from /lib64/libcrypto.so.3
#3  0x7fb37f519482 in get_provider_store () from /lib64/libcrypto.so.3
#4  0x7fb37f519af9 in provider_deactivate () from /lib64/libcrypto.so.3
#5  0x7fb37f51b813 in ossl_provider_deactivate () from /lib64/libcrypto.so.3
#6  0x7fb37f518399 in OSSL_PROVIDER_unload () from /lib64/libcrypto.so.3

Thanks,

Jason



From: Matt Caswell 
Sent: Thursday, October 28, 2021 2:00 PM
To: Jason Schultz ; Dr Paul Dale ; 
openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0 FIPS questions



On 28/10/2021 14:49, Jason Schultz wrote:
> A call to OSSL_PROVIDER_available() says the "default" provider is
> available;  however, I'm wondering if I should be loading the default
> provider via *load_config() as well? I would have to uncomment the
> "activate = 1" in the default section of my config though.

This is entirely a matter of personal taste. It makes no difference
functionally whether you load a provider via OSSL_PROVIDER_load()
directly, or whether you do it via the config file. Obviously if you do
it via a config file it gives you the ability to modify what providers
get loaded later without having to recompile.

If you decided to do it via config then you probably want *2* different
config files. One for the fips libctx and one for the non-fips libctx.


>
> I also still have this in my code:
>
>  /* Disallow falling back to the default library context */
>  nullp = OSSL_PROVIDER_load(NULL, "null");
>
> But not sure it's having any affect?

You could attempt to test it by attempting to fetch an algorithm. We
would expect it to fail if it is working as expected. E.g.

EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", NULL);
if (md != NULL) {
 /* Should not happen! The null provider should prevent this */
}


>
> I do know that later in my application, both in "FIPS" or "non-FIPS"
> mode, I can  create an SSL_CTX with SSL_CTX_new_ex(). I also
> successfully call several APIs using both the fips_libctx or the
> non_fips_libctx, for example:
>
> status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);
>
> status = SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);
>
> status = SSL_CTX_check_private_key(ctx);
>
>
> All return successfully. So I think what I have between configuration
> files and API calls accomplishes what I need to. Would anyone reading
> this agree?

It sounds correct from what you have described.

Matt

>
> I'm running into another issue that I need to troubleshoot a bit more
> before I add too much information and too many questions to a single
> message.
>
> Thanks to everyone for their help with this, things are starting to make
> more sense now.
>
>
>
> 
> *From:* Matt Caswell 
> *Sent:* Thursday, October 28, 2021 7:39 AM
> *To:* Jason Schultz ; Dr Paul Dale
> ; openssl-users@openssl.org 
> *Subject:* Re: OpenSSL 3.0 FIPS questions
>
>
> On 27/10/2021 17:28, Jason Schultz wrote:
>> With these config files and the code above, the
>> OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the
>> messages from the ERR_print_errors_fp() call:
>>
>> 2097C692B57F:error:1C8000D5:Provider routines:(unknown
>> function):missing config data:providers/fips/self_test.c:289:
>> 2097C692B57F:error:1C8000E0:Provider routines:(unknown
>> function):fips module entering error state:providers/fips/self_test.c:387:
>> 2097C692B57F:error:1C8000D8:Provider routines:(unknown
>> function):self test post failure:providers/fips/fipsprov.c:706:
>> 2097C692B57F:error:078C0105:common libcrypto routines:(unknown
>> function):init fail:crypto/provider_core.c:903:name=fips
>
>
> This tells us that the fips provider has successfully loaded, but then
> subsequently failed during its self-test because it cannot find its

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Thanks Matt. I actually had this working (loading the fips_libctx using the 
*load_config() API) but I was hitting other issues and thought I was doing 
something wrong (more on that later).

So to review, I have my own config file, /usr/local/ssl/openssl-fips, with the 
relevant contents(some comments snipped):

.include /usr/local/ssl/fipsmodule.cnf

[openssl_init]
providers = provider_sect

# List of providers to load
[provider_sect]
default = default_sect
# The fips section name should match the section name inside the
# included fipsmodule.cnf.
fips = fips_sect
base = base_sect

[default_sect]
# activate = 1

[base_sect]
activate = 1

And then fipsmodule.cnf contains:

[fips_sect]
activate = 1
conditional-errors = 1
security-checks = 1
module-mac = 
E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9

By activating the fips and base providers via config, my application then calls:

OSSL_LIB_CTX_load_config(fips_libctx, "/usr/local/ssl/openssl-fips.cnf");

Which loads the "fips" and "base" providers in the fips_libctx, which I verify 
with:

OSSL_PROVIDER_available(fips_libctx, "fips");
and
OSSL_PROVIDER_available(fips_libctx, "base")

...and both are available.

However, remember I am trying to create two non-default library contexts (from 
earlier code):

fips_libctx = OSSL_LIB_CTX_new();
non_fips_libctx = OSSL_LIB_CTX_new();

Again, I think I have what I need for the fibs_libctx. For the non_fips_libctx, 
I'm calling:

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
nullp = OSSL_PROVIDER_load(NULL, "null");

A call to OSSL_PROVIDER_available() says the "default" provider is available;  
however, I'm wondering if I should be loading the default provider via 
*load_config() as well? I would have to uncomment the "activate = 1" in the 
default section of my config though.

I also still have this in my code:

/* Disallow falling back to the default library context */

nullp = OSSL_PROVIDER_load(NULL, "null");

But not sure it's having any affect?

I do know that later in my application, both in "FIPS" or "non-FIPS" mode, I 
can  create an SSL_CTX with SSL_CTX_new_ex(). I also successfully call several 
APIs using both the fips_libctx or the non_fips_libctx, for example:


status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);

status = SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM);

status = SSL_CTX_check_private_key(ctx);

All return successfully. So I think what I have between configuration files and 
API calls accomplishes what I need to. Would anyone reading this agree?

I'm running into another issue that I need to troubleshoot a bit more before I 
add too much information and too many questions to a single message.

Thanks to everyone for their help with this, things are starting to make more 
sense now.




From: Matt Caswell 
Sent: Thursday, October 28, 2021 7:39 AM
To: Jason Schultz ; Dr Paul Dale ; 
openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0 FIPS questions



On 27/10/2021 17:28, Jason Schultz wrote:
> With these config files and the code above, the
> OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the
> messages from the ERR_print_errors_fp() call:
>
> 2097C692B57F:error:1C8000D5:Provider routines:(unknown
> function):missing config data:providers/fips/self_test.c:289:
> 2097C692B57F:error:1C8000E0:Provider routines:(unknown
> function):fips module entering error state:providers/fips/self_test.c:387:
> 2097C692B57F:error:1C8000D8:Provider routines:(unknown
> function):self test post failure:providers/fips/fipsprov.c:706:
> 2097C692B57F:error:078C0105:common libcrypto routines:(unknown
> function):init fail:crypto/provider_core.c:903:name=fips


This tells us that the fips provider has successfully loaded, but then
subsequently failed during its self-test because it cannot find its
config data.

I can see that you have created a separate libctx for fips. However
automatic loading of the config file only works for the *default*
libctx. If you create your own one then you need to explicitly load the
config file:

if (!OSSL_LIB_CTX_load_config(fips_libtx, "/usr/local/ssl/openssl.cnf")) {
 /* error handling */
}

Actually if you do this then you should not need to call
OSSL_PROVIDER_load() explicitly to load the fips provider since you
already activated it in the config file. You can either drop the
explicit call to OSSL_PROVIDER_load() for the fips provider, or remove
the "activate = 1" line in "fips_sect" in fipsmodule.cnf. This is just a
minor optimisation though. Doing both is redundant but harmless. You
could also load the base provider via config if you wanted to.

Matt

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Sorry, I meant to include the config information in my previous email. I should 
probably go back to the beginning, I've been trying a lot of different 
combinations without success, so unwinding to the beginning and taking one step 
at a time is probably appropriate. Since I want the FIPS changes limited to my 
application only, this is based on the response from Dr. Paul Dale earlier in 
the thread, the first approach he recommended, so the application code looks 
like this:

fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
if (fipsp == NULL)
  {
// error handling
 }

basep = OSSL_PROVIDER_load(fips_libctx, "base"); /* can't load keys without 
this */
if (basep == NULL)
  {
/* error handling */
   }

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
if (defp == NULL)
  {
/* error handling */

  }

Since I'm back to not using my own config file, this is the relevant content in 
/usr/local/ssl/openssl.cnf. Again, from Dr. Paul Dale's advice of needing a 
FIPS section, and not needing base or default sections:

openssl_conf = openssl_init

.include /usr/local/ssl/fipsmodule.cnf

[openssl_init]
providers = provider_sect

# List of providers to load
[provider_sect]
default = default_sect
# The fips section name should match the section name inside the
# included fipsmodule.cnf.
fips = fips_sect

[default_sect]
# activate = 1

Here is the /usr/local/ssl/fipsmodule.cnf file:

[fips_sect]
activate = 1
conditional-errors = 1
security-checks = 1
module-mac = 
E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9

With these config files and the code above, the OSSL_PROVIDER_load(fips_libctx, 
"fips") call fails. Here are the messages from the ERR_print_errors_fp() call:

2097C692B57F:error:1C8000D5:Provider routines:(unknown function):missing 
config data:providers/fips/self_test.c:289:
2097C692B57F:error:1C8000E0:Provider routines:(unknown function):fips 
module entering error state:providers/fips/self_test.c:387:
2097C692B57F:error:1C8000D8:Provider routines:(unknown function):self test 
post failure:providers/fips/fipsprov.c:706:
2097C692B57F:error:078C0105:common libcrypto routines:(unknown 
function):init fail:crypto/provider_core.c:903:name=fips

So this does seem like I have something wrong as far as setup/install or 
configuration. I'm not sure if it's something in the config files above, or 
something with my application being able to find the fips.so, which was also 
mentioned. The code above in self_test.c that's throwing the error looks like 
the st parameter to SELF_TESET_post() is NULL, but I'm not sure what the actual 
problem is. The self test isn't set up to run correctly, the self test failed, 
maybe both, or maybe something else?

One of the links from Matt included a function  
OSSL_PROVIDER_set_default_search_path(). I'm wondering if that's needed since I 
don't have any environment variables set up? I'm not sure what the default 
search path is.

Jason



From: Matt Caswell 
Sent: Wednesday, October 27, 2021 10:34 AM
To: Jason Schultz ; Dr Paul Dale ; 
openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0 FIPS questions



On 26/10/2021 20:17, Jason Schultz wrote:
> Thanks for all of the help so far. Unfortunately, I'm still struggling
> with this. There could be a number of issues, starting with the
> installation of OpenSSL. I basically followed the documentation and did
> the following:
>
> ./Configure enable-fips
>
> make
>
> make test
>
> make install
>
>
> The "make test" actually fails, but I did not troubleshoot as it seems
> like a lot of systems have issues here. But I know the .so produced when
> I build my application is linking to the correct OpenSSL libraries
> (libssl.so.3 and libcrypto.so.3). Checking the OpenSSL version shows 3.0.
>
> I've tried a number of combinations trying to make this work, starting
> with the code from Dr. Paul Dale in a previous message:
>
>  fips_libctx = OSSL_LIB_CTX_new();
>  if (!fips_libctx)
>  // error handling
>
>  non_fips_libctx = OSSL_LIB_CTX_new();
>  if (!non_fips_libctx)
>  // error handling
>
>  fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
>  if (fipsp == NULL)
>{
>  /* error handling */
>}
>
>  basep = OSSL_PROVIDER_load(fips_libctx, "base");
>  if (basep == NULL)
>{
>  /* error handling */
>}
>
>  defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
>  if (defp == NULL)
>{
>  /* error handling */
>}
>
>  /* Disallow falling back to the default library context */
>  nullp = OSSL_PROVIDER_load(NULL, &q

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Ah, OK. Yes, I am running on the same machine. Thanks for clarifying.



From: Kory Hamzeh 
Sent: Tuesday, October 26, 2021 9:15 PM
To: Jason Schultz 
Cc: Dr Paul Dale ; openssl-users@openssl.org 

Subject: Re: OpenSSL 3.0 FIPS questions

Actually, if you are running on the same machine that you built OpenSSL, you 
are fine. I cross-compile and have to do a fipsinstall each time. My apologies.


On Oct 26, 2021, at 12:17 PM, Jason Schultz 
mailto:jetso...@hotmail.com>> wrote:

Thanks for all of the help so far. Unfortunately, I'm still struggling with 
this. There could be a number of issues, starting with the installation of 
OpenSSL. I basically followed the documentation and did the following:

./Configure enable-fips
make
make test
make install

The "make test" actually fails, but I did not troubleshoot as it seems like a 
lot of systems have issues here. But I know the .so produced when I build my 
application is linking to the correct OpenSSL libraries (libssl.so.3 and 
libcrypto.so.3). Checking the OpenSSL version shows 3.0.

I've tried a number of combinations trying to make this work, starting with the 
code from Dr. Paul Dale in a previous message:

fips_libctx = OSSL_LIB_CTX_new();
if (!fips_libctx)
// error handling

non_fips_libctx = OSSL_LIB_CTX_new();
if (!non_fips_libctx)
// error handling

fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
if (fipsp == NULL)
  {
/* error handling */
  }


basep = OSSL_PROVIDER_load(fips_libctx, "base");
if (basep == NULL)
  {
/* error handling */
  }

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
if (defp == NULL)
  {
/* error handling */
  }

/* Disallow falling back to the default library context */

nullp = OSSL_PROVIDER_load(NULL, "null");
if (nullp == NULL)
  {
/*error handling */
  }

With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. If 
I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns NULL, 
which is probably expected given the fips provider didn't load.

At that point, I wasn't sure if my application was using the (correct) config 
file in /usr/local/ssl/. I don't have any environment variables set up, and 
would prefer not to have to set any to get this to work. So I changed the 
provider load for FIPS to use OSSL_LIB_CTX_load_config():

if (!OSSL_LIB_CTX_load_config(fips_libctx, 
"/usr/local/ssl/openssl-fips.cnf"))
  // error handling

This seems to work load the provider; however, there are two separate problems 
at this point. If FIPS is enabled by my application creating the SSL_CTX with  
the FIPS library context fails, returning NULL.

If FIPS is turned OFF by my application, creating an SSL_CTX with the 
non_fips_libctx  is successful, but later calling X509_get_pubkey() returns 
NULL, implying maybe something is wrong with the non_fips_libctx as well.

I've tried other combinations, but at this point I'm just guessing. Is there 
anything obvious I could be missing and I should be checking?

Thanks,

Jason



From: Dr Paul Dale mailto:pa...@openssl.org>>
Sent: Monday, October 25, 2021 9:37 PM
To: Jason Schultz mailto:jetso...@hotmail.com>>; 
openssl-users@openssl.org<mailto:openssl-users@openssl.org> 
mailto:openssl-users@openssl.org>>
Subject: Re: OpenSSL 3.0 FIPS questions

It was meant for the second method only.  The first method is using different 
library contexts to distinguish FIPS algorithms.  Using the properties in 
addition is harmless and might prevent a future mistake that breaks compliance.

Pauli

On 26/10/21 4:46 am, Jason Schultz wrote:
Thanks again. I think most of that makes sense. Going back to your initial 
response, there is something I'm not clear on.

The second method you explained (which I don't plan to use) starting with 
"Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then 
discussed calling the following API for FIPS:

   EVP_set_default_properties(NULL, “fips=yes”);

Was the EVP_set_default_properties() call specifically and only for the 2nd 
method, or did that API call apply to both the first and second methods you 
explained? From reading the doc for that call, it seems like I should be doing 
it if I use the first method as well.

Regards,

Jason


From: openssl-users 
<mailto:openssl-users-boun...@openssl.org> 
on behalf of Dr Paul Dale <mailto:pa...@openssl.org>
Sent: Sunday, October 24, 2021 11:12 PM
To: openssl-users@openssl.org<mailto:openssl-users@openssl.org> 
<mailto:openssl-users@openssl.org>
Subject: Re: OpenSSL 3.0 FIPS questions

The configuration shouldn't have much impact.  You will need a fips section 
specifying where the integrity check data are.  You shoul

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Kory-

If I'm understanding the README-FIPS.md file, I don't need to do the 
"fipsinstall", it is done during the normal installation process when FIPS is 
enabled, presumably with the "enable-fips" on the configure command:

Installing the FIPS module
==

If the FIPS provider is enabled, it gets installed automatically during the
normal installation process. Simply follow the normal procedure (configure,
make, make test, make install) as described in the [INSTALL](INSTALL.md) file.

For example, on Unix the final command

$ make install

effectively executes the following install targets

$ make install_sw
$ make install_ssldirs
$ make install_docs
$ make install_fips # for `enable-fips` only

It looks like the fips.so shared object was produced from these steps on my 
system, in /usr/local/lib64/ossl-modules/.

Are you saying I still needed to do "openssl fipsinstall" after the 4 steps I 
already did?

Thanks,

Jason



From: Kory Hamzeh 
Sent: Tuesday, October 26, 2021 8:13 PM
To: Jason Schultz 
Cc: Dr Paul Dale ; openssl-users@openssl.org 

Subject: Re: OpenSSL 3.0 FIPS questions

Did you follow the steps in README-FIPS.md and do the “fipsinstall”?


On Oct 26, 2021, at 12:17 PM, Jason Schultz 
mailto:jetso...@hotmail.com>> wrote:

Thanks for all of the help so far. Unfortunately, I'm still struggling with 
this. There could be a number of issues, starting with the installation of 
OpenSSL. I basically followed the documentation and did the following:

./Configure enable-fips
make
make test
make install

The "make test" actually fails, but I did not troubleshoot as it seems like a 
lot of systems have issues here. But I know the .so produced when I build my 
application is linking to the correct OpenSSL libraries (libssl.so.3 and 
libcrypto.so.3). Checking the OpenSSL version shows 3.0.

I've tried a number of combinations trying to make this work, starting with the 
code from Dr. Paul Dale in a previous message:

fips_libctx = OSSL_LIB_CTX_new();
if (!fips_libctx)
// error handling

non_fips_libctx = OSSL_LIB_CTX_new();
if (!non_fips_libctx)
// error handling

fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
if (fipsp == NULL)
  {
/* error handling */
  }


basep = OSSL_PROVIDER_load(fips_libctx, "base");
if (basep == NULL)
  {
/* error handling */
  }

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
if (defp == NULL)
  {
/* error handling */
  }

/* Disallow falling back to the default library context */

nullp = OSSL_PROVIDER_load(NULL, "null");
if (nullp == NULL)
  {
/*error handling */
  }

With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. If 
I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns NULL, 
which is probably expected given the fips provider didn't load.

At that point, I wasn't sure if my application was using the (correct) config 
file in /usr/local/ssl/. I don't have any environment variables set up, and 
would prefer not to have to set any to get this to work. So I changed the 
provider load for FIPS to use OSSL_LIB_CTX_load_config():

if (!OSSL_LIB_CTX_load_config(fips_libctx, 
"/usr/local/ssl/openssl-fips.cnf"))
  // error handling

This seems to work load the provider; however, there are two separate problems 
at this point. If FIPS is enabled by my application creating the SSL_CTX with  
the FIPS library context fails, returning NULL.

If FIPS is turned OFF by my application, creating an SSL_CTX with the 
non_fips_libctx  is successful, but later calling X509_get_pubkey() returns 
NULL, implying maybe something is wrong with the non_fips_libctx as well.

I've tried other combinations, but at this point I'm just guessing. Is there 
anything obvious I could be missing and I should be checking?

Thanks,

Jason


____
From: Dr Paul Dale mailto:pa...@openssl.org>>
Sent: Monday, October 25, 2021 9:37 PM
To: Jason Schultz mailto:jetso...@hotmail.com>>; 
openssl-users@openssl.org<mailto:openssl-users@openssl.org> 
mailto:openssl-users@openssl.org>>
Subject: Re: OpenSSL 3.0 FIPS questions

It was meant for the second method only.  The first method is using different 
library contexts to distinguish FIPS algorithms.  Using the properties in 
addition is harmless and might prevent a future mistake that breaks compliance.

Pauli

On 26/10/21 4:46 am, Jason Schultz wrote:
Thanks again. I think most of that makes sense. Going back to your initial 
response, there is something I'm not clear on.

The second method you explained (which I don't plan to use) starting with 
"Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then 
discussed calling the

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Thanks for all of the help so far. Unfortunately, I'm still struggling with 
this. There could be a number of issues, starting with the installation of 
OpenSSL. I basically followed the documentation and did the following:


./Configure enable-fips

make

make test

make install

The "make test" actually fails, but I did not troubleshoot as it seems like a 
lot of systems have issues here. But I know the .so produced when I build my 
application is linking to the correct OpenSSL libraries (libssl.so.3 and 
libcrypto.so.3). Checking the OpenSSL version shows 3.0.

I've tried a number of combinations trying to make this work, starting with the 
code from Dr. Paul Dale in a previous message:

fips_libctx = OSSL_LIB_CTX_new();
if (!fips_libctx)
// error handling

non_fips_libctx = OSSL_LIB_CTX_new();
if (!non_fips_libctx)
// error handling

fipsp = OSSL_PROVIDER_load(fips_libctx, "fips");
if (fipsp == NULL)
  {
/* error handling */
  }


basep = OSSL_PROVIDER_load(fips_libctx, "base");
if (basep == NULL)
  {
/* error handling */
  }

defp = OSSL_PROVIDER_load(non_fips_libctx, "default");
if (defp == NULL)
  {
/* error handling */
  }

/* Disallow falling back to the default library context */

nullp = OSSL_PROVIDER_load(NULL, "null");
if (nullp == NULL)
  {
/*error handling */
  }

With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. If 
I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns NULL, 
which is probably expected given the fips provider didn't load.

At that point, I wasn't sure if my application was using the (correct) config 
file in /usr/local/ssl/. I don't have any environment variables set up, and 
would prefer not to have to set any to get this to work. So I changed the 
provider load for FIPS to use OSSL_LIB_CTX_load_config():

if (!OSSL_LIB_CTX_load_config(fips_libctx, 
"/usr/local/ssl/openssl-fips.cnf"))
  // error handling

This seems to work load the provider; however, there are two separate problems 
at this point. If FIPS is enabled by my application creating the SSL_CTX with  
the FIPS library context fails, returning NULL.

If FIPS is turned OFF by my application, creating an SSL_CTX with the 
non_fips_libctx  is successful, but later calling X509_get_pubkey() returns 
NULL, implying maybe something is wrong with the non_fips_libctx as well.

I've tried other combinations, but at this point I'm just guessing. Is there 
anything obvious I could be missing and I should be checking?

Thanks,

Jason



From: Dr Paul Dale 
Sent: Monday, October 25, 2021 9:37 PM
To: Jason Schultz ; openssl-users@openssl.org 

Subject: Re: OpenSSL 3.0 FIPS questions

It was meant for the second method only.  The first method is using different 
library contexts to distinguish FIPS algorithms.  Using the properties in 
addition is harmless and might prevent a future mistake that breaks compliance.

Pauli

On 26/10/21 4:46 am, Jason Schultz wrote:
Thanks again. I think most of that makes sense. Going back to your initial 
response, there is something I'm not clear on.

The second method you explained (which I don't plan to use) starting with 
"Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then 
discussed calling the following API for FIPS:

   EVP_set_default_properties(NULL, “fips=yes”);

Was the EVP_set_default_properties() call specifically and only for the 2nd 
method, or did that API call apply to both the first and second methods you 
explained? From reading the doc for that call, it seems like I should be doing 
it if I use the first method as well.

Regards,

Jason


From: openssl-users 
<mailto:openssl-users-boun...@openssl.org> 
on behalf of Dr Paul Dale <mailto:pa...@openssl.org>
Sent: Sunday, October 24, 2021 11:12 PM
To: openssl-users@openssl.org<mailto:openssl-users@openssl.org> 
<mailto:openssl-users@openssl.org>
Subject: Re: OpenSSL 3.0 FIPS questions

The configuration shouldn't have much impact.  You will need a fips section 
specifying where the integrity check data are.  You shouldn't need base or 
default sections.


Pauli

On 25/10/21 5:23 am, Jason Schultz wrote:
Thank you for your response. I think all of that makes sense, and seems to 
accomplish what I want programmatically, limiting it to my application. I guess 
the only question I have is what about the config files? Should they remain as 
they were installed, or do I need to provide sections for fips, base, default, 
etc?

Regards,

Jason



From: openssl-users 
<mailto:openssl-users-boun...@openssl.org> 
on behalf of Dr Paul Dale <mailto:pa...@openssl.org>
Sent: Sunday, October 24, 2021 12:28 AM
To: openssl-users@opens

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Thanks again. I think most of that makes sense. Going back to your initial 
response, there is something I'm not clear on.

The second method you explained (which I don't plan to use) starting with 
"Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then 
discussed calling the following API for FIPS:


   EVP_set_default_properties(NULL, “fips=yes”);

Was the EVP_set_default_properties() call specifically and only for the 2nd 
method, or did that API call apply to both the first and second methods you 
explained? From reading the doc for that call, it seems like I should be doing 
it if I use the first method as well.

Regards,

Jason


From: openssl-users  on behalf of Dr Paul 
Dale 
Sent: Sunday, October 24, 2021 11:12 PM
To: openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0 FIPS questions

The configuration shouldn't have much impact.  You will need a fips section 
specifying where the integrity check data are.  You shouldn't need base or 
default sections.


Pauli

On 25/10/21 5:23 am, Jason Schultz wrote:
Thank you for your response. I think all of that makes sense, and seems to 
accomplish what I want programmatically, limiting it to my application. I guess 
the only question I have is what about the config files? Should they remain as 
they were installed, or do I need to provide sections for fips, base, default, 
etc?

Regards,

Jason



From: openssl-users 
<mailto:openssl-users-boun...@openssl.org> 
on behalf of Dr Paul Dale <mailto:pa...@openssl.org>
Sent: Sunday, October 24, 2021 12:28 AM
To: openssl-users@openssl.org<mailto:openssl-users@openssl.org> 
<mailto:openssl-users@openssl.org>
Subject: Re: OpenSSL 3.0 FIPS questions

Oops, the second time this occurs "defp = OSSL_PROVIDER_load(non_fips_libctx, 
"default");" it should be "defp = OSSL_PROVIDER_load(NULL, "default");"


Pauli

On 24/10/21 10:06 am, Dr Paul Dale wrote:
defp = OSSL_PROVIDER_load(non_fips_libctx, "default");

Re: OpenSSL 3.0 FIPS questions

[Jason Schultz]

Thank you for your response. I think all of that makes sense, and seems to 
accomplish what I want programmatically, limiting it to my application. I guess 
the only question I have is what about the config files? Should they remain as 
they were installed, or do I need to provide sections for fips, base, default, 
etc?

Regards,

Jason



From: openssl-users  on behalf of Dr Paul 
Dale 
Sent: Sunday, October 24, 2021 12:28 AM
To: openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0 FIPS questions

Oops, the second time this occurs "defp = OSSL_PROVIDER_load(non_fips_libctx, 
"default");" it should be "defp = OSSL_PROVIDER_load(NULL, "default");"


Pauli

On 24/10/21 10:06 am, Dr Paul Dale wrote:
defp = OSSL_PROVIDER_load(non_fips_libctx, "default");

OpenSSL 3.0 FIPS questions

[Jason Schultz]

Quick aside: I know the 3.0 FIPS module is not "approved" yet, I'm just trying 
to get my application updates done in advance.

I’m porting an application from OpenSSL 1.1.1, which was originally written for 
OpenSSL 1.0.2, to OpenSSL 3.0. Going to 3.0, I need to incorporate FIPS usage. 
My Linux application basically is told if its user wants to use FIPS or not. We 
don’t use the cryptographic APIs (EVP_*), we just need to create an SSL_CTX, 
and SSL objects created with SSL_new() based on this SSL_CTX, which will then 
call SSL_read(), SSL_write(), etc. The application won’t “fetch” any 
algorithms. So my focus can been on Section 7.7 of the Wiki:

https://wiki.openssl.org/index.php/OpenSSL_3.0#Using_the_FIPS_module_in_SSL.2FTLS

Based on if FIPS is on or off, I will use the replacement for SSL_CTX_new() and 
call SSL_CTX_new_ex() either something like this:

ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());

or this:

ctx = SSL_CTX_new_ex(fips_libctx, NULL, TLS_method());

Depending on if the users does not want FIPS, or wants FIPS, respectively.

Based on that and what Section 7.7 tells me, I know I need:


  1.  A non-default library context with the FIPS provider loaded (called 
fips_libctx), and
  2.  A non-default library context with the default provider loaded (called 
non_fips_libctx)

I know that I don’t want all applications using OpenSSL to use the FIPS module 
by default, so I’m just trying to configure mine correctly, using the APIs (and 
possibly config files). I also obviously don’t want to make my application use 
the FIPS module only.

Given all of the above I’m confused on how to set up #1 and #2. It seems like I 
need to use a combination of configuration files and programmatically calling 
APIs in my application. In the Wiki and the fips_module man page there is a 
section called “Programmatically loading the FIPS module (nondefault library 
context)”. I’m pretty sure this is what I want. The code example says it 
“assumes the existence of a config file called openssl-fips.cnf that 
automatically loads and configures the FIPS and base providers.”

The .cnf files that I have after the (FIPS) install of OpenSSL 3.0 are in 
/usr/local/ssl/: openssl.cnf and fipsmodule.cnf.

I guess the first thing is I’m confused on if the “openssl-fips.cnf” file 
referred to in the example is in addition to the two files above, or a 
replacement for one of them, and also what the contents of it need to be.

I had already made changes to the openssl.cnf file for FIPS (described in 
earlier sections of the Wiki):


# For FIPS

# Optionally include a file that is generated by the OpenSSL fipsinstall

# application. This file contains configuration data required by the OpenSSL

# fips provider. It contains a named section e.g. [fips_sect] which is

# referenced from the [provider_sect] below.

# Refer to the OpenSSL security policy for more information.

.include /usr/local/ssl/fipsmodule.cnfß uncommented



[openssl_init]

providers = provider_sect



# List of providers to load

[provider_sect]

default = default_sect

# The fips section name should match the section name inside the

# included fipsmodule.cnf.

fips = fips_sect ß uncommented



# If no providers are activated explicitly, the default one is activated 
implicitly.

# See man 7 OSSL_PROVIDER-default for more details.

#

# If you add a section explicitly activating any other provider(s), you most

# probably need to explicitly activate the default provider, otherwise it

# becomes unavailable in openssl.  As a consequence applications depending on

# OpenSSL may not work correctly which could lead to significant system

# problems including inability to remotely access the system.

[default_sect]

activate = 1 ß uncommented


I did this to make sure the FIPS provider was available and make sure the 
default provider was activated.

I also changed the fipsmodule.cnf file to comment out the activate = 1 line:


[fips_sect]

# activate = 1

conditional-errors = 1

security-checks = 1

module-mac = 
E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9

That was from the “Programmatically loading the FIPS module (default library 
context)” section, so I’m wondering if this was a mistake.

But currently, with the configs files as described above, my application is 
loading both providers:

fipsp = OSSL_PROVIDER_load(NULL, "fips");
if (fipsp == NULL)
{
/* error handling */
}

defp = OSSL_PROVIDER_load(NULL, "default");
if (defp == NULL)
{
/* error handling */
}

And then creating two library contexts:

fips_libctx = OSSL_LIB_CTX_new();
non_fips_libctx = OSSL_LIB_CTX_new();

Which are later used to create SSL_CTX’s as needed:

if (user does not want fips)
{
  ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());
}
   else (user wants fips)
{
  ctx = SSL_CTX_new_ex(fips_libctx, 

Re: Client side session handling

[Jason Schultz]

OpenSSL SSL_SESSSIONS are reference-counted.  This is typical of a
number of similar sufficiently complex structures for which it makes
more sense to bump a reference counter than to make a copy.

The SSL_SESSION_free(3), X509_free(), and various other calls just
decrement the reference counter, with the object only actually freed
once the counter reaches 0.

Various functions (though not all, as documented for each function) that
return such objects to the application increment the refernce counter
(say initially from 1 to 2), and the application is then responsible for
decrementing it.  THe object is finally freed when any internal
reference is released (if that happens last).
---

Hi Viktor. Thanks for your reply.

I'm somewhat familiar with the reference count stuff from reading the doc on 
these (and other) functions. But it sounds like the behavior I'm seeing is 
expected, and OpenSSL is doing the actual free of the SSL_SESSION when the 
SSL_CTX is freed.

Is that accurate?

Thanks,

Jason

Client side session handling

[Jason Schultz]

I’m not sure I fully understand client-side sessions in OpenSSL. My 
understanding is that on the server side, OpenSSL internally handles managing 
sessions. On the client side, they need to be handled by the application. This 
is true for both TLS 1.3 and TLS 1.2 (and prior), even though both protocols 
handle sessions slightly differently.

I’ll try to keep my questions to the simplest case and not get into how I store 
off the session objects and re-use them. But basically, I save each session 
object (2 of them per long handshake in this case) for client connections. I am 
able to successfully re-use them to initiate a short handshake. I have a remove 
callback set up that basically just prints something so I can see what OpenSSL 
is doing. After the SESSION object is used on the client side, I call 
SSL_SESSION_free() on that session. If I don’t use the client-side session, I 
also call SSL_SESSION_free() when the session times out and is no longer 
presumable, checking for that with SSL_SESSION_is_resumable().

Everything works fine, short handshakes are done when I expect them to be, etc.

The confusing part is that given everything above, when I free the SSL_CTX 
associated with these connections/sessions, I see the remove callback function 
get called again for client-side sessions that I already called 
SSL_SESSION_free() on. Is this normal behavior? Is there something else I’m 
missing?

Thanks in advance.

Jason

Questions regarding OpenSSL 3.0 and corresponding FIPS Module

[Jason Schultz]

I read the most recent (10/20) update to the OpenSSL 3.0 release page here:

https://www.openssl.org/blog/blog/2020/10/20/OpenSSL3.0Alpha7/

As well as the release strategy: 
https://wiki.openssl.org/index.php?title=OpenSSL_3.0_Release_Schedule=3099

I have not done anything with the Alpha releases so far, but I noticed the note 
"Basic functionality plus basic FIPS module".

Does this mean that there is a FIPS module available to test with in the 
alpha(and presumably beta) releases?

If the answer to that question is "yes", I'm assuming that the validation of 
that FIPS Module can't/won't start until after the Final OpenSSL 3.0 release. 
The timeframe for that validation is TBD, as it always varies.

The Final 3.0 release is currently behind schedule as it was estimated "early 
Q4 2020". Any ideas on how much behind that release is?

Thanks in advance for any information.

Re: Peer certificate verification in verify_callback

[Jason Schultz]

Thanks Victor.

I need to look at X509_VERIFY_PARAM_set_flags() a little closer, but I think I 
understand what I need to do.

I also can't concatenate all my trusted certificates into a single file, there 
are dozens of certificates in the trusted store. Our users can also manipulate 
the trusted store, so the trusted certificates will always be in PEM files in 
/etc/ssl/certs/.

It sounds like that's not going to hold me back from accomplishing what I need 
to do though, but I'll pursue this and let the list know if I run into any 
other issues.

Thanks again,

Jason



From: openssl-users  on behalf of Viktor 
Dukhovni 
Sent: Monday, March 30, 2020 9:19 PM
To: openssl-users@openssl.org 
Subject: Re: Peer certificate verification in verify_callback

On Mon, Mar 30, 2020 at 09:02:47PM +, Jason Schultz wrote:

> I won't get into the details of my application as it's complex, but it
> can act as a client or a server. The case we are worried about is
> obviously when it's acting as a client. I thought the standard way of
> dealing with these type of errors was with setting a verify_callback()
> function, which is part of the description below.

The verify callback is mostly for logging and error reporting.  It is
not intended to supplant the built-in verification logic.  While it
can be used to ignore some errors, that's generally quite risky and
difficult to do correctly.  You should strive to arrange for the
built-in verification to succeed, rather than attempt to work around
the resulting errors when it does not.

> I set up an X509_STORE object and then cycle through all of the
> certificate files in /etc/ssl/certs/, open them, and call
> PEM_read_X509() to get an X509 (certificate) object and then call
> X509_STORE_add_cert(x509_stor, certificate) to read the certificates
> into  my trusted store, X509_store object.

It would be far simpler to concatenate them into a single CAfile, or use
"c_rehash" to create the symlinks need to make the directory into a
workable CApath.  You should not have to manually load them into your
own store, although doing the latter potentially gives you the
opportunity to decorate them with auxiliary trust EKUs.


> If the user of this CTX is acting as a client and the server presents
> a certificate chain, and my trusted store has the root, the connection
> will work, as the chain is verified and trusted.

With the partial chain flag it can also work when the EE cert is present
(verbatim) in the store, or an intermediate CA is present in the store.

> If the server presents a self-signed certificate, the
> verify_callback() function is invoked with the error
>
> 18/X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT, but if I search for and find the 
> self-signed cert in my trusted store, I clear the error and let the
> connection proceed.

With 1.0.2 and later, the partial chain flag makes this work-around
unnecessary.

> The scenario is very similar for the case I asked about, the only difference 
> is I'm presented a 2 certs in a chain, and I have the
> intermediate cert in my store.  My understanding was the verify_callback() is 
> the correct place to handle these cases.

No, it is not.

> From Victor's response, I don't know what a custom X509_STORE type is
> or how to set one up.

You're already populating a custom store (though not a store type, which
it does not look like you need since your store is just a directory full
of PEM files).

> Likewise, I don't know how to use the "partial chain" flag

See X509_VERIFY_PARAM_set_flags(3).

> and what API I need to load intermediate certificates into my trusted
> store(other than what I describe above). Because of the way
> certificates are distributed, I can't always rely on having the root
> in the trusted store, so I'll need to trust some intermediate certs,
> provided they are valid, actually signed the end-entity cert, etc.

You just need to add them to the store, simplest is a CAfile or
a hashed CApath.

--
Viktor.

Re: Peer certificate verification in verify_callback

[Jason Schultz]

Victor, Jeremy-

Thanks for your responses. It sounds like I should maybe take a step back and 
describe what I'm doing and how. I'm possibly doing things fundamentally wrong, 
maybe because the way I'm doing them is based originally on OpenSSL 0.9.8. I'm 
currently moving from 1.0.2 to 1.1.1, which is why the questions are coming up.

I won't get into the details of my application as it's complex, but it can act 
as a client or a server. The case we are worried about is obviously when it's 
acting as a client. I thought the standard way of dealing with these type of 
errors was with setting a verify_callback() function, which is part of the 
description below.

I set up an X509_STORE object and then cycle through all of the certificate 
files in /etc/ssl/certs/, open them, and call PEM_read_X509() to get an X509 
(certificate) object and then call X509_STORE_add_cert(x509_stor, certificate) 
to read the certificates into  my trusted store, X509_store object. Then when I 
create an SSL CTX, I call SSL_CTX_set_cert_store() to set the X509_store object 
for the CTX. I also call SSL_set_verify( ,SSL_VERIFY_PEER,verify_callback) with 
the SSL object created from that CTX to set the verify_callback() function for 
each user that will act as a client.

If the user of this CTX is acting as a client and the server presents a 
certificate chain, and my trusted store has the root, the connection will work, 
as the chain is verified and trusted. If the server presents a self-signed 
certificate, the verify_callback() function is invoked with the error

18/X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT, but if I search for and find the 
self-signed cert in my trusted store, I clear the error and let the

connection proceed. The scenario is very similar for the case I asked about, 
the only difference is I'm presented a 2 certs in a chain, and I have the

intermediate cert in my store.  My understanding was the verify_callback() is 
the correct place to handle these cases.


>From Victor's response, I don't know what a custom X509_STORE type is or how 
>to set one up. Likewise, I don't know how to use the "partial chain" flag

and what API I need to load intermediate certificates into my trusted 
store(other than what I describe above). Because of the way certificates are

distributed, I can't always rely on having the root in the trusted store, so 
I'll need to trust some intermediate certs, provided they are valid, actually 
signed

the end-entity cert, etc.


Let me know if I am off track, and if so, what APIs I should be looking at, 
especially if there are been changes in this area.


Thanks.



From: openssl-users  on behalf of Viktor 
Dukhovni 
Sent: Monday, March 30, 2020 6:17 PM
To: openssl-users@openssl.org 
Subject: Re: Peer certificate verification in verify_callback

On Thu, Mar 05, 2020 at 02:04:27PM +0000, Jason Schultz wrote:

> I have some questions about my application’s verify_callback() function and 
> how I handle some of the OpenSSL errors.

You're going about this the wrong way.  Instead of tryign (likely
insecurely) to patch up verification errors in a verify callback, if you
have a certificate store that is not directly supported by OpenSSL, you
need to implement your own custom X509_STORE type, associate that store
with the SSL_CTX and have OpenSSL's built-in certificate verification
search that store for you.

If you also want to directly trust intermediate certificates that are
not self-signed roots, you can either set the "partial chain" flag,
or load into your store intermediate certificates with auxiliary
trust settings (aka "TRUSTED CERTIFICATES"), which will then be
trusted without chaining to a root, but simpler to just add the
roots to the store.

--
Viktor.

Re: Peer certificate verification in verify_callback

[Jason Schultz]

Just wanted to bring this up again as I didn't get any responses initially. Has 
anyone dealt with this or similar issues with OpenSSL 1.1.1?




From: openssl-users  on behalf of Jason 
Schultz 
Sent: Thursday, March 5, 2020 2:04 PM
To: openssl-users@openssl.org 
Subject: Peer certificate verification in verify_callback


I have some questions about my application’s verify_callback() function and how 
I handle some of the OpenSSL errors.



For example, if my client application is presented a self-signed certificate in 
the handshake, verify_callback() is called with an error, for which 
X509_STORE_CTX_get_error() returns 18/X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT. 
In this case, my application searches its trusted store for this certificate, 
and if it finds a match, the error is cleared and the handshake is allow to 
proceed.



Other examples are cases where my client application is presented with a 
certificate chain. Let’s say the chain looks like root -> intermediate -> 
end-entity, but the server is configured to not send the root, so my client 
gets: intermediate -> end-entity in the handshake.



One case is where my client is presented these  certificates and has the 
end-entity certificate in its trusted store. In this case, the 
verify_callback() gets error 20/ X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY. 
For this error, my application will search its trusted store for the end-entity 
certificate, and when a match is found the error is cleared and the handshake 
is allowed to proceed.



A slightly different case is when the client has only the intermediate 
certificate in its trusted store, while the server presents the intermediate -> 
end-entity chain. In this case, verify_callback() is called with an error, and 
X509_STORE_CTX_get_error() returns 2/ X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT.



These last two cases seem very similar but get slightly different errors. Right 
now my application does not look for a match in the case of 
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT. My plan is to add that error to the cases 
where the trusted store is searched for a match. Are there more subtle 
differences between these two errors that I’m missing? Or does my plan to have 
the application do the addition checking for this error make sense?

SSL_CTX_build_cert_chain() and SSL_CTX_set_mode()

[Jason Schultz]

Changing the subject to be more relevant to my questions. Just wanted to ping 
the list again.



From: openssl-users  on behalf of Jason 
Schultz 
Sent: Friday, March 20, 2020 3:21 PM
To: openssl-users@openssl.org 
Subject: Re: OpenSSL server sending certificate chain(inc. root cert) during 
handshake

I apologize for bringing this old subject back up, but I'm running into 
something I wanted to poll the list on.

Based on Victor's email below, I am doing the following in my application to 
set up my server to send a certificate chain *excluding* the root certificate 
during a handshake.

status = SSL_CTX_set_mode(ctx, SSL_MODE_NO_AUTO_CHAIN);
status = SSL_CTX_build_cert_chain(ctx, SSL_BUILD_CHAIN_FLAG_NO_ROOT);

When I configure a certificate chain, the server sends the chain, excluding the 
root. The call to SSL_CTX_build_cert_chain() accomplishes this, with the "no 
root" flag. This works as expected.

The interesting part comes in when I am configuring a self-signed certificate 
as the server cert.

** NOTE **: I know this isn't recommended, this is ONLY for test purposes, and 
our users will configure servers in this way, also ONLY for test purposes. This 
is why I'm testing the operation of this configuration.

As Victor indicated, my EE certificate is also the entire chain; of 1 
self-signed certificate. Setting the SSL_MODE_AUTO_CHAIN flag allowed me to 
configure a self-signed certificate on the server, the two calls above succeed, 
and my server sends that single, self-signed cert in the handshake. This is 
true for version 3 self-signed certificates, with the CA bit set.

If I have a version 1 *RSA* certificate, with the CA bit NOT set(so CA:FALSE), 
the call to SSL_CTX_build_cert_chain() errors. I think this is the expected 
behavior. Does everyone agree with that? Since OpenSSL 1.1.1 is more strict 
regarding the CA bit, the building of the "chain" will fail because a 
self-signed cert MUST have CA:TRUE.

The incorrect behavior I think I'm seeing is when configuring a self-signed 
ECDSA certificate. I'll paste the certificate below, but I would think this 
version 1 certificate that does NOT have CA:TRUE would error in the same was 
the similar RSA certificate did above. Does anyone know what could be the 
result of the (seemingly) different behavior? Are there any other tests I could 
try to lead me to an answer?

Thanks,

Jason


TEST:/etc/ssl # openssl x509 -text -noout -in certs/ecdsacert.pem
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
de:6e:db:59:3a:03:e5:ac
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=State, L=City, O=Company, OU=Networking, 
CN=COMMON-NAME/emailAddress=john@example.com
Validity
Not Before: Mar 17 18:23:09 2020 GMT
Not After : Mar 17 18:23:09 2021 GMT
Subject: C=US, ST=State, L=City, O=Company, OU=Networking, 
CN=COMMON-NAME/emailAddress=john@example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:dc:67:d3:f5:53:0b:c9:3c:13:e9:d9:52:17:60:
fb:a2:f6:ad:98:74:a4:1b:6d:57:52:81:d3:e5:8f:
e9:0f:a6:32:81:8f:f6:6d:3f:f2:1c:1c:6b:a7:c6:
3a:59:a3:c8:ce:12:08:ee:5c:8c:3e:4f:52:cb:35:
dc:6b:1a:de:59
ASN1 OID: prime256v1
NIST CURVE: P-256
Signature Algorithm: ecdsa-with-SHA256
 30:45:02:20:66:d8:35:06:98:38:0a:88:57:c4:8d:30:02:97:
 3a:e7:4f:34:4a:50:d2:5c:e7:16:61:80:b3:43:41:7f:71:42:
 02:21:00:82:c2:39:b5:52:d4:e9:aa:21:d5:d1:fb:e8:01:e2:
 aa:81:16:75:cb:0d:2c:33:f6:34:5b:54:80:ac:82:66:4f




From: openssl-users  on behalf of Viktor 
Dukhovni 
Sent: Friday, May 31, 2019 9:44 PM
To: openssl-users@openssl.org 
Subject: Re: OpenSSL server sending certificate chain(inc. root cert) during 
handshake

> On May 31, 2019, at 3:20 PM, Jason Schultz  wrote:
>
> My questions deal with #2: Why does OpenSSL include the root cert in the 
> certificate chain?

The OpenSSL SSL_CTX_build_cert_chain(3) function constructs a complete
chain of trust for your certificate chain, based on the configured trust
stores (CAfile and/or CApath).  If you call this function, then you can
control how your certificates chain is augmented.

But if your EE certificate is the entire chain, then the internal automatic
chain construction code will assume that the chain was not built, and will
try to augment it unless you set the SSL_MODE_NO_AUTO_CHAIN flag via:

  SSL_CTX_set_mode(3), or
  SSL_set_mode(3)

[ Which really ought to also document SSL_MODE_NO_AUTO_CHAIN ]

> Will the root cert be included in the chain any time it's in the same 
> directory
> as the server cert?

No, the chain is augmented based on the configured tru

Re: OpenSSL server sending certificate chain(inc. root cert) during handshake

[Jason Schultz]

I apologize for bringing this old subject back up, but I'm running into 
something I wanted to poll the list on.

Based on Victor's email below, I am doing the following in my application to 
set up my server to send a certificate chain *excluding* the root certificate 
during a handshake.

status = SSL_CTX_set_mode(ctx, SSL_MODE_NO_AUTO_CHAIN);
status = SSL_CTX_build_cert_chain(ctx, SSL_BUILD_CHAIN_FLAG_NO_ROOT);

When I configure a certificate chain, the server sends the chain, excluding the 
root. The call to SSL_CTX_build_cert_chain() accomplishes this, with the "no 
root" flag. This works as expected.

The interesting part comes in when I am configuring a self-signed certificate 
as the server cert.

** NOTE **: I know this isn't recommended, this is ONLY for test purposes, and 
our users will configure servers in this way, also ONLY for test purposes. This 
is why I'm testing the operation of this configuration.

As Victor indicated, my EE certificate is also the entire chain; of 1 
self-signed certificate. Setting the SSL_MODE_AUTO_CHAIN flag allowed me to 
configure a self-signed certificate on the server, the two calls above succeed, 
and my server sends that single, self-signed cert in the handshake. This is 
true for version 3 self-signed certificates, with the CA bit set.

If I have a version 1 *RSA* certificate, with the CA bit NOT set(so CA:FALSE), 
the call to SSL_CTX_build_cert_chain() errors. I think this is the expected 
behavior. Does everyone agree with that? Since OpenSSL 1.1.1 is more strict 
regarding the CA bit, the building of the "chain" will fail because a 
self-signed cert MUST have CA:TRUE.

The incorrect behavior I think I'm seeing is when configuring a self-signed 
ECDSA certificate. I'll paste the certificate below, but I would think this 
version 1 certificate that does NOT have CA:TRUE would error in the same was 
the similar RSA certificate did above. Does anyone know what could be the 
result of the (seemingly) different behavior? Are there any other tests I could 
try to lead me to an answer?

Thanks,

Jason


TEST:/etc/ssl # openssl x509 -text -noout -in certs/ecdsacert.pem
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
de:6e:db:59:3a:03:e5:ac
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=State, L=City, O=Company, OU=Networking, 
CN=COMMON-NAME/emailAddress=john@example.com
Validity
Not Before: Mar 17 18:23:09 2020 GMT
Not After : Mar 17 18:23:09 2021 GMT
Subject: C=US, ST=State, L=City, O=Company, OU=Networking, 
CN=COMMON-NAME/emailAddress=john@example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:dc:67:d3:f5:53:0b:c9:3c:13:e9:d9:52:17:60:
fb:a2:f6:ad:98:74:a4:1b:6d:57:52:81:d3:e5:8f:
e9:0f:a6:32:81:8f:f6:6d:3f:f2:1c:1c:6b:a7:c6:
3a:59:a3:c8:ce:12:08:ee:5c:8c:3e:4f:52:cb:35:
dc:6b:1a:de:59
ASN1 OID: prime256v1
NIST CURVE: P-256
Signature Algorithm: ecdsa-with-SHA256
 30:45:02:20:66:d8:35:06:98:38:0a:88:57:c4:8d:30:02:97:
 3a:e7:4f:34:4a:50:d2:5c:e7:16:61:80:b3:43:41:7f:71:42:
 02:21:00:82:c2:39:b5:52:d4:e9:aa:21:d5:d1:fb:e8:01:e2:
 aa:81:16:75:cb:0d:2c:33:f6:34:5b:54:80:ac:82:66:4f




From: openssl-users  on behalf of Viktor 
Dukhovni 
Sent: Friday, May 31, 2019 9:44 PM
To: openssl-users@openssl.org 
Subject: Re: OpenSSL server sending certificate chain(inc. root cert) during 
handshake

> On May 31, 2019, at 3:20 PM, Jason Schultz  wrote:
>
> My questions deal with #2: Why does OpenSSL include the root cert in the 
> certificate chain?

The OpenSSL SSL_CTX_build_cert_chain(3) function constructs a complete
chain of trust for your certificate chain, based on the configured trust
stores (CAfile and/or CApath).  If you call this function, then you can
control how your certificates chain is augmented.

But if your EE certificate is the entire chain, then the internal automatic
chain construction code will assume that the chain was not built, and will
try to augment it unless you set the SSL_MODE_NO_AUTO_CHAIN flag via:

  SSL_CTX_set_mode(3), or
  SSL_set_mode(3)

[ Which really ought to also document SSL_MODE_NO_AUTO_CHAIN ]

> Will the root cert be included in the chain any time it's in the same 
> directory
> as the server cert?

No, the chain is augmented based on the configured trust stores, and does
not directly consider the directory holding the chain file.

> Is there a way, via API call, configuration, etc, to force OpenSSL to NOT 
> send the
> root certificate as part of the chain in this case?

You can set a CAfile/CApath that do not include the location of the root
cert, or disable automatic chain const

Peer certificate verification in verify_callback

[Jason Schultz]

I have some questions about my application’s verify_callback() function and how 
I handle some of the OpenSSL errors.



For example, if my client application is presented a self-signed certificate in 
the handshake, verify_callback() is called with an error, for which 
X509_STORE_CTX_get_error() returns 18/X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT. 
In this case, my application searches its trusted store for this certificate, 
and if it finds a match, the error is cleared and the handshake is allow to 
proceed.



Other examples are cases where my client application is presented with a 
certificate chain. Let’s say the chain looks like root -> intermediate -> 
end-entity, but the server is configured to not send the root, so my client 
gets: intermediate -> end-entity in the handshake.



One case is where my client is presented these  certificates and has the 
end-entity certificate in its trusted store. In this case, the 
verify_callback() gets error 20/ X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY. 
For this error, my application will search its trusted store for the end-entity 
certificate, and when a match is found the error is cleared and the handshake 
is allowed to proceed.



A slightly different case is when the client has only the intermediate 
certificate in its trusted store, while the server presents the intermediate -> 
end-entity chain. In this case, verify_callback() is called with an error, and 
X509_STORE_CTX_get_error() returns 2/ X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT.



These last two cases seem very similar but get slightly different errors. Right 
now my application does not look for a match in the case of 
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT. My plan is to add that error to the cases 
where the trusted store is searched for a match. Are there more subtle 
differences between these two errors that I’m missing? Or does my plan to have 
the application do the addition checking for this error make sense?

Re: OpenSSL 3.0

[Jason Schultz]

That's fair. So the only option is to use another module? Extended 1.0.2 
support does not resolve this either, correct?


From: Salz, Rich 
Sent: Thursday, February 27, 2020 8:49 PM
To: Jason Schultz ; openssl-users@openssl.org 

Subject: Re: OpenSSL 3.0


  *   The OpenSSL FIPS Object Module will be moved to the CMVP historical list 
as of 9/1/2020. Since there is no OpenSSL 3.0 until Q4 2020, and a FIPS Module 
will be after that sometime, where does this leave 1.0.2 users who need a FIPS 
validated object module past that date?



Without their free lunch?

Re: OpenSSL 3.0

[Jason Schultz]

For option 2, we have a support contract in place. But does this actually help 
us as far as the FIPS Object Module?



From: openssl-users  on behalf of Neptune 

Sent: Thursday, February 27, 2020 8:56 PM
To: openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0

You essentially have three choices:
1. Stay on the 1.0.2 branch to continue FIPS compliance, but go the entire
year without support or security patches.
2. Pay OpenSSL for a premium support contract ($50,000 per year) to continue
to receive patches on 1.0.2 for the remainder of the year.
3. Pay SafeLogic for support contract to receive 1.0.2 security patches
through the year. Cost is roughly half what OpenSSL is asking, but you may
be able to negotiate.

These are the only options of which I am aware.




--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html

Re: OpenSSL 3.0

[Jason Schultz]

Thanks for all of the responses. This question has led to other related topics, 
so I have another one. According to this blog:

https://keypair.us/2019/12/rip-fips-186-2/

The OpenSSL FIPS Object Module will be moved to the CMVP historical list as of 
9/1/2020. Since there is no OpenSSL 3.0 until Q4 2020, and a FIPS Module will 
be after that sometime, where does this leave 1.0.2 users who need a FIPS 
validated object module past that date?




From: openssl-users  on behalf of Salz, Rich 
via openssl-users 
Sent: Thursday, February 27, 2020 1:31 PM
To: Matt Caswell ; openssl-users@openssl.org 

Subject: Re: OpenSSL 3.0


>It would probably be a good idea for us to pull together a "Getting
Started" guide on the Wiki with some basic information on how to get
things going, with some links to the various man pages etc where more
detailed information is required.

This needs to be real user documentation as part of the FIPS deliverable, right?

OpenSSL 3.0

[Jason Schultz]

Greetings. It has been several months since this blog post on OpenSSL 3.0:



https://www.openssl.org/blog/blog/2019/11/07/3.0-update/



“We are now not expecting code completion to occur until the end of Q2 2020 
with a final release in early Q4 2020.”



Is OpenSSL 3.0 still expected to reach code completion at the end of Q2 this 
year? Also, by “final release” I’m assuming that means the first official, 
non-beta/dev release?

Re: Questions about using Elliptic Curve ciphers in OpenSSL

[Jason Schultz]

Nicola...my apologies for the typo...


From: openssl-users  on behalf of Jason 
Schultz 
Sent: Friday, February 21, 2020 1:05 PM
To: Nicola Tuveri 
Cc: openssl-users 
Subject: Re: Questions about using Elliptic Curve ciphers in OpenSSL

Nicole-

This was very helpful, thank you for taking the time to respond. I was confused 
about the parameters files, I understand why they are not needed.

Also, I should have been more clear, the creation of these cert/key pairs is 
strictly for testing purposes (and to give our users an easy way to test before 
they have their own certificate, signed by a CA).

Thanks again.



From: Nicola Tuveri 
Sent: Wednesday, February 19, 2020 9:42 PM
To: Jason Schultz 
Cc: Kyle Hamilton ; openssl-users 

Subject: Re: Questions about using Elliptic Curve ciphers in OpenSSL

I think there might be some confusion.

The "parameters" files are a legacy from when cryptosystems using "custom" 
domains were not widely deprecated.
Such parameter files were required for any instance of key generation, to make 
sure that a key was generated in the defined custom domain, and were part of 
any key serialization because in cryptosystems that define domain parameters a 
keypair is generally void of operational meaning if it isn't associated with a 
domain in which that keypair can be used to perform operations and also because 
when two or more peers are involved we need  to make sure that exchanged keys 
belonged to the same domain in which we chose to operate.

Nowadays the experts discourage "custom" domains (see e.g. RFC 8422), as they 
bring way more disadvantages than advantages, especially considering that the 
disadvantages include potential serious security pitfalls.

Historically you needed to pregenerate a domain parameters file for ephemeral 
DH used in the key exchange part of the TLS handshake, because key generation 
is a relatively cheap operation, but generating the big random primes required 
for creating new domain parameters is a quite demanding process: this was the 
params file that was provided to the SSL/TLS backend and needed to be saved 
alongside keys and certificates.
With ECDH, parameter generation for custom domains is even more involved, error 
prone, and the validation of custom parameters received from a peer is very 
expensive and littered with risks for the overall security if not done properly.

That being said, recommending "use named curves" just means to use 
well-established and studied set of parameters that standardizing bodies deemed 
recommendable for secure use: this way both peers refer to a set of parameters 
with a given common name rather than explicit parameters, and the clients can 
trust the evaluation done by experts rather than having to verify the received 
parameters for complex mathematical properties.

Now, to the commands in your email, it must be clear that there are a few 
cryptosystems involved in a generic TLS handshake:
1. key exchange: usually ephemeral ECDH
2. digital signature (to validate the handshake with the server credentials): 
commonly RSA, ECDSA or EdDSA (depending on the server key type)
3. digital signature (to validate the certificate where the CA states "this 
public key belongs to this subject"): commonly RSA, ECDSA or EdDSA (depending 
on the CA key type)

(We should note that 3 does not necessarily require a `verify()` operation for 
every handshake, because both the issuer and the subject credentials are 
static, so a certificate for a server could be validated once and cached for 
later use).

1)

Ephemeral ECDH generates a new keypair for every handshake, so the parties need 
to agree on which domain parameters to use.
We negotiate named curves rather than explicit parameters, and that is what 
`status = SSL_CTX_set1_curves_list(ctx, "P-521:P-384:P-256");` does: both 
parties specify a list of supported curves, and one in common is picked 
(preference on multiple hits is an irrelevant detail here).
So no need for a parameters file here, we use a list of names, and this is 
independent from the cryptosystem picked for the two digital signature 
operations.

2)

The server needs to have its own keypair, this means a one-time-only keygen 
operation for which parameters are necessary if we pick ECDSA as the 
cryptosystem of our choice.
You can do this using explicit parameters or a named curve, and the latter is 
preferred. In any case there is no need to store a parameters file after the 
key has been generated, as the key parameters are saved in the key 
serialization anyway, both for named and for custom curves.

There is no harm in generating an intermediary params file, but it is 
superfluous, and also the fact that there is no need to create such a file 
should answer to your original question about where/how it is best to store the 
parameter file.

To generate such a private key wit

Re: Questions about using Elliptic Curve ciphers in OpenSSL

[Jason Schultz]

Nicole-

This was very helpful, thank you for taking the time to respond. I was confused 
about the parameters files, I understand why they are not needed.

Also, I should have been more clear, the creation of these cert/key pairs is 
strictly for testing purposes (and to give our users an easy way to test before 
they have their own certificate, signed by a CA).

Thanks again.



From: Nicola Tuveri 
Sent: Wednesday, February 19, 2020 9:42 PM
To: Jason Schultz 
Cc: Kyle Hamilton ; openssl-users 

Subject: Re: Questions about using Elliptic Curve ciphers in OpenSSL

I think there might be some confusion.

The "parameters" files are a legacy from when cryptosystems using "custom" 
domains were not widely deprecated.
Such parameter files were required for any instance of key generation, to make 
sure that a key was generated in the defined custom domain, and were part of 
any key serialization because in cryptosystems that define domain parameters a 
keypair is generally void of operational meaning if it isn't associated with a 
domain in which that keypair can be used to perform operations and also because 
when two or more peers are involved we need  to make sure that exchanged keys 
belonged to the same domain in which we chose to operate.

Nowadays the experts discourage "custom" domains (see e.g. RFC 8422), as they 
bring way more disadvantages than advantages, especially considering that the 
disadvantages include potential serious security pitfalls.

Historically you needed to pregenerate a domain parameters file for ephemeral 
DH used in the key exchange part of the TLS handshake, because key generation 
is a relatively cheap operation, but generating the big random primes required 
for creating new domain parameters is a quite demanding process: this was the 
params file that was provided to the SSL/TLS backend and needed to be saved 
alongside keys and certificates.
With ECDH, parameter generation for custom domains is even more involved, error 
prone, and the validation of custom parameters received from a peer is very 
expensive and littered with risks for the overall security if not done properly.

That being said, recommending "use named curves" just means to use 
well-established and studied set of parameters that standardizing bodies deemed 
recommendable for secure use: this way both peers refer to a set of parameters 
with a given common name rather than explicit parameters, and the clients can 
trust the evaluation done by experts rather than having to verify the received 
parameters for complex mathematical properties.

Now, to the commands in your email, it must be clear that there are a few 
cryptosystems involved in a generic TLS handshake:
1. key exchange: usually ephemeral ECDH
2. digital signature (to validate the handshake with the server credentials): 
commonly RSA, ECDSA or EdDSA (depending on the server key type)
3. digital signature (to validate the certificate where the CA states "this 
public key belongs to this subject"): commonly RSA, ECDSA or EdDSA (depending 
on the CA key type)

(We should note that 3 does not necessarily require a `verify()` operation for 
every handshake, because both the issuer and the subject credentials are 
static, so a certificate for a server could be validated once and cached for 
later use).

1)

Ephemeral ECDH generates a new keypair for every handshake, so the parties need 
to agree on which domain parameters to use.
We negotiate named curves rather than explicit parameters, and that is what 
`status = SSL_CTX_set1_curves_list(ctx, "P-521:P-384:P-256");` does: both 
parties specify a list of supported curves, and one in common is picked 
(preference on multiple hits is an irrelevant detail here).
So no need for a parameters file here, we use a list of names, and this is 
independent from the cryptosystem picked for the two digital signature 
operations.

2)

The server needs to have its own keypair, this means a one-time-only keygen 
operation for which parameters are necessary if we pick ECDSA as the 
cryptosystem of our choice.
You can do this using explicit parameters or a named curve, and the latter is 
preferred. In any case there is no need to store a parameters file after the 
key has been generated, as the key parameters are saved in the key 
serialization anyway, both for named and for custom curves.

There is no harm in generating an intermediary params file, but it is 
superfluous, and also the fact that there is no need to create such a file 
should answer to your original question about where/how it is best to store the 
parameter file.

To generate such a private key without the need for an intermediate params file 
you could run:

~~~sh
curve_name=prime256v1
privkey_file=mykeyout.pem

openssl genpkey \
-algorithm EC -pkeyopt ec_paramgen_curve:$curve_name \
-pkeyopt ec_param_enc:named_curve \
-outform pem -out $priv

Re: Questions about using Elliptic Curve ciphers in OpenSSL

[Jason Schultz]

Nicola-

Thanks for your response. It does help, but at the same time it also raises 
questions and maybe conflicts with what I thought I was doing correct earlier 
in this thread. I'm talking mostly about where I landed in this post:

https://www.mail-archive.com/openssl-users@openssl.org/msg87538.html
Re: Questions about using Elliptic Curve ciphers in 
OpenSSL<https://www.mail-archive.com/openssl-users@openssl.org/msg87538.html>
Thank you for your response Thulasi, this helped. I'm posting this back to the 
OpenSSL users list in case it helps anyone else, and in case anyone can help 
with my additional questions.
www.mail-archive.com


I am only using named curves. You also said:

"...you don't really need at all to generate a ecparam file (which only 
contains the name): the private key file already contains the very same name 
and fully contains what you need to perform ECDSA signatures that can be 
validated against a matching certificate."

Let me apply that and start from the beginning and outline everything (I think) 
I need to do in that case:

1 - Generate a certificate and private key pair. Using the OpenSSL command line:


openssl req -nodes -sha256 -newkey ec:<(openssl ecparam -name prime256v1)
-keyout mykeyout.pem -new -out mycertfileout.pem -config /etc/ssl/openssl.cnf
-x509 -days 365 -outform pem

Note: the "ec:" parameter basically substitutes the openssl command above with 
the file I had created and used in this command. Also, the "-genkey" parameter 
I included in the ecparam command was probably not needed, or potentially bad?

2 - Call the SSL_CTX_use_PrivateKey_file() and SSL_CTX_use_certificate_file() 
to use the certificate and private key pair. (Same as before)

3 - Call the APIs to set the curves and allow the server to pick the 
appropriate curves for the client:


status = SSL_CTX_set1_curves_list(ctx, "P-521:P-384:P-256");
status = SSL_CTX_set_ecdh_auto(ctx, 1);

Do I have this right? Is the only difference combining the two commands into 
one in Step 1 above, instead of the intermediate ecparams file? Or is there 
something else I'm missing on the generation of certificate/private key pairs?

Thanks,

Jason





From: Nicola Tuveri 
Sent: Tuesday, February 18, 2020 2:50 PM
To: Jason Schultz 
Cc: Kyle Hamilton ; openssl-users 

Subject: Re: Questions about using Elliptic Curve ciphers in OpenSSL

The ec parameters are public anyway, so there is no real need to store such 
files somewhere with restricted reading access.

On the other hand, I want to reiterate that if you are using (and this is 
highly recommended) one of the named curves (e.g. NIST P-256) you don't really 
need at all to generate a ecparam file (which only contains the name): the 
private key file already contains the very same name and fully contains what 
you need to perform ECDSA signatures that can be validated against a matching 
certificate.

In the same way, for the ECDHE part, pick curves that you want to support (most 
TLS 1.2 and 1.3 clients will be happy to support P-256 and X25519 key 
exchanges) from the named curves: also in this case there is no need to 
generate a separate ecparam file.

Hope this helps!

Best regards,

Nicola Tuveri


On Tue, 18 Feb 2020 at 15:27, Jason Schultz 
mailto:jetso...@hotmail.com>> wrote:
This comment does spark another question though. Do I need to protect the 
ecparam file I created for us in generating the private key? I know the private 
key should reside in /etc/ssl/private/ as that directory has no read access. 
Right now I have the ecparam generated file in /etc/ssl/dsaparams/, which is 
readable. Should that file also reside in /etc/ssl/private/ so it's protected?

Thanks.



From: Kyle Hamilton mailto:aerow...@gmail.com>>
Sent: Sunday, February 16, 2020 10:49 PM
To: Jason Schultz mailto:jetso...@hotmail.com>>
Cc: Thulasi Goriparthi 
mailto:thulasi.goripar...@gmail.com>>; 
openssl-users mailto:openssl-users@openssl.org>>
Subject: Re: Questions about using Elliptic Curve ciphers in OpenSSL

Be aware that you just posted your certificate's private key, and thus you 
should regenerate a new keypair/certificate to use.  Otherwise, anyone who can 
manipulate traffic to your machine can execute a man-in-the-middle attack.

-Kyle H


On Fri, Feb 14, 2020, 07:40 Jason Schultz 
mailto:jetso...@hotmail.com>> wrote:

Thank you for your response Thulasi, this helped. I'm posting this back to the 
OpenSSL users list in case it helps anyone else, and in case anyone can help 
with my additional questions. While waiting for responses, I've been able to 
find out how my certificate and keys were generated. I'd like to walk through 
that to hopefully verify I'm handling things correctly.

First, here is how my EC parameters file was generated:

openssl ecparam -name prime256v1 -genkey -out myecparamsfile.pem

And the resulting

Re: Questions about using Elliptic Curve ciphers in OpenSSL

[Jason Schultz]

This comment does spark another question though. Do I need to protect the 
ecparam file I created for us in generating the private key? I know the private 
key should reside in /etc/ssl/private/ as that directory has no read access. 
Right now I have the ecparam generated file in /etc/ssl/dsaparams/, which is 
readable. Should that file also reside in /etc/ssl/private/ so it's protected?

Thanks.



From: Kyle Hamilton 
Sent: Sunday, February 16, 2020 10:49 PM
To: Jason Schultz 
Cc: Thulasi Goriparthi ; openssl-users 

Subject: Re: Questions about using Elliptic Curve ciphers in OpenSSL

Be aware that you just posted your certificate's private key, and thus you 
should regenerate a new keypair/certificate to use.  Otherwise, anyone who can 
manipulate traffic to your machine can execute a man-in-the-middle attack.

-Kyle H


On Fri, Feb 14, 2020, 07:40 Jason Schultz 
mailto:jetso...@hotmail.com>> wrote:

Thank you for your response Thulasi, this helped. I'm posting this back to the 
OpenSSL users list in case it helps anyone else, and in case anyone can help 
with my additional questions. While waiting for responses, I've been able to 
find out how my certificate and keys were generated. I'd like to walk through 
that to hopefully verify I'm handling things correctly.

First, here is how my EC parameters file was generated:

openssl ecparam -name prime256v1 -genkey -out myecparamsfile.pem

And the resulting file:


M640A-SAIL:/etc/ssl # openssl ecparam -in myecparamsfile.pem -text

ASN1 OID: prime256v1

NIST CURVE: P-256

-BEGIN EC PARAMETERS-

BggqhkjOPQMBBw==

-END EC PARAMETERS-


 # openssl ecparam -in myecparamsfile.pem -text

ASN1 OID: prime256v1

NIST CURVE: P-256

-BEGIN EC PARAMETERS-

BggqhkjOPQMBBw==

-END EC PARAMETERS-

Is this good so far? Do I need the -genkey?

Then I take this file and use it when I generate my certificate and private key 
pair, here is the openssl command I used:

openssl req -nodes -sha256 -newkey ec:/etc/ssl/private/myecparamsfile.pem 
-keyout mykeyout.pem -new -out mycertfileout.pem -config /etc/ssl/openssl.cnf 
-x509 -days 365 -outform pem
Generating a EC private key
writing new private key to 'mykeyout.pem'


And the resulting key:

# cat mykeyout.pem
-BEGIN PRIVATE KEY-
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgbfUwVhomun9Q5IAY
xTOAn+sDoXZ+k4UWkvUyfshPBJ6hRANCAAQsakFVUTV4JmfVJH31XOvHVhhBodnV
8evYCJSd2Jgo4uOomCSh3oekKL+Tia+LOmynygfvmneOX2YadoNr9uzH
-END PRIVATE KEY-

# openssl ec -noout -text -in mykeyout.pem
read EC key
Private-Key: (256 bit)
priv:
6d:f5:30:56:1a:26:ba:7f:50:e4:80:18:c5:33:80:
9f:eb:03:a1:76:7e:93:85:16:92:f5:32:7e:c8:4f:
04:9e
pub:
04:2c:6a:41:55:51:35:78:26:67:d5:24:7d:f5:5c:
eb:c7:56:18:41:a1:d9:d5:f1:eb:d8:08:94:9d:d8:
98:28:e2:e3:a8:98:24:a1:de:87:a4:28:bf:93:89:
af:8b:3a:6c:a7:ca:07:ef:9a:77:8e:5f:66:1a:76:
83:6b:f6:ec:c7
ASN1 OID: prime256v1
NIST CURVE: P-256

And certificate:

M740A-PMM1:/etc/ssl # openssl x509 -text -in mycertfileout.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
e2:2f:c6:e4:bf:f1:de:20
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=NY, L=Loc, O=Org, OU=test, CN=My 
Name/emailAddress=t...@example.com
Validity
Not Before: Feb 13 16:11:39 2020 GMT
Not After : Feb 12 16:11:39 2021 GMT
Subject: C=US, ST=NY, L=Loc, O=Org, OU=test, CN=My 
Name/emailAddress=t...@example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:2c:6a:41:55:51:35:78:26:67:d5:24:7d:f5:5c:
eb:c7:56:18:41:a1:d9:d5:f1:eb:d8:08:94:9d:d8:
98:28:e2:e3:a8:98:24:a1:de:87:a4:28:bf:93:89:
af:8b:3a:6c:a7:ca:07:ef:9a:77:8e:5f:66:1a:76:
83:6b:f6:ec:c7
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Subject Key Identifier:
D6:8A:F3:3B:4E:A1:F8:F8:34:C1:1B:7A:EC:BF:9B:58:7F:68:4A:D9
X509v3 Authority Key Identifier:

keyid:D6:8A:F3:3B:4E:A1:F8:F8:34:C1:1B:7A:EC:BF:9B:58:7F:68:4A:D9

X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: ecdsa-with-SHA256
 30:44:02:20:37:f0:f7:f7:4a:b4:8e:8f:64:72:e4:d1:31:9f:
 a1:36:c5:5d:f3:42:4c:24:37:75:cf:b6:55:b0:66:1b:6e:63:
 02:20:39:18:81:f8:6c:86:3a:57:74:05:cc:99:6c:d9:dc:6a:
 a2:20:98:4c:66:a1:97:d1:c7:ea:42:b4:01:1a:f7:b2

Then I call the APIs as described in my first email to use them:


ctx = SSL_CTX_new(TLS_method());

status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);
status = SSL_CTX_use_certificate_file(ctx, ,,SSL_FILETYPE_PEM);


// Verify the cert and key are a pair
status = SSL_CTX_check_private_key(ctx);

Then call th

Re: Questions about using Elliptic Curve ciphers in OpenSSL

[Jason Schultz]

Yes, absolutely. As I said in my first post, these are throwaway key pairs, not 
for production use, just a short time for testing to get things working.

Thanks,

Jason


On Feb 16, 2020, at 4:49 PM, Kyle Hamilton  wrote:


Be aware that you just posted your certificate's private key, and thus you 
should regenerate a new keypair/certificate to use.  Otherwise, anyone who can 
manipulate traffic to your machine can execute a man-in-the-middle attack.

-Kyle H


On Fri, Feb 14, 2020, 07:40 Jason Schultz 
mailto:jetso...@hotmail.com>> wrote:

Thank you for your response Thulasi, this helped. I'm posting this back to the 
OpenSSL users list in case it helps anyone else, and in case anyone can help 
with my additional questions. While waiting for responses, I've been able to 
find out how my certificate and keys were generated. I'd like to walk through 
that to hopefully verify I'm handling things correctly.

First, here is how my EC parameters file was generated:

openssl ecparam -name prime256v1 -genkey -out myecparamsfile.pem

And the resulting file:


M640A-SAIL:/etc/ssl # openssl ecparam -in myecparamsfile.pem -text

ASN1 OID: prime256v1

NIST CURVE: P-256

-BEGIN EC PARAMETERS-

BggqhkjOPQMBBw==

-END EC PARAMETERS-


 # openssl ecparam -in myecparamsfile.pem -text

ASN1 OID: prime256v1

NIST CURVE: P-256

-BEGIN EC PARAMETERS-

BggqhkjOPQMBBw==

-END EC PARAMETERS-

Is this good so far? Do I need the -genkey?

Then I take this file and use it when I generate my certificate and private key 
pair, here is the openssl command I used:

openssl req -nodes -sha256 -newkey ec:/etc/ssl/private/myecparamsfile.pem 
-keyout mykeyout.pem -new -out mycertfileout.pem -config /etc/ssl/openssl.cnf 
-x509 -days 365 -outform pem
Generating a EC private key
writing new private key to 'mykeyout.pem'


And the resulting key:

# cat mykeyout.pem
-BEGIN PRIVATE KEY-
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgbfUwVhomun9Q5IAY
xTOAn+sDoXZ+k4UWkvUyfshPBJ6hRANCAAQsakFVUTV4JmfVJH31XOvHVhhBodnV
8evYCJSd2Jgo4uOomCSh3oekKL+Tia+LOmynygfvmneOX2YadoNr9uzH
-END PRIVATE KEY-

# openssl ec -noout -text -in mykeyout.pem
read EC key
Private-Key: (256 bit)
priv:
6d:f5:30:56:1a:26:ba:7f:50:e4:80:18:c5:33:80:
9f:eb:03:a1:76:7e:93:85:16:92:f5:32:7e:c8:4f:
04:9e
pub:
04:2c:6a:41:55:51:35:78:26:67:d5:24:7d:f5:5c:
eb:c7:56:18:41:a1:d9:d5:f1:eb:d8:08:94:9d:d8:
98:28:e2:e3:a8:98:24:a1:de:87:a4:28:bf:93:89:
af:8b:3a:6c:a7:ca:07:ef:9a:77:8e:5f:66:1a:76:
83:6b:f6:ec:c7
ASN1 OID: prime256v1
NIST CURVE: P-256

And certificate:

M740A-PMM1:/etc/ssl # openssl x509 -text -in mycertfileout.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
e2:2f:c6:e4:bf:f1:de:20
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=NY, L=Loc, O=Org, OU=test, CN=My 
Name/emailAddress=t...@example.com
Validity
Not Before: Feb 13 16:11:39 2020 GMT
Not After : Feb 12 16:11:39 2021 GMT
Subject: C=US, ST=NY, L=Loc, O=Org, OU=test, CN=My 
Name/emailAddress=t...@example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:2c:6a:41:55:51:35:78:26:67:d5:24:7d:f5:5c:
eb:c7:56:18:41:a1:d9:d5:f1:eb:d8:08:94:9d:d8:
98:28:e2:e3:a8:98:24:a1:de:87:a4:28:bf:93:89:
af:8b:3a:6c:a7:ca:07:ef:9a:77:8e:5f:66:1a:76:
83:6b:f6:ec:c7
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Subject Key Identifier:
D6:8A:F3:3B:4E:A1:F8:F8:34:C1:1B:7A:EC:BF:9B:58:7F:68:4A:D9
X509v3 Authority Key Identifier:

keyid:D6:8A:F3:3B:4E:A1:F8:F8:34:C1:1B:7A:EC:BF:9B:58:7F:68:4A:D9

X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: ecdsa-with-SHA256
 30:44:02:20:37:f0:f7:f7:4a:b4:8e:8f:64:72:e4:d1:31:9f:
 a1:36:c5:5d:f3:42:4c:24:37:75:cf:b6:55:b0:66:1b:6e:63:
 02:20:39:18:81:f8:6c:86:3a:57:74:05:cc:99:6c:d9:dc:6a:
 a2:20:98:4c:66:a1:97:d1:c7:ea:42:b4:01:1a:f7:b2

Then I call the APIs as described in my first email to use them:


ctx = SSL_CTX_new(TLS_method());

status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);
status = SSL_CTX_use_certificate_file(ctx, ,,SSL_FILETYPE_PEM);


// Verify the cert and key are a pair
status = SSL_CTX_check_private_key(ctx);

Then call the APIs to set the curves and allow the server to pick the 
appropriate curve for the client:


status = SSL_CTX_set1_curves_list(ctx, "P-521:P-384:P-256");
status = SSL_CTX_set_ecdh_auto(ctx, 1);

That should be it, right? The EC parameters file has been used to generate the 
private key, it does not need to be read in by an API call.

With the steps above, I get a successful TLS connecti

Re: Questions about using Elliptic Curve ciphers in OpenSSL

[Jason Schultz]

Thank you for your response Thulasi, this helped. I'm posting this back to the 
OpenSSL users list in case it helps anyone else, and in case anyone can help 
with my additional questions. While waiting for responses, I've been able to 
find out how my certificate and keys were generated. I'd like to walk through 
that to hopefully verify I'm handling things correctly.

First, here is how my EC parameters file was generated:

openssl ecparam -name prime256v1 -genkey -out myecparamsfile.pem

And the resulting file:


M640A-SAIL:/etc/ssl # openssl ecparam -in myecparamsfile.pem -text

ASN1 OID: prime256v1

NIST CURVE: P-256

-BEGIN EC PARAMETERS-

BggqhkjOPQMBBw==

-END EC PARAMETERS-


 # openssl ecparam -in myecparamsfile.pem -text

ASN1 OID: prime256v1

NIST CURVE: P-256

-BEGIN EC PARAMETERS-

BggqhkjOPQMBBw==

-END EC PARAMETERS-

Is this good so far? Do I need the -genkey?

Then I take this file and use it when I generate my certificate and private key 
pair, here is the openssl command I used:

openssl req -nodes -sha256 -newkey ec:/etc/ssl/private/myecparamsfile.pem 
-keyout mykeyout.pem -new -out mycertfileout.pem -config /etc/ssl/openssl.cnf 
-x509 -days 365 -outform pem
Generating a EC private key
writing new private key to 'mykeyout.pem'


And the resulting key:

# cat mykeyout.pem
-BEGIN PRIVATE KEY-
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgbfUwVhomun9Q5IAY
xTOAn+sDoXZ+k4UWkvUyfshPBJ6hRANCAAQsakFVUTV4JmfVJH31XOvHVhhBodnV
8evYCJSd2Jgo4uOomCSh3oekKL+Tia+LOmynygfvmneOX2YadoNr9uzH
-END PRIVATE KEY-

# openssl ec -noout -text -in mykeyout.pem
read EC key
Private-Key: (256 bit)
priv:
6d:f5:30:56:1a:26:ba:7f:50:e4:80:18:c5:33:80:
9f:eb:03:a1:76:7e:93:85:16:92:f5:32:7e:c8:4f:
04:9e
pub:
04:2c:6a:41:55:51:35:78:26:67:d5:24:7d:f5:5c:
eb:c7:56:18:41:a1:d9:d5:f1:eb:d8:08:94:9d:d8:
98:28:e2:e3:a8:98:24:a1:de:87:a4:28:bf:93:89:
af:8b:3a:6c:a7:ca:07:ef:9a:77:8e:5f:66:1a:76:
83:6b:f6:ec:c7
ASN1 OID: prime256v1
NIST CURVE: P-256

And certificate:

M740A-PMM1:/etc/ssl # openssl x509 -text -in mycertfileout.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
e2:2f:c6:e4:bf:f1:de:20
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=NY, L=Loc, O=Org, OU=test, CN=My 
Name/emailAddress=t...@example.com
Validity
Not Before: Feb 13 16:11:39 2020 GMT
Not After : Feb 12 16:11:39 2021 GMT
Subject: C=US, ST=NY, L=Loc, O=Org, OU=test, CN=My 
Name/emailAddress=t...@example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:2c:6a:41:55:51:35:78:26:67:d5:24:7d:f5:5c:
eb:c7:56:18:41:a1:d9:d5:f1:eb:d8:08:94:9d:d8:
98:28:e2:e3:a8:98:24:a1:de:87:a4:28:bf:93:89:
af:8b:3a:6c:a7:ca:07:ef:9a:77:8e:5f:66:1a:76:
83:6b:f6:ec:c7
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Subject Key Identifier:
D6:8A:F3:3B:4E:A1:F8:F8:34:C1:1B:7A:EC:BF:9B:58:7F:68:4A:D9
X509v3 Authority Key Identifier:

keyid:D6:8A:F3:3B:4E:A1:F8:F8:34:C1:1B:7A:EC:BF:9B:58:7F:68:4A:D9

X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: ecdsa-with-SHA256
 30:44:02:20:37:f0:f7:f7:4a:b4:8e:8f:64:72:e4:d1:31:9f:
 a1:36:c5:5d:f3:42:4c:24:37:75:cf:b6:55:b0:66:1b:6e:63:
 02:20:39:18:81:f8:6c:86:3a:57:74:05:cc:99:6c:d9:dc:6a:
 a2:20:98:4c:66:a1:97:d1:c7:ea:42:b4:01:1a:f7:b2

Then I call the APIs as described in my first email to use them:


ctx = SSL_CTX_new(TLS_method());

status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);
status = SSL_CTX_use_certificate_file(ctx, ,,SSL_FILETYPE_PEM);


// Verify the cert and key are a pair
status = SSL_CTX_check_private_key(ctx);

Then call the APIs to set the curves and allow the server to pick the 
appropriate curve for the client:


status = SSL_CTX_set1_curves_list(ctx, "P-521:P-384:P-256");
status = SSL_CTX_set_ecdh_auto(ctx, 1);

That should be it, right? The EC parameters file has been used to generate the 
private key, it does not need to be read in by an API call.

With the steps above, I get a successful TLS connection from a client using 
ECDHE-ECDSA-AES256-GCM-SHA384.

And yes, I think my main confusion was on what to do with the DH parameters 
file. I thought using ECDHE key exchange was similar to DSA with DH. With 
ECDHE, I don't need to read in a parameters file at all.

If there's anything wrong above, please let me know, otherwise, thanks for all 
the help!



From: Thulasi Goriparthi 
Sent: Wednesday, February 12, 2020 8:29 AM
To: jetso...@hotmail.com 
Cc: rs...@akamai.com 
Subject: Re: Questions about using Elliptic Curve ciphers 

Re: Questions about using Elliptic Curve ciphers in OpenSSL

[Jason Schultz]

Rich-

Thanks for your reply. At this point I'm 99% sure I have ECDH with RSA working. 
My question in the previous post was just to confirm. But I have my RSA cert 
and key pair, and a client can successfully connect to my server using 
ECDHE_RSA* ciphers.

My questions are more related to ECDSA. For example, you said "just load your 
ECDSA cert", which is easy enough. My question is, is that all I need? For 
example, with DSA (which we don't really use anymore), I also needed a DH 
parameters file, which I read in with PEM_read_DHparams(). Do I need to do 
something similar with "EC params" or "ECDSA params"? I've seen references to 
both, and I'm not sure if and when I need them.

As I pointed out, it looks like there are "EC PARAMETERS" in my private key 
file. Are these needed? If so, how and when do I use them? Or do I need them in 
a separate file?




From: Salz, Rich 
Sent: Tuesday, February 11, 2020 4:37 PM
To: Jason Schultz ; openssl-users@openssl.org 

Subject: Re: Questions about using Elliptic Curve ciphers in OpenSSL


The first thing I would suggest is to separate ECDH, the session key exchange, 
from ECDSA, the signature.  Try to make ECDH with RSA work.  Then just load 
your ECDSA cert; you can load one cert of each type (RSA DSA) and the runtime 
will figure out what to do, depending on what the client offers.

Re: Questions about using Elliptic Curve ciphers in OpenSSL

[Jason Schultz]

Anyone have any advice on Elliptic Curve?

Thanks in advance.


From: openssl-users  on behalf of Jason 
Schultz 
Sent: Friday, February 7, 2020 2:58 AM
To: openssl-users@openssl.org 
Subject: Questions about using Elliptic Curve ciphers in OpenSSL


I’m somewhat confused as to what I need to do to use ECDHE ciphers 
(ECDHE-ECDSA-AES128-SHA256, ECDHE-ECDSA-AES256-GCM-SHA384, etc). I’m hoping 
this list can help, or at least point me to a good tutorial somewhere. A lot of 
the information I’ve looked at is from the following links:



https://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations



https://crypto.stackexchange.com/questions/19452/static-dh-static-ecdh-certificate-using-openssl



I’m only looking at getting something set up for testing for now; I have a 
self-signed certificate and a private key. Here is the certificate, with some 
info stripped (I didn’t create it so I don’t have the exact commands used):



Certificate:

Data:

Version: 3 (0x2)

Serial Number:

e7:64:34:3c:f2:b4:f5:cc

Signature Algorithm: ecdsa-with-SHA256

Issuer: C=US, ST=MyState, L=City, O=Org, OU=Dept, 
CN=MyCN/emailAddress=m...@example.com

Validity

Not Before: Jan 29 20:11:44 2020 GMT

Not After : Jan 28 20:11:44 2021 GMT

Subject: C=US, ST= MyState, L=City, O=Org, OU=Dept, 
CN=MyCN/emailAddress=m...@example.com

Subject Public Key Info:

Public Key Algorithm: id-ecPublicKey

Public-Key: (256 bit)

pub:

04:1f:07:e7:ea:09:b4:94:3e:a9:0b:c4:c6:d2:65:

31:db:4c:9c:33:9c:cd:fb:bd:f8:b1:0e:8e:69:5c:

74:cd:8d:98:0c:67:09:fb:1d:01:9f:f6:88:d4:02:

89:9d:66:78:ff:ce:34:09:e7:05:cc:63:1f:53:07:

58:68:82:a4:3e

ASN1 OID: prime256v1

NIST CURVE: P-256

X509v3 extensions:

X509v3 Subject Key Identifier:

DA:B7:A7:5A:16:85:40:61:36:D7:37:5E:AF:BE:E4:90:80:05:C7:FA

X509v3 Authority Key Identifier:


keyid:DA:B7:A7:5A:16:85:40:61:36:D7:37:5E:AF:BE:E4:90:80:05:C7:FA



X509v3 Basic Constraints:

CA:TRUE

Signature Algorithm: ecdsa-with-SHA256

 30:45:02:21:00:bc:9c:cb:f1:ca:30:24:d3:7e:86:b4:d4:6f:

 f6:5a:3c:ab:c2:8d:24:b5:bc:03:b2:f9:55:74:0d:5d:cc:2c:

 11:02:20:56:f8:05:4d:88:e6:35:ab:7b:db:01:02:1c:3d:ae:

 ab:5d:5a:86:61:5b:e5:2d:1a:3f:4d:bf:5b:ea:12:c2:50





I also didn’t generate the private key, but I’ll dump some info on it here, 
again to make sure it looks OK. It’s also part of the equation that I’m not 
100% sure about (if my private key is set up correctly). This is a 
non-production key, used only for initial testing:



---:/etc/ssl # openssl ec -in private/mykey.pem -text

read EC key

Private-Key: (256 bit)

priv:

00:96:f8:5b:9d:a3:fb:3d:27:de:01:75:54:0f:51:

69:38:d1:8f:2d:62:19:80:67:14:4a:da:1e:b5:d8:

57:8f:e8

pub:

04:1f:07:e7:ea:09:b4:94:3e:a9:0b:c4:c6:d2:65:

31:db:4c:9c:33:9c:cd:fb:bd:f8:b1:0e:8e:69:5c:

74:cd:8d:98:0c:67:09:fb:1d:01:9f:f6:88:d4:02:

89:9d:66:78:ff:ce:34:09:e7:05:cc:63:1f:53:07:

58:68:82:a4:3e

ASN1 OID: prime256v1

NIST CURVE: P-256

writing EC key

-BEGIN EC PRIVATE KEY-

MHcCAQEEIJb4W52j+z0n3gF1VA9RaTjRjy1iGYBnFEraHrXYV4/ooAoGCCqGSM49

AwEHoUQDQgAEHwfn6gm0lD6pC8TG0mUx20ycM5zN+734sQ6OaVx0zY2YDGcJ+x0B

n/aI1AKJnWZ4/840CecFzGMfUwdYaIKkPg==

-END EC PRIVATE KEY-



---:/etc/ssl # openssl ec -in private/mykey.pem -text -param_out

read EC key

Private-Key: (256 bit)

priv:

00:96:f8:5b:9d:a3:fb:3d:27:de:01:75:54:0f:51:

69:38:d1:8f:2d:62:19:80:67:14:4a:da:1e:b5:d8:

57:8f:e8

pub:

04:1f:07:e7:ea:09:b4:94:3e:a9:0b:c4:c6:d2:65:

31:db:4c:9c:33:9c:cd:fb:bd:f8:b1:0e:8e:69:5c:

74:cd:8d:98:0c:67:09:fb:1d:01:9f:f6:88:d4:02:

89:9d:66:78:ff:ce:34:09:e7:05:cc:63:1f:53:07:

58:68:82:a4:3e

ASN1 OID: prime256v1

NIST CURVE: P-256

writing EC key

-BEGIN EC PARAMETERS-

BggqhkjOPQMBBw==

-END EC PARAMETERS-



For my server code, the setup I use is very similar to if I was using an RSA 
certificate/key pair; setting up a CTX and calling the appropriate APIs for 
specifying the private key and certificate. Pseudocode:



ctx = SSL_CTX_new(TLS_method());



status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);

status = SSL_CTX_use_certificate_file(ctx, ,,SSL_FILETYPE_PEM);



// Verify the cert and key are a pair

status = SSL_CTX_check_private_key(ctx);



I do some validation of the certificate, the code for which I’ll skip as I 
don’t think it’s important here. I also set the protocol version I support with 
SSL_CTX_set_max_proto_version() and call SSL_CTX_set_cipher_list() to set the 
ciphers the server supports. The ciphers include the following

Questions about using Elliptic Curve ciphers in OpenSSL

[Jason Schultz]

I’m somewhat confused as to what I need to do to use ECDHE ciphers 
(ECDHE-ECDSA-AES128-SHA256, ECDHE-ECDSA-AES256-GCM-SHA384, etc). I’m hoping 
this list can help, or at least point me to a good tutorial somewhere. A lot of 
the information I’ve looked at is from the following links:



https://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations



https://crypto.stackexchange.com/questions/19452/static-dh-static-ecdh-certificate-using-openssl



I’m only looking at getting something set up for testing for now; I have a 
self-signed certificate and a private key. Here is the certificate, with some 
info stripped (I didn’t create it so I don’t have the exact commands used):



Certificate:

Data:

Version: 3 (0x2)

Serial Number:

e7:64:34:3c:f2:b4:f5:cc

Signature Algorithm: ecdsa-with-SHA256

Issuer: C=US, ST=MyState, L=City, O=Org, OU=Dept, 
CN=MyCN/emailAddress=m...@example.com

Validity

Not Before: Jan 29 20:11:44 2020 GMT

Not After : Jan 28 20:11:44 2021 GMT

Subject: C=US, ST= MyState, L=City, O=Org, OU=Dept, 
CN=MyCN/emailAddress=m...@example.com

Subject Public Key Info:

Public Key Algorithm: id-ecPublicKey

Public-Key: (256 bit)

pub:

04:1f:07:e7:ea:09:b4:94:3e:a9:0b:c4:c6:d2:65:

31:db:4c:9c:33:9c:cd:fb:bd:f8:b1:0e:8e:69:5c:

74:cd:8d:98:0c:67:09:fb:1d:01:9f:f6:88:d4:02:

89:9d:66:78:ff:ce:34:09:e7:05:cc:63:1f:53:07:

58:68:82:a4:3e

ASN1 OID: prime256v1

NIST CURVE: P-256

X509v3 extensions:

X509v3 Subject Key Identifier:

DA:B7:A7:5A:16:85:40:61:36:D7:37:5E:AF:BE:E4:90:80:05:C7:FA

X509v3 Authority Key Identifier:


keyid:DA:B7:A7:5A:16:85:40:61:36:D7:37:5E:AF:BE:E4:90:80:05:C7:FA



X509v3 Basic Constraints:

CA:TRUE

Signature Algorithm: ecdsa-with-SHA256

 30:45:02:21:00:bc:9c:cb:f1:ca:30:24:d3:7e:86:b4:d4:6f:

 f6:5a:3c:ab:c2:8d:24:b5:bc:03:b2:f9:55:74:0d:5d:cc:2c:

 11:02:20:56:f8:05:4d:88:e6:35:ab:7b:db:01:02:1c:3d:ae:

 ab:5d:5a:86:61:5b:e5:2d:1a:3f:4d:bf:5b:ea:12:c2:50





I also didn’t generate the private key, but I’ll dump some info on it here, 
again to make sure it looks OK. It’s also part of the equation that I’m not 
100% sure about (if my private key is set up correctly). This is a 
non-production key, used only for initial testing:



---:/etc/ssl # openssl ec -in private/mykey.pem -text

read EC key

Private-Key: (256 bit)

priv:

00:96:f8:5b:9d:a3:fb:3d:27:de:01:75:54:0f:51:

69:38:d1:8f:2d:62:19:80:67:14:4a:da:1e:b5:d8:

57:8f:e8

pub:

04:1f:07:e7:ea:09:b4:94:3e:a9:0b:c4:c6:d2:65:

31:db:4c:9c:33:9c:cd:fb:bd:f8:b1:0e:8e:69:5c:

74:cd:8d:98:0c:67:09:fb:1d:01:9f:f6:88:d4:02:

89:9d:66:78:ff:ce:34:09:e7:05:cc:63:1f:53:07:

58:68:82:a4:3e

ASN1 OID: prime256v1

NIST CURVE: P-256

writing EC key

-BEGIN EC PRIVATE KEY-

MHcCAQEEIJb4W52j+z0n3gF1VA9RaTjRjy1iGYBnFEraHrXYV4/ooAoGCCqGSM49

AwEHoUQDQgAEHwfn6gm0lD6pC8TG0mUx20ycM5zN+734sQ6OaVx0zY2YDGcJ+x0B

n/aI1AKJnWZ4/840CecFzGMfUwdYaIKkPg==

-END EC PRIVATE KEY-



---:/etc/ssl # openssl ec -in private/mykey.pem -text -param_out

read EC key

Private-Key: (256 bit)

priv:

00:96:f8:5b:9d:a3:fb:3d:27:de:01:75:54:0f:51:

69:38:d1:8f:2d:62:19:80:67:14:4a:da:1e:b5:d8:

57:8f:e8

pub:

04:1f:07:e7:ea:09:b4:94:3e:a9:0b:c4:c6:d2:65:

31:db:4c:9c:33:9c:cd:fb:bd:f8:b1:0e:8e:69:5c:

74:cd:8d:98:0c:67:09:fb:1d:01:9f:f6:88:d4:02:

89:9d:66:78:ff:ce:34:09:e7:05:cc:63:1f:53:07:

58:68:82:a4:3e

ASN1 OID: prime256v1

NIST CURVE: P-256

writing EC key

-BEGIN EC PARAMETERS-

BggqhkjOPQMBBw==

-END EC PARAMETERS-



For my server code, the setup I use is very similar to if I was using an RSA 
certificate/key pair; setting up a CTX and calling the appropriate APIs for 
specifying the private key and certificate. Pseudocode:



ctx = SSL_CTX_new(TLS_method());



status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);

status = SSL_CTX_use_certificate_file(ctx, ,,SSL_FILETYPE_PEM);



// Verify the cert and key are a pair

status = SSL_CTX_check_private_key(ctx);



I do some validation of the certificate, the code for which I’ll skip as I 
don’t think it’s important here. I also set the protocol version I support with 
SSL_CTX_set_max_proto_version() and call SSL_CTX_set_cipher_list() to set the 
ciphers the server supports. The ciphers include the following:



ECDHE_RSA_WITH_AES_128_CBC_SHA256

ECDHE_RSA_WITH_AES_128_GCM_SHA256

ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

ECDHE_RSA_WITH_AES_256_CBC_SHA384

ECDHE_RSA_WITH_AES_256_GCM_SHA384

ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

Re: sk_X509_OBJECT_num()

[Jason Schultz]

That makes sense. Thanks to everyone for the responses.

Jason



From: Dave Coombs 
Sent: Wednesday, November 13, 2019 5:30 PM
To: Jason Schultz 
Cc: openssl-users@openssl.org 
Subject: Re: sk_X509_OBJECT_num()

Hi,

They're macros, defined in SKM_DEFINE_STACK_OF() in safestack.h.  If you 
DEFINE_STACK_OF(Foo), you'll automatically end up with a sk_Foo_num() macro.

Cheers,
  -Dave


> On Nov 13, 2019, at 12:20, Jason Schultz  wrote:
>
> Hello-
>
> I am updating my Linux application from using OpenSSL 1.0.2 to 1.1.1 in 
> preparation for OpenSSL 3.0 (and of course the EOL of 1.0.2). I'm confused 
> about the function in the subject line as well as other, related sk_X509_* 
> functions.
>
> My code has always used these functions, and currently my code compiles and 
> runs successfully against 1.1.1. I was sort of doing an audit of my code, 
> evaluating the API calls that have changed vs not changed when I noticed 
> these functions. I searched for them in the 1.1.1 source. They don't exist, 
> except where called in x509_lu.c. In the 1.0.2 code base, they are called in 
> the same file, as well as are defined in a header, 
> /include/openssl/safestack.h.
>
> My question is, how are those symbols in my application being resolved since 
> they are no longer found in the safestack.h header file?
>
> My system previously had OpenSSL 1.0.2 installed when I installed 1.1.1, but 
> I don't think I have any old headers around that are being found when I 
> compile and link. But for some reason this works. They obviously work within 
> the OpenSSL 1.1.1 code also.
>
> I'm thinking I could be missing something basic about the compile/link 
> process that explains this. Any ideas?
>
> Thanks in advance.

sk_X509_OBJECT_num()

[Jason Schultz]

Hello-

I am updating my Linux application from using OpenSSL 1.0.2 to 1.1.1 in 
preparation for OpenSSL 3.0 (and of course the EOL of 1.0.2). I'm confused 
about the function in the subject line as well as other, related sk_X509_* 
functions.

My code has always used these functions, and currently my code compiles and 
runs successfully against 1.1.1. I was sort of doing an audit of my code, 
evaluating the API calls that have changed vs not changed when I noticed these 
functions. I searched for them in the 1.1.1 source. They don't exist, except 
where called in x509_lu.c. In the 1.0.2 code base, they are called in the same 
file, as well as are defined in a header, /include/openssl/safestack.h.

My question is, how are those symbols in my application being resolved since 
they are no longer found in the safestack.h header file?

My system previously had OpenSSL 1.0.2 installed when I installed 1.1.1, but I 
don't think I have any old headers around that are being found when I compile 
and link. But for some reason this works. They obviously work within the 
OpenSSL 1.1.1 code also.

I'm thinking I could be missing something basic about the compile/link process 
that explains this. Any ideas?

Thanks in advance.

Re: OpenSSL server sending certificate chain(inc. root cert) during handshake

[Jason Schultz]

Right, I realize it doesn't have to be sent, my questions are why is it sent 
and is there a way to force OpenSSL to not send it?

You may have answered the first question as to "why?". But is OpenSSL doing 
this just to make problems easier to diagnose? Are there other reasons?

More importantly, can I force OpenSSL to not send the root cert?

Thanks,

Jason



From: Sam Roberts 
Sent: Friday, May 31, 2019 7:32 PM
To: Jason Schultz
Cc: openssl-users@openssl.org
Subject: Re: OpenSSL server sending certificate chain(inc. root cert) during 
handshake

The root cert is not used for validation, so it doesn't have to be
sent. However, sending it does no harm, and it is useful for humans
who are attempting to diagnose problems, it allows them to see what
what root cert they are expected to have locally for sucessful cert
chain validation.

OpenSSL server sending certificate chain(inc. root cert) during handshake

[Jason Schultz]

I believe this behavior is common among all supported versions of OpenSSL, but 
most of my testing has been with OpenSSL 1.0.2, the latest LTS release.

My application using OpenSSL is acting as a server. I have a server certificate 
configured that has been signed by a self-signed/root certificate, so the chain 
is only the server certificate and the root certificate. The certificates were 
created using OpenSSL, for non-production use only. The server application is 
calling SSL_CTX_use_certificate_file() to load the server cert, residing in 
/etc/ssl/certs.

Depending on what's in /etc/ssl/certs, the handshake behavior will show 1 of 2 
things:


  1.  If only the server certificate (and NOT the self-signed root cert) is in 
/etc/ssl/certs/, only the server certificate will be presented in the handshake.
  2.  If the server AND self-signed root certificates are in /etc/ssl/certs/, 
the entire chain will be presented during the handshake.

My questions deal with #2: Why does OpenSSL include the root cert in the 
certificate chain? Will the root cert be included in the chain any time it's in 
the same directory as the server cert? Is there a way, via API call, 
configuration, etc, to force OpenSSL to NOT send the root certificate as part 
of the chain in this case? Or is there something more basic I'm missing? 
Googling for answers has not proved fruitful as there are a lot of results, 
none of which pertain to my situation...although my google fu may be lacking.

Thanks in advance.

Re: X509_STORE_CTX_get1_certs

[Jason Schultz]

I see. Can anyone summarize what X509_STORE_CTX_get1_certs() is doing so I can 
make sure my understanding of it is correct?

Thanks.


From: openssl-users  on behalf of Viktor 
Dukhovni 
Sent: Wednesday, May 29, 2019 8:21 PM
To: openssl-users@openssl.org
Subject: Re: X509_STORE_CTX_get1_certs

On Wed, May 29, 2019 at 07:44:26PM +, Jason Schultz wrote:

> It looks like this function is available in OpenSSL 1.1.1 (not available
> in 1.0.2) and I think I need to use it, but I can't find documentation for
> it anywhere.

In 1.0.2 it was called X509_STORE_get1_certs().

> Is this an over site, or am I missing something obvious?

It has not yet been documented.

--
Viktor.

X509_STORE_CTX_get1_certs

[Jason Schultz]

It looks like this function is available in OpenSSL 1.1.1 (not available in 
1.0.2) and I think I need to use it, but I can't find documentation for it 
anywhere.

Is this an over site, or am I missing something obvious?

Thanks,

Jason

Re: [openssl-users] FIPS Module for OpenSSL 1.1.1

[Jason Schultz]

Thanks for your response. A follow up question based on Matt Caswell's blog 
post: Does the blog post imply that the next FIPS module will be based on 
OpenSSL 3.0? Or is 3.0 a longer term thing and the next FIPS module will be for 
OpenSSL 1.1.1?

Thanks.



From: openssl-users  on behalf of Paul Dale 

Sent: Wednesday, February 13, 2019 1:24 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] FIPS Module for OpenSSL 1.1.1


The answer hasn’t changed: there is no firm date.

Progress is being made however.





Pauli

--

Oracle

Dr Paul Dale | Cryptographer | Network Security & Encryption

Phone +61 7 3031 7217

Oracle Australia



From: Jason Schultz [mailto:jetso...@hotmail.com]
Sent: Wednesday, 13 February 2019 9:39 AM
To: openssl-users@openssl.org
Subject: [openssl-users] FIPS Module for OpenSSL 1.1.1



Just wondering if there is a time frame for the availability of the FIPS Module 
for OpenSSL 1.1.1? Q3 2019? Q4?



I realize this has been asked before, but the most recent answer I found was 
from several months ago, so I thought there might be new information.



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

[openssl-users] FIPS Module for OpenSSL 1.1.1

[Jason Schultz]

Just wondering if there is a time frame for the availability of the FIPS Module 
for OpenSSL 1.1.1? Q3 2019? Q4?

I realize this has been asked before, but the most recent answer I found was 
from several months ago, so I thought there might be new information.

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

Re: [openssl-users] OpenSSL FIPS Object Module 2.0 on CD

[Jason Schultz]

Just curious, but does this satisfy Section 6.6 of the User Guide, since the CD 
does not come directly from the OpenSSL Foundation?


I don't have a huge need to know, just curious since as with a lot of issues 
regarding FIPS, no answer would surprise me.




From: openssl-users  on behalf of Mark 
Minnoch 
Sent: Wednesday, June 20, 2018 4:33 PM
To: openssl-users@openssl.org
Subject: [openssl-users] OpenSSL FIPS Object Module 2.0 on CD

If you are looking for a copy of the OpenSSL FIPS Object Module (versions 2.0 
to 2.0.16) delivered to you on CD, then please send an email to 
c...@keypair.us with your shipping address.

We will send you a copy of the original OpenSSL FOM CD.

For details, see: https://keypair.us/2018/05/cd/

Mark J. Minnoch
Co-Founder, CISSP, CISA
KeyPair Consulting
+1 (805) 550-3231 mobile
https://KeyPair.us
https://www.linkedin.com/in/minnoch

We expertly guide technology companies in achieving their FIPS 140 goals

New blog post: You Have Your FIPS Certificate. Now 
What?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Help with ssl error

[Jason Schultz]

>From the original question, it appears the server here only supports two 
>cipher suites:

RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA

This would explain the alert 71, which is the sent because there are no cipher 
suites in common.


From: openssl-users  on behalf of Viktor 
Dukhovni 
Sent: Tuesday, April 18, 2017 5:06 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Help with ssl error

On Tue, Apr 18, 2017 at 11:17:48AM -0400, Joseph Southwell wrote:

> It doesn’t look like it requested a client certificate to me.

Correct, the server alert was returned immediately in response
to the TLS ClientHello.

> $ openssl s_client -state -msg -connect ftp.echannel.banksys.be:16370 
> -starttls ftp
> CONNECTED(0104)
> SSL_connect:before SSL initialization
> >>> ??? [length 0005]
> 16 03 01 00 ab
> >>> TLS 1.2Handshake [length 00ab], ClientHello
> 01 00 00 a7 03 03 b1 9d 3b a7 9d c4 3f de 8a 20
> 59 07 1f d7 50 3e 20 cf 92 cb a6 7d 94 1d 2f b2
> 81 c0 d9 12 1c f9 00 00 38 c0 2c c0 30 00 9f cc
> a9 cc a8 cc aa c0 2b c0 2f 00 9e c0 24 c0 28 00
> 6b c0 23 c0 27 00 67 c0 0a c0 14 00 39 c0 09 c0
> 13 00 33 00 9d 00 9c 00 3d 00 3c 00 35 00 2f 00
> ff 01 00 00 46 00 0b 00 04 03 00 01 02 00 0a 00
> 0a 00 08 00 1d 00 17 00 19 00 18 00 23 00 00 00
> 0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05
> 03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02
> 02 02 03 00 16 00 00 00 17 00 00
> SSL_connect:SSLv3/TLS write client hello
> <<< ??? [length 0005]
> 15 03 02 00 02
> <<< TLS 1.2Alert [length 0002], fatal insufficient_security
> 02 47
> SSL3 alert read:fatal:insufficient security
> SSL_connect:error in SSLv3/TLS write client hello
> 3252:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient 
> security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71

The ClientHello decodes via tshark as:

Secure Sockets Layer
SSL Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 171
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 167
Version: TLS 1.2 (0x0303)
Random
GMT Unix Time: Jun  5, 2064 16:07:35.0 AEST
Random Bytes: 
9dc43fde8a2059071fd7503e20cf92cba67d941d2fb281c0...
Session ID Length: 0
Cipher Suites Length: 56
Cipher Suites (28 suites)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
Cipher Suite: Unknown (0xcca9)
Cipher Suite: Unknown (0xcca8)
Cipher Suite: Unknown (0xccaa)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
Extensions Length: 70
Extension: ec_point_formats
Type: ec_point_formats (0x000b)
Length: 4
EC point formats Length: 3
Elliptic curves point formats (3)
EC point 

[openssl-users] Building 1.0.2g with "no-idea"

[Jason Schultz]

I am re-posting this (and another) message to the list as I was having email 
issues with the list and I posted an erroneous subject line, which may have 
deterred responses.

I have another question that was encountered at the same time as my previous 
one, but I believe it is two separate issues, so I created a different thread.

When building 1.0.2g and attempting to remove some ciphers at build time 
("no-idea"), I discovered that the Make scripting was attempting to build some 
of its files anyway:

[...]
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O2 -g 
-m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -std=gnu99 -Wa,--noexecstack -fomit-frame-pointer 
-DTERMIO -DPURIFY -DSSL_FORBID_ENULL -D_GNU_SOURCE -fstack-protector -Wall 
-Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
-DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM   -c -o e_bf.o e_bf.c
make[2]: *** No rule to make target `../../include/openssl/idea.h', needed by 
`e_idea.o'.  Stop.
make[2]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto/evp'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto'
make: *** [build_crypto] Error 1

It looks as though the "no-idea" removes some of the header files from the 
build, but then the make tries to compile the .c files anyway.

Has anyone else encountered this problem?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Build of 1.0.2g fails

[Jason Schultz]

Greetings. I am re-posing this message (as well as another message) to the list 
as I was having problems with my list membership when it was posted, and I also 
made a mistake in the subject line, which may have deterred some responses.

I'm having problems building OpenSSL, starting with 1.0.1g. The 
scenario is as follows.

I'm not sure when the problem was introduced; however, with the compiling-out 
of SSLv2 *by default* in -1.0.2g, that change has exacerbated this problem.  
(That is, instead of affecting only those who selected "no-ssl2", it now 
affects everyone *except* those that explicitly select "ssl2".)

First, the existing package runs a self-test during the package build process.  
One of those tests verifies SSL (ssl/ssltest.c), and another verifies SSL usage 
when FIPS is active (test/testfipsssl).  The code in ssl/ssltest.c has a 
section that detects if the requested encryption mechanism has been disabled at 
build time ("compiled out").  If this situation is detected, an "OK" status is 
returned so that the test driver can determine what to do.  When FIPS is 
compiled, configured, and enabled, calling the SSL verification from 
test/testfipsssl to verify SSLv2 or SSLv3 support should result in a "Fail" 
status since neither SSLv2 nor SSLv3 is supported with FIPS.  However, when the 
"no-sslv2" and/or "no-sslv3" build options are selected, neither mechanism gets 
compiled in, so the SSL verification test detects this and immediately returns 
"OK" status.  Since FIPS is compiled, configured, and enabled, a "Fail" status 
is expected by test/testfipsssl instead, so the "OK" status that is re
 ceived because the ciphers are not present is handled as a test failure 
thereby aborting the build.

To make the package build correctly with "no-sslv2" or "no-sslv3" specified, I 
had to add the following:

Index: ssl/ssltest.c
===
--- ssl/ssltest.c (revision 4068)
+++ ssl/ssltest.c (working copy)
@@ -1203,8 +1203,20 @@
 if (no_protocol) {
 fprintf(stderr, "Testing was requested for a disabled protocol. "
 "Skipping tests.\n");
+#ifdef OPENSSL_FIPS
+/*
+ * If FIPS is enabled, then neither SSLv2 nor SSLv3 are permitted 
anyway.
+ * In this case, the fact that one or both are compiled-out is a good 
thing,
+ * so we continue onward to return the expected error status instead.
+ */
+if (!fips_mode || !FIPS_mode_set(1) || !(ssl2 || ssl3)) {
+ret = 0;
+goto end;
+}
+#else
 ret = 0;
 goto end;
+#endif
 }

 if (!ssl2 && !ssl3 && !tls1 && !dtls1 && !dtls12 && number > 1 && !reuse 
&& !force) {

Is this a known problem? Is there a solution available?

Thanks in advance.

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

[openssl-users] Building 1.0.1g with "no-idea"

[Jason Schultz]

I have another question that was encountered at the same time as my previous 
one, but I believe it is two separate issues, so I created a different thread.

When building 1.0.2g and attempting to remove some ciphers at build time 
("no-idea"), I discovered that the Make scripting was attempting to build some 
of its files anyway:

[...]
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O2 -g 
-m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -std=gnu99 -Wa,--noexecstack -fomit-frame-pointer 
-DTERMIO -DPURIFY -DSSL_FORBID_ENULL -D_GNU_SOURCE -fstack-protector -Wall 
-Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
-DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM   -c -o e_bf.o e_bf.c
make[2]: *** No rule to make target `../../include/openssl/idea.h', needed by 
`e_idea.o'.  Stop.
make[2]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto/evp'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto'
make: *** [build_crypto] Error 1

It looks as though the "no-idea" removes some of the header files from the 
build, but then the make tries to compile the .c files anyway.

Has anyone else encountered this problem?

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

[openssl-users] Build of 1.0.1g fails

[Jason Schultz]

Greetings. I'm having problems building OpenSSL, starting with 1.0.1g. The 
scenario is as follows.

I'm not sure when the problem was introduced; however, with the compiling-out 
of SSLv2 *by default* in -1.0.2g, that change has exacerbated this problem.  
(That is, instead of affecting only those who selected "no-ssl2", it now 
affects everyone *except* those that explicitly select "ssl2".)

First, the existing package runs a self-test during the package build process.  
One of those tests verifies SSL (ssl/ssltest.c), and another verifies SSL usage 
when FIPS is active (test/testfipsssl).  The code in ssl/ssltest.c has a 
section that detects if the requested encryption mechanism has been disabled at 
build time ("compiled out").  If this situation is detected, an "OK" status is 
returned so that the test driver can determine what to do.  When FIPS is 
compiled, configured, and enabled, calling the SSL verification from 
test/testfipsssl to verify SSLv2 or SSLv3 support should result in a "Fail" 
status since neither SSLv2 nor SSLv3 is supported with FIPS.  However, when the 
"no-sslv2" and/or "no-sslv3" build options are selected, neither mechanism gets 
compiled in, so the SSL verification test detects this and immediately returns 
"OK" status.  Since FIPS is compiled, configured, and enabled, a "Fail" status 
is expected by test/testfipsssl instead, so the "OK" status that is re
 ceived because the ciphers are not present is handled as a test failure 
thereby aborting the build.

To make the package build correctly with "no-sslv2" or "no-sslv3" specified, I 
had to add the following:

Index: ssl/ssltest.c
===
--- ssl/ssltest.c (revision 4068)
+++ ssl/ssltest.c (working copy)
@@ -1203,8 +1203,20 @@
 if (no_protocol) {
 fprintf(stderr, "Testing was requested for a disabled protocol. "
 "Skipping tests.\n");
+#ifdef OPENSSL_FIPS
+/*
+ * If FIPS is enabled, then neither SSLv2 nor SSLv3 are permitted 
anyway.
+ * In this case, the fact that one or both are compiled-out is a good 
thing,
+ * so we continue onward to return the expected error status instead.
+ */
+if (!fips_mode || !FIPS_mode_set(1) || !(ssl2 || ssl3)) {
+ret = 0;
+goto end;
+}
+#else
 ret = 0;
 goto end;
+#endif
 }

 if (!ssl2 && !ssl3 && !tls1 && !dtls1 && !dtls12 && number > 1 && !reuse 
&& !force) {

Is this a known problem? Is there a solution available?

Thanks in advance.

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

Re: [openssl-users] Peer closing connection with a FIN without first sending a close_notify

[Jason Schultz]

Thanks for your response, Viktor. You views fall in line with our opinions on 
how the situation should be handled.
Any other opinions?

 Date: Mon, 20 Apr 2015 16:26:43 +
 From: openssl-us...@dukhovni.org
 To: openssl-users@openssl.org
 Subject: Re: [openssl-users] Peer closing connection with a FIN without first 
 sending a close_notify
 
 On Mon, Apr 20, 2015 at 03:03:37PM +, Jason Schultz wrote:
 
  We am seeing the following situation and are not quite sure the proper
  way to handle it, so I thought I'd solicit the mailing list. Our application
  is an FTP server using OpenSSL. The peer is a non-OpenSSL FTP client in
  active mode.  The problem comes in with how the FTP client handles closing
  the data connection after doing a put and transferring a file from client
  to our server. Instead of sending a close_notify, it closes the connection
  with a TCP FIN. 
 
 That's wrong.  This client snatches defeat from the jaws of victory,
 by failing to take advantage of the TLS shutdown facility to securely
 signal end of data.  Without SSL shutdown the data transfer is
 vulnerable to truncation attacks.
  
  On our server, calls to SSL_read() and SSL_get_error() indicate an
  SSL_ERROR_SYSCALL, which we treat as a protocol violation and abort the
  connection.  When the FTP implementation sees the abort, it tears down
  the connection and throws the file away.
 
 That's sensible default behaviour I think, but you may need
 work-arounds for broken clients.
 
  If we change our server to look for this specific case, and indicate a
  close to the FTP application instead of an abort, the FTP transfer completes
  successfully.
 
 Apply this work-around to as few clients as possible.
 
  This is where our questions arise. First of all, the FTP client's close
  without being preceded by a close_notify seems to be a violation of the
  protocol, and OpenSSL handles it as such.
 
 Correct.
 
  Does changing the way it's handled open up our application to truncation
  attacks?
 
 Yes.
 
  We have also read that this particular behavior is not unheard of in SSL
  implementations, and treating the TCP FIN as a proper way to close the
  connection as described above is OK.
 
 Only when the application-level protocol contains sufficient framing,
 to make additional framing in TLS redundant.  This is not the case
 in FTP in stream mode.  FTP in block mode can signal end of file via
 the block headers, and then TLS shutdown is not needed.  (I've never
 seen FTP used in block mode).
 
  Given the conflicting information we have seen, what is the opinion of
  the OpenSSL team?
 
 I don't speak for the team.  My opinion is that the client is broken
 unless it is using FTP in some manner that provides in-band file
 integrity.
 
 So any work-around may require client-specific configuration so as
 not to downgrade all clients.
 
 -- 
   Viktor.
 ___
 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] Peer closing connection with a FIN without first sending a close_notify

[Jason Schultz]

Greetings.
We am seeing the following situation and are not quite sure the proper way to 
handle it, so I thought I'd solicit the mailing list. Our application is an FTP 
server using OpenSSL. The peer is a non-OpenSSL FTP client in active mode.
The problem comes in with how the FTP client handles closing the data 
connection after doing a put and transferring a file from client to our server. 
Instead of sending a close_notify, it closes the connection with a TCP FIN. On 
our server, calls to SSL_read() and SSL_get_error() indicate an 
SSL_ERROR_SYSCALL, which we treat as a protocol violation and abort the 
connection. When the FTP implementation sees the abort, it tears down the 
connection and throws the file away.
Regarding SSL_ERROR_SYSCALL, the OpenSSL documentation says this:
Some I/O error occurred. The OpenSSL error queue may contain more information 
on the error. If the error queue is empty (i.e. ERR_get_error() returns 0), ret 
can be used to find out more about the error: If ret == 0, an EOF was observed 
that violates the protocol. If ret == -1, the underlying BIO reported an I/O 
error (for socket I/O on Unix systems, consult errno for details).
From this information, we determined we were seeing the case where 
ERR_get_error() returns 0, meaning an EOF was observed that violates the 
protocol; the FIN being sent without being preceded by a close_notify. If we 
change our server to look for this specific case, and indicate a close to the 
FTP application instead of an abort, the FTP transfer completes successfully.
This is where our questions arise. First of all, the FTP client's close without 
being preceded by a close_notify seems to be a violation of the protocol, and 
OpenSSL handles it as such. Does changing the way it's handled open up our 
application to truncation attacks?
We have also read that this particular behavior is not unheard of in SSL 
implementations, and treating the TCP FIN as a proper way to close the 
connection as described above is OK.
Given the conflicting information we have seen, what is the opinion of the 
OpenSSL team?
Thanks in advance.
  ___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] FIPS_module_version_text()

[Jason Schultz]

Is this function available to call in OpenSSL 1.0.1? I'm trying to call it from 
my application running a FIPS capable version of OpenSSL (everything else 
works, turning FIPS on, etc), but I include fips.h but I get a compile error 
saying the function was not declared.
I did find something in the CVS repository that says it was added to 1.1.0:
http://marc.info/?l=openssl-cvsm=130982270901165
I feel like I'm missing something obvious...
  ___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS_module_version_text()

[Jason Schultz]

Hmm. I am pretty sure I was linking against the FIPS capable OpenSSL but I will 
double check tomorrow to make sure I did it right. 

Thanks. 



 On Mar 10, 2015, at 7:28 PM, Dr. Stephen Henson st...@openssl.org wrote:
 
 On Tue, Mar 10, 2015, Jason Schultz wrote:
 
 Is this function available to call in OpenSSL 1.0.1? I'm trying to call it 
 from my application running a FIPS capable version of OpenSSL (everything 
 else works, turning FIPS on, etc), but I include fips.h but I get a compile 
 error saying the function was not declared.
 
 That's odd. I just compiled OpenSSL 1.0.1 and FIPS_module_version_text was
 present in libcrypto.so. Are you linking against the FIPS capable OpenSSL or
 the system supplied one?
 
 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 ___
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS_module_version_text()

[Jason Schultz]

I guess I didn't have the correct fips.h file in my include path when I 
couldn't get it to compile. But I don't think it will work for my purposes 
since if I install my application on another system, that entry point is not 
defined in libcrypto.so or libssl.so. 
Does anyone know if it's really going to be added to 1.1.0?

From: jetso...@hotmail.com
To: openssl-users@openssl.org
Subject: FIPS_module_version_text()
Date: Tue, 10 Mar 2015 16:01:53 +




Is this function available to call in OpenSSL 1.0.1? I'm trying to call it from 
my application running a FIPS capable version of OpenSSL (everything else 
works, turning FIPS on, etc), but I include fips.h but I get a compile error 
saying the function was not declared.
I did find something in the CVS repository that says it was added to 1.1.0:
http://marc.info/?l=openssl-cvsm=130982270901165
I feel like I'm missing something obvious...
  ___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

1.0.1i fails on make test

[Jason Schultz]

I've been trying to build the latest (1.0.1i) OpenSSL, and I'm having problems 
with the self-tests.
 
The steps I followed were the same steps I used to build a FIPS enabled 1.0.1h. 
I built the FIPS object module using the 2.0.6 ecp module without issue. When I 
attempt to build the FIPS capable OpenSSL, I did the following and got an error 
on the make test:
 
./config fips shared
make
make test
[...]
SEC2 curve secp160r1 -- Generator:
 x = 0x4A96B5688EF573284664698968C38BB913CBFC82
 y = 0x23A628553168947D59DCC912042351377AC5FB32
verify degree ... ok
verify group order  ok
long/negative scalar tests allowing precomputation ...ectest.c:260: ABORT
make[1]: *** [test_ec] Error 1
make[1]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.i1/test'
make: *** [tests] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.57104 (%build)
 
Looking into ectest.c (actually, it's crypto/ec/ectest.c with a sym-link), I 
can see the failure is in the following test code:
 
[...]
  fprintf(stdout, long/negative scalar tests );
for (i = 1; i = 2; i++)
{
const BIGNUM *scalars[6];
const EC_POINT *points[6];
 
fprintf(stdout, i == 1 ?
  allowing precomputation ...  :
  without precomputation ... );
if (!BN_set_word(n1, i)) ABORT;
/* If i == 1, P will be the predefined generator for which
 * EC_GROUP_precompute_mult has set up precomputation. */
if (!EC_POINT_mul(group, P, n1, NULL, NULL, ctx)) ABORT;
 
  if (!BN_one(n1)) ABORT;
  /* n1 = 1 - order */
  if (!BN_sub(n1, n1, order)) ABORT;
  if(!EC_POINT_mul(group, Q, NULL, P, n1, ctx)) ABORT;
  if (0 != EC_POINT_cmp(group, Q, P, ctx)) ABORT;
  /* n2 = 1 + order */
  if (!BN_add(n2, order, BN_value_one())) ABORT;
  if(!EC_POINT_mul(group, Q, NULL, P, n2, ctx)) ABORT;
  if (0 != EC_POINT_cmp(group, Q, P, ctx)) ABORT;
 
/* n2 = (1 - order) * (1 + order) = 1 - order^2 */
  if (!BN_mul(n2, n1, n2, ctx)) ABORT;
  if(!EC_POINT_mul(group, Q, NULL, P, n2, ctx)) ABORT;
  if (0 != EC_POINT_cmp(group, Q, P, ctx)) ABORT;
 
/* n2 = order^2 - 1 */
BN_set_negative(n2, 0);
if (!EC_POINT_mul(group, Q, NULL, P, n2, ctx)) ABORT;
/* Add P to verify the result. */
if (!EC_POINT_add(group, Q, Q, P, ctx)) ABORT;
if (!EC_POINT_is_at_infinity(group, Q)) ABORT;
 
/* Exercise EC_POINTs_mul, including corner cases. */
scalars[0] = n1; points[0] = Q; /* = infinity */
scalars[1] = n2; points[1] = P; /* = -P */
scalars[2] = n1; points[2] = Q; /* = infinity */
scalars[3] = n2; points[3] = Q; /* = infinity */
scalars[4] = n1; points[4] = P; /* = P */
scalars[5] = n2; points[5] = Q; /* = infinity */
if (!EC_POINTs_mul(group, Q, NULL, 5, points, scalars, ctx)) ABORT;
if (!EC_POINT_is_at_infinity(group, Q)) ABORT;  ---*** This test is the 
error
}
  fprintf(stdout, ok\n);
[...]
 
It is failing the test pointed out above (which is line 260) that triggers the 
abort.
 
Interestingly enough, there were a number of changes in this area, and the 
failing code is part of the new code.  Here's the .diff for this file:
 
diff -rwBN -U3 openssl-1.0.1h/crypto/ec/ectest.c 
openssl-1.0.1i/crypto/ec/ectest.c
--- openssl-1.0.1h/crypto/ec/ectest.c 2014-06-05 09:44:33.0 +
+++ openssl-1.0.1i/crypto/ec/ectest.c 2014-08-06 21:10:56.0 +
@@ -199,6 +199,7 @@
  EC_POINT *P = EC_POINT_new(group);
  EC_POINT *Q = EC_POINT_new(group);
  BN_CTX *ctx = BN_CTX_new();
+ int i;
 
  n1 = BN_new(); n2 = BN_new(); order = BN_new();
  fprintf(stdout, verify group order ...);
@@ -212,7 +213,20 @@
  if (!EC_POINT_mul(group, Q, order, NULL, NULL, ctx)) ABORT;
  if (!EC_POINT_is_at_infinity(group, Q)) ABORT;
  fprintf(stdout,  ok\n);
- fprintf(stdout, long/negative scalar tests ... );
+ fprintf(stdout, long/negative scalar tests );
+for (i = 1; i = 2; i++)
+   {
+   const BIGNUM *scalars[6];
+   const EC_POINT *points[6];
+
+   fprintf(stdout, i == 1 ?
+ allowing precomputation ...  :
+ without precomputation ... );
+   if (!BN_set_word(n1, i)) ABORT;
+   /* If i == 1, P will be the predefined generator for which
+* EC_GROUP_precompute_mult has set up precomputation. */
+   if (!EC_POINT_mul(group, P, n1, NULL, NULL, ctx)) ABORT;
+
  if (!BN_one(n1)) ABORT;
  /* n1 = 1 - order */
  if (!BN_sub(n1, n1, order)) ABORT;
@@ -222,11 +237,31 @@
  if (!BN_add(n2, order, BN_value_one())) ABORT;
  if(!EC_POINT_mul(group, Q, NULL, P, n2, ctx)) ABORT;
  if (0 != EC_POINT_cmp(group, Q, P, ctx)) ABORT;
- /* n2 = (1 - order) * (1 + order) */
+
+   /* n2 = (1 - order) * (1 + order) = 1 - order^2 */
  if (!BN_mul(n2, n1, n2, ctx)) ABORT;
  if(!EC_POINT_mul(group, Q, NULL, P, n2, ctx)) ABORT;
  if (0 != EC_POINT_cmp(group, Q, P, ctx)) ABORT;
+
+   /* n2 = order^2 - 1 */
+   BN_set_negative(n2, 0);
+   if (!EC_POINT_mul(group, Q, NULL, P, n2, ctx)) ABORT;
+   /* Add P to verify the result. */
+   if (!EC_POINT_add(group, Q, Q, P, ctx)) ABORT;
+   if (!EC_POINT_is_at_infinity(group, Q)) ABORT;
+

Re: 1.0.1i fails on make test

[Jason Schultz]

Thank you for the fast reply. 

 On Aug 13, 2014, at 4:31 PM, Jeffrey Walton noloa...@gmail.com wrote:
 
 On Wed, Aug 13, 2014 at 5:19 PM, Jason Schultz jetso...@hotmail.com wrote:
 I've been trying to build the latest (1.0.1i) OpenSSL, and I'm having
 problems with the self-tests.
 ...
 http://groups.google.com/d/msg/mailing.openssl.users/1PzVX75ic_s/Oba578nnpWIJ
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Can't get my CRL to work on my OpenSSL client

[Jason Schultz]

I'm having trouble figuring out how to get a CRL I created working. I'll start 
from the beginning, apologies for length.
First, I created my own CA with OpenSSL (1.0.1h) on my server machine, 
consisting of 3 certificates:  root - serverCA - serverI successfully opened 
connections from my client to the server after installing the root certificate 
on my client machine, so I believe the CA I set up is working properly.
Then I attempted to create a CRL revoking the server cert with the following 
commands:
openssl ca -config openssl.cnf -revoke server.pem -keyfile rootkey.pem -cert 
root.pem
openssl ca -config openssl.cnf -keyfile rootkey.pem -cert root.pem -gencrl -out 
crl.pem
I also had to set up the crlnumber file and the index.txt file to get these 
commands to work. Later on, since I didn't know if revoking server with root 
would work properly, I also did the same commands to revoke serverCA. I did 
find that revoking server with root may not work, and I should actually have 
revoked serverCA instead. So I have tried all of my tests with a CRL that 
attempts to revoke both certs. The resulting CRL looks ok to me:
openssl crl -text -in crls/crl.pem
Certificate Revocation List (CRL):Version 2 (0x1)Signature 
Algorithm: sha1WithRSAEncryptionIssuer: 
/C=US/ST=MN/L=mycity/O=mycompany/OU=Networking/CN=My Root/emailAddress=edited   
 Last Update: Jul 30 14:31:31 2014 GMTNext Update: Aug 29 14:31:31 
2014 GMTCRL extensions:X509v3 CRL Number:
8998Revoked Certificates:Serial Number: 9B7CBA0F9C48177CRevocation 
Date: Jul 28 15:52:28 2014 GMTSerial Number: AEB802C77D4CF001
Revocation Date: Jul 23 13:19:40 2014 GMTSerial Number: D3F15A42946EAFB2
Revocation Date: Jul 30 14:30:24 2014 GMTSignature Algorithm: 
sha1WithRSAEncryption 
38:e3:51:c6:30:d5:ec:50:60:88:18:2c:60:ac:fa:80:98:b9: 
1d:81:65:99:bf:5b:02:71:88:e9:d3:22:40:8a:7b:fa:24:7d: 
ef:00:d6:ee:32:84:68:e9:bc:93:e3:6f:e6:0a:62:20:0f:0c: 
60:e2:f7:94:7c:25:13:54:68:98:11:fc:99:4e:9d:09:7b:8c: 
80:82:e7:96:f6:d2:73:75:85:6d:64:7c:56:ac:3c:76:44:ac: 
1e:32:bb:04:ad:a9:b3:cf:04:34:6e:ab:2b:0b:87:d7:9b:46: 
a9:fa:34:ae:35:80:39:a6:ce:2b:34:9c:a8:25:86:4b:b9:16: 
81:8d:8a:8f:f9:67:1c:4a:c5:b0:c2:5c:68:d3:e1:8a:d6:2f: 
dc:5b:a0:bf:10:ee:1b:54:fc:ae:b3:02:b4:10:18:5b:17:8f: 
2b:3a:d7:a7:a5:f3:2a:4d:7a:39:5f:49:10:a2:fa:3e:8f:bd: 
ed:6a:1d:aa:8b:00:f9:be:8d:29:12:46:a9:87:b2:dc:d8:25: 
69:e2:d1:bc:b6:00:4c:5a:7f:16:8e:5e:99:1d:89:7b:17:38: 
06:6c:c6:38:3b:e3:2f:fc:88:43:35:c5:03:42:7f:09:e2:c7: 
95:ab:4a:01:85:4f:bd:f3:8a:ed:bc:64:bf:d9:a8:67:77:79: 89:ed:d4:4a
You can ignore one of the serial numbers of the revoked certs, the two I was 
trying to revoke that are part of this CA are as follows:
openssl x509 -in certs/server.pem -text 
   Certificate:Data:Version: 3 (0x2)Serial Number: 
11204034549200197500 (0x9b7cba0f9c48177c)Signature Algorithm: 
sha256WithRSAEncryptionIssuer: C=US, ST=MN, L=mycity, O=mycompany, 
OU=Networking, CN=Server CA/emailAddress=editedValidityNot 
Before: Jul 21 14:41:11 2014 GMTNot After : Aug 20 14:41:11 2014 
GMTSubject: C=US, ST=Minnesota, L=mycity, O=mycompany, OU=Networking, 
CN= server/emailAddress=editedSubject Public Key Info:
Public Key Algorithm: rsaEncryptionPublic-Key: (2048 bit)   
 Modulus:
00:e1:2c:c1:42:af:ab:f1:ae:07:3d:4f:d6:fe:d6:
cd:e6:8b:3d:00:fd:e4:ac:a3:73:bc:3e:46:3d:af:
64:88:ae:fb:cc:96:42:31:7a:71:59:e2:8c:24:e2:
fa:e8:7e:91:cd:c9:c1:04:bd:c6:b8:34:3c:26:e7:
4a:65:9b:2c:49:a2:9a:a3:d5:46:04:86:20:da:92:
bd:7b:ba:f9:65:20:62:f6:2f:2f:9e:96:8a:8f:00:
01:a4:d9:0e:ad:eb:d8:aa:af:5a:ff:e3:eb:0e:48:
f9:6e:5c:da:30:17:f3:e1:a8:2f:4e:47:43:a1:46:
ac:77:4f:75:fd:8c:9e:5e:91:8e:63:4c:85:68:5c:
b5:d5:1d:b6:82:d5:1d:50:0d:12:51:05:b6:0b:43:
ff:8f:c6:d4:3c:3a:10:1b:8c:35:38:f9:50:f7:e5:
44:95:55:17:31:2d:14:35:c6:a3:b3:93:f0:85:ff:
19:99:ad:27:d5:56:a0:5a:32:9b:9f:77:0f:14:4d:
24:de:db:29:59:4d:7c:58:f0:c7:44:f3:94:53:1f:
6f:c8:43:ff:67:33:67:9f:f7:cb:83:ea:9b:67:c2:
54:0a:89:f1:de:36:f2:bc:25:15:3d:48:30:58:7f:
85:a3:dc:c6:10:47:4c:27:02:e1:b6:d7:54:75:a4:90:09  
  Exponent: 65537 (0x10001)X509v3 extensions:X509v3 
Basic Constraints:CA:FALSENetscape Comment: 
   OpenSSL Generated CertificateX509v3 

RE: Can't get my CRL to work on my OpenSSL client

[Jason Schultz]

It appears this is resolved already, sort of. It appears the one thing I did 
not try after revoking the serverCA certificate with my root was to concatenate 
the new CRL to the root cert on the client machine. When I did that, my client 
got a certificate revoked error.
However, I do have a question. Is there any way around this requirement? The 
requirement of apending the  root certificate and  CRL files on the client 
machine in /etc/ssl/crls?

From: jetso...@hotmail.com
To: openssl-users@openssl.org
Subject: Can't get my CRL to work on my OpenSSL client
Date: Wed, 30 Jul 2014 18:18:03 +




I'm having trouble figuring out how to get a CRL I created working. I'll start 
from the beginning, apologies for length.
First, I created my own CA with OpenSSL (1.0.1h) on my server machine, 
consisting of 3 certificates:  root - serverCA - serverI successfully opened 
connections from my client to the server after installing the root certificate 
on my client machine, so I believe the CA I set up is working properly.
Then I attempted to create a CRL revoking the server cert with the following 
commands:
openssl ca -config openssl.cnf -revoke server.pem -keyfile rootkey.pem -cert 
root.pem
openssl ca -config openssl.cnf -keyfile rootkey.pem -cert root.pem -gencrl -out 
crl.pem
I also had to set up the crlnumber file and the index.txt file to get these 
commands to work. Later on, since I didn't know if revoking server with root 
would work properly, I also did the same commands to revoke serverCA. I did 
find that revoking server with root may not work, and I should actually have 
revoked serverCA instead. So I have tried all of my tests with a CRL that 
attempts to revoke both certs. The resulting CRL looks ok to me:
openssl crl -text -in crls/crl.pem
Certificate Revocation List (CRL):Version 2 (0x1)Signature 
Algorithm: sha1WithRSAEncryptionIssuer: 
/C=US/ST=MN/L=mycity/O=mycompany/OU=Networking/CN=My Root/emailAddress=edited   
 Last Update: Jul 30 14:31:31 2014 GMTNext Update: Aug 29 14:31:31 
2014 GMTCRL extensions:X509v3 CRL Number:
8998Revoked Certificates:Serial Number: 9B7CBA0F9C48177CRevocation 
Date: Jul 28 15:52:28 2014 GMTSerial Number: AEB802C77D4CF001
Revocation Date: Jul 23 13:19:40 2014 GMTSerial Number: D3F15A42946EAFB2
Revocation Date: Jul 30 14:30:24 2014 GMTSignature Algorithm: 
sha1WithRSAEncryption 
38:e3:51:c6:30:d5:ec:50:60:88:18:2c:60:ac:fa:80:98:b9: 
1d:81:65:99:bf:5b:02:71:88:e9:d3:22:40:8a:7b:fa:24:7d: 
ef:00:d6:ee:32:84:68:e9:bc:93:e3:6f:e6:0a:62:20:0f:0c: 
60:e2:f7:94:7c:25:13:54:68:98:11:fc:99:4e:9d:09:7b:8c: 
80:82:e7:96:f6:d2:73:75:85:6d:64:7c:56:ac:3c:76:44:ac: 
1e:32:bb:04:ad:a9:b3:cf:04:34:6e:ab:2b:0b:87:d7:9b:46: 
a9:fa:34:ae:35:80:39:a6:ce:2b:34:9c:a8:25:86:4b:b9:16: 
81:8d:8a:8f:f9:67:1c:4a:c5:b0:c2:5c:68:d3:e1:8a:d6:2f: 
dc:5b:a0:bf:10:ee:1b:54:fc:ae:b3:02:b4:10:18:5b:17:8f: 
2b:3a:d7:a7:a5:f3:2a:4d:7a:39:5f:49:10:a2:fa:3e:8f:bd: 
ed:6a:1d:aa:8b:00:f9:be:8d:29:12:46:a9:87:b2:dc:d8:25: 
69:e2:d1:bc:b6:00:4c:5a:7f:16:8e:5e:99:1d:89:7b:17:38: 
06:6c:c6:38:3b:e3:2f:fc:88:43:35:c5:03:42:7f:09:e2:c7: 
95:ab:4a:01:85:4f:bd:f3:8a:ed:bc:64:bf:d9:a8:67:77:79: 89:ed:d4:4a
You can ignore one of the serial numbers of the revoked certs, the two I was 
trying to revoke that are part of this CA are as follows:
openssl x509 -in certs/server.pem -text 
   Certificate:Data:Version: 3 (0x2)Serial Number: 
11204034549200197500 (0x9b7cba0f9c48177c)Signature Algorithm: 
sha256WithRSAEncryptionIssuer: C=US, ST=MN, L=mycity, O=mycompany, 
OU=Networking, CN=Server CA/emailAddress=editedValidityNot 
Before: Jul 21 14:41:11 2014 GMTNot After : Aug 20 14:41:11 2014 
GMTSubject: C=US, ST=Minnesota, L=mycity, O=mycompany, OU=Networking, 
CN= server/emailAddress=editedSubject Public Key Info:
Public Key Algorithm: rsaEncryptionPublic-Key: (2048 bit)   
 Modulus:
00:e1:2c:c1:42:af:ab:f1:ae:07:3d:4f:d6:fe:d6:
cd:e6:8b:3d:00:fd:e4:ac:a3:73:bc:3e:46:3d:af:
64:88:ae:fb:cc:96:42:31:7a:71:59:e2:8c:24:e2:
fa:e8:7e:91:cd:c9:c1:04:bd:c6:b8:34:3c:26:e7:
4a:65:9b:2c:49:a2:9a:a3:d5:46:04:86:20:da:92:
bd:7b:ba:f9:65:20:62:f6:2f:2f:9e:96:8a:8f:00:
01:a4:d9:0e:ad:eb:d8:aa:af:5a:ff:e3:eb:0e:48:
f9:6e:5c:da:30:17:f3:e1:a8:2f:4e:47:43:a1:46:
ac:77:4f:75:fd:8c:9e:5e:91:8e:63:4c:85:68:5c:
b5:d5:1d:b6:82:d5:1d:50:0d:12:51:05:b6:0b:43:
ff:8f:c6:d4:3c:3a:10:1b:8c:35:38:f9:50:f7:e5:

RE: Can't get my CRL to work on my OpenSSL client

[Jason Schultz]

Rich-
Thanks for your response. The client is my own Linux client using OpenSSL. So 
are you saying that I need to do certificate validation on my own, at least as 
far as checking for revocation?  That's assuming the solution isn't to 
concatenate the files as described previously. I am not concerned with getting 
updated CRLs, I just want to know how to properly check for revocation once I 
have a CRL in /etc/ssl/crls on the client.
Can you give a brief high-level view of what I'd need to do this in my client 
without the file appending?
Thanks!

 From: rs...@akamai.com
 To: openssl-users@openssl.org
 Date: Wed, 30 Jul 2014 15:15:51 -0400
 Subject: RE: Can't get my CRL to work on my OpenSSL client
 
  However, I do have a question. Is there any way around this requirement? 
  The requirement of apending the  root certificate and  CRL files on the 
  client machine in /etc/ssl/crls?
 
 It totally depends on the client program that you are using.  So, which 
 client?  The validation code won't, on its own, look at something like the 
 CRL-DP and fetch things for you.
 
   /r$
 
 --  
 Principal Security Engineer
 Akamai Technologies, Cambridge MA
 IM: rs...@jabber.me Twitter: RichSalz
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
  

RE: Can't get my CRL to work on my OpenSSL client

[Jason Schultz]

OK, maybe I'm confused. I can get the CRL to my client machine OK, that's not 
an issue. What I'm saying is, placing the CRLs into the local directory alone 
is not OK, revocation check will not work. In order for that to work, I need to 
append the CRL to the root certificate in /etc/ssl/crls.
So my question was, is there a way to get this to work (i.e., OpenSSL sees the 
certificate sent by the server is revoked) without having the root certificate 
and CRL files appended together?

From: rs...@akamai.com
To: openssl-users@openssl.org
Date: Wed, 30 Jul 2014 15:34:57 -0400
Subject: RE: Can't get my CRL to work on my OpenSSL client

No, I’m saying that putting the CRL’s into the local directory is okay, and 
OpenSSL will parse them.  How you get them there is your issue J --  Principal 
Security EngineerAkamai Technologies, Cambridge MAIM: rs...@jabber.me Twitter: 
RichSalz

RE: Can't get my CRL to work on my OpenSSL client

[Jason Schultz]

OK. So as far as you're aware, there's not a way to avoid the requirement of 
the combined root cert/CRL file when checking for revoked certificates? I would 
prefer to just have to deal with the CRL in PEM format, but the CRL file must 
always be the CRL appended to the root cert, as far as I can tell.  
Thanks for your prompt responses, by the way.

From: rs...@akamai.com
To: openssl-users@openssl.org
Date: Wed, 30 Jul 2014 16:02:56 -0400
Subject: RE: Can't get my CRL to work on my OpenSSL client

No, I was confused; when you said “append to the root cert” I thought you meant 
copying it into the local directory.  You meant literally appending it to the 
cert.  I suppose you could create a new file with a “similar” name… --  
Principal Security EngineerAkamai Technologies, Cambridge MAIM: rs...@jabber.me 
Twitter: RichSalz   

RE: Can't get my CRL to work on my OpenSSL client

[Jason Schultz]

Dr Henson-
The first message in this thread had the relevant code, copied again below. I 
have tried a few tweaks on setting up for CRL checking, but this is what I have 
now:
Reading the file in; I have edited out a lot of error checking, etc, but the 
CRL is read in successfully:
X509_STORE*trusted_store;X509_CRL  *crl;fp = 
fopen(/etc/ssl/crls/crl.pem, r);crl = PEM_read_X509_CRL(fp, NULL, 0, 
NULL);X509_STORE_add_crl(trusted_store,crl);
Then I enable CRL checking as follows (I have also tried  setting only 
X509_V_FLAG_CRL_CHECK):
X509_VERIFY_PARAM *param = X509_VERIFY_PARAM_new();
X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_CRL_CHECK |  
  X509_V_FLAG_CRL_CHECK_ALL);
X509_STORE_set1_param(trusted_store, param);
X509_VERIFY_PARAM_free(param);
The fopen(), etc is only for the crl, but I loop through every .pem file in the 
/etc/ssl/crls directory and read in each one(successfullly).

 Date: Wed, 30 Jul 2014 23:44:45 +0200
 From: st...@openssl.org
 To: openssl-users@openssl.org
 Subject: Re: Can't get my CRL to work on my OpenSSL client
 
 On Wed, Jul 30, 2014, Jason Schultz wrote:
 
  OK. So as far as you're aware, there's not a way to avoid the requirement of
  the combined root cert/CRL file when checking for revoked certificates? I
  would prefer to just have to deal with the CRL in PEM format, but the CRL
  file must always be the CRL appended to the root cert, as far as I can tell.
  Thanks for your prompt responses, by the way.
  
 
 The CRL can come from anywhere as long as it is supplied to OpenSSL in the
 appropriate way.
 
 There are some standard places a CRL can be included such as a file or
 directory containing the set of trusted certificates but it is not a
 requirement.
 
 I can't really comment more without seeing a sample of how your code is
 loading the CRL and how it is enabling CRL checks.
 
 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
  

SHA1 signatures in FIPS mode w/ TLS 1.2

[Jason Schultz]

According to this wiki page:

 

http://wiki.openssl.org/index.php/FIPS_mode_and_TLS

 

When in FIPS mode, SHA1 signatures can not be used when
using the TLS 1.2 protocol:
If that wasn't enough there's another complication. For TLS v1.2 you have to 
restrict the supported signature algorithms to exclude SHA1, allowing only 
SHA256 and above.
However, our application is in FIPS mode, and I am successfully opening a 
connection using only cipher AES256-SHA. We are not calling any low level 
APIs, just simply using calls to SSL_do_handshake() to perform the handshake. 
Both client and server are using OpenSSL and only making AES256-SHA available.  
The client and server hello from a successful handshake are below, the 0x23 in 
both indicate RSA_WITH_AES_256_SHA (from s3_lib.c) and protocol TLS 1.2 (0x03 
0x03).
 TLS 1.2
Handshake [length 005e], ClientHello01 00 00 5a 03 03 77 7d 00 39 a8 d6 9e 16 
3a 438d 23 70 13 5f f5 59 ea aa 17 72 9e ff 45 00 8f17 a8 35 bb 3d f2 00 00 04 
00 9d 00 ff 01 00 002d 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02 0603 05 01 05 
02 05 03 04 01 04 02 04 03 03 01 0302 03 03 02 01 02 02 02 03 00 0f 00 01 01 
TLS 1.2
Handshake [length 003a], ServerHello02 00 00 36 03 03 70 3b f5 15 8d 56 c5 69 
79 cb3a 6a 7a 0c 21 07 3d f2 63 cb 4d 24 c3 53 c9 3b1f 01 fc 5c 9f 37 00 00 9d 
00 00 0e ff 01 00 01































00 00 23 00 00 00 0f 00 01 01
I would just like to confirm the accuracy or inaccuracy of the wiki page. I 
have also read in the FIPS User Guide that attempting to use non-FIPS 
algorithms will not always fail. 
From Section 5.4: However, there is no guarantee that the OpenSSL API will 
always return an error condition in every possible permutation of or sequence 
of API calls that might invoke code relating to non-FIPS algorithms.
And Section 2.6.2: It is the responsibility of the application developer to 
ensure that only FIPS algorithms are used when in FIPS mode.
To furthur complicate things, several days ago I had observed handshakes 
failing in this situation, with the following errors in the OpenSSL Error Queue 
on the client side:
error:0409A09E:rsa
routines:PKEY_RSA_VERIFY:operation not allowed in fips modeerror:0D0C5006:asn1
encoding routines:ASN1_item_verify:EVP liberror:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Are we seeing a case where sometimes OpenSSL fails to prevent non-FIPS 
algorithms and sometimes does not, for whatever reason?
Thanks in advance.

RE: SHA1 signatures in FIPS mode w/ TLS 1.2

[Jason Schultz]

Another follow up question. The Wiki page refers to FIPS 186-4. Are these 
restrictions only for FIPS 186-4, or FIPS 140-2 as well?

From: jetso...@hotmail.com
To: openssl-users@openssl.org
Subject: SHA1 signatures in FIPS mode w/ TLS 1.2
Date: Wed, 16 Jul 2014 13:31:35 +




According to this wiki page:

 

http://wiki.openssl.org/index.php/FIPS_mode_and_TLS

 

When in FIPS mode, SHA1 signatures can not be used when
using the TLS 1.2 protocol:
If that wasn't enough there's another complication. For TLS v1.2 you have to 
restrict the supported signature algorithms to exclude SHA1, allowing only 
SHA256 and above.
However, our application is in FIPS mode, and I am successfully opening a 
connection using only cipher AES256-SHA. We are not calling any low level 
APIs, just simply using calls to SSL_do_handshake() to perform the handshake. 
Both client and server are using OpenSSL and only making AES256-SHA available.  
The client and server hello from a successful handshake are below, the 0x23 in 
both indicate RSA_WITH_AES_256_SHA (from s3_lib.c) and protocol TLS 1.2 (0x03 
0x03).
 TLS 1.2
Handshake [length 005e], ClientHello01 00 00 5a 03 03 77 7d 00 39 a8 d6 9e 16 
3a 438d 23 70 13 5f f5 59 ea aa 17 72 9e ff 45 00 8f17 a8 35 bb 3d f2 00 00 04 
00 9d 00 ff 01 00 002d 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02 0603 05 01 05 
02 05 03 04 01 04 02 04 03 03 01 0302 03 03 02 01 02 02 02 03 00 0f 00 01 01 
TLS 1.2
Handshake [length 003a], ServerHello02 00 00 36 03 03 70 3b f5 15 8d 56 c5 69 
79 cb3a 6a 7a 0c 21 07 3d f2 63 cb 4d 24 c3 53 c9 3b1f 01 fc 5c 9f 37 00 00 9d 
00 00 0e ff 01 00 01































00 00 23 00 00 00 0f 00 01 01
I would just like to confirm the accuracy or inaccuracy of the wiki page. I 
have also read in the FIPS User Guide that attempting to use non-FIPS 
algorithms will not always fail. 
From Section 5.4: However, there is no guarantee that the OpenSSL API will 
always return an error condition in every possible permutation of or sequence 
of API calls that might invoke code relating to non-FIPS algorithms.
And Section 2.6.2: It is the responsibility of the application developer to 
ensure that only FIPS algorithms are used when in FIPS mode.
To furthur complicate things, several days ago I had observed handshakes 
failing in this situation, with the following errors in the OpenSSL Error Queue 
on the client side:
error:0409A09E:rsa
routines:PKEY_RSA_VERIFY:operation not allowed in fips modeerror:0D0C5006:asn1
encoding routines:ASN1_item_verify:EVP liberror:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Are we seeing a case where sometimes OpenSSL fails to prevent non-FIPS 
algorithms and sometimes does not, for whatever reason?
Thanks in advance.  
  

ClientHello protocol versions with s_server

[Jason Schultz]

I'm a bit confused on the appropriate protocol versions
to use on a ClientHello in my SSL/TLS implementation. (I am using s_server to 
test my client code.) I say “versions” as there is the record version
and the suggested protocol version.  Ignoring SSLv2, the initial
ClientHello to a server should have a record version of 3.0, as the lowest
supported, and 3.3 as the suggested version (or whatever is the highest
supported by the client).  

 

RFC 5246 states on page 40 for ClientHello:

 

client_version

  The version of the TLS
protocol by which the client wishes to

  communicate during this
session.  This SHOULD be the latest

  (highest valued) version
supported by the client.  For this

  version of the specification,
the version will be 3.3 (see

  Appendix E for details about
backward compatibility).

 

That's clear and unequivocal--not sure why it is not a MUST,
just a SHOULD –I’m guessing this is to allow servers to be more permissive and
increase interoperability?

 

In Appendix E there are two interesting statements:

 

If a TLS server receives a ClientHello containing a
version number

greater than the highest version supported by the server, it
MUST

reply according to the highest version supported by the
server.

 

So if the client sent 3.3 as the suggested version, I can
assume that whatever the server negotiates is the highest version it supports,
correct?

 

Whenever a client already knows the highest protocol
version known to

a server (for example, when resuming a session), it SHOULD
initiate

the connection in that native protocol.

 

OK, here is where I am confused.  If the server
negotiated 3.1, and I am doing session resumption, what protocol versions
should I send in the ClientHello to be compliant with the RFC?

 

Should the record version be 3.1 to satisfy the appendix,
and the suggested version 3.3 to satisfy page 40? My SSL/TLS implementation 
acting as a client sends record version 3.0 and suggested version 3.1 and 
OpenSSL s_server accepts it as OK. Is OpenSSL just being
permissive to allow for interoperation?


Thanks for any clarification.  Also please advise if
there are any differences in this area between session resumption and
renegotiation.

FIPS 140-2 questions

[Jason Schultz]

I’m trying to decipher FIPS 140-2 Certification in regards
to OpenSSL FIPS module 2.0 and have some questions:


1.  
Can one claim FIPS validated if running on an
Operating Environment not listed on Cert #1747?  (I don’t think not having
an OE direct match is necessarily required, as long as I follow the build
guidelines as defined in the Security Policy.)


2.  
Related to #1, what if the build process is
followed on an OE listed on 1747, and the resulting FIPS and OpenSSL modules
were moved to an OE not listed (e.g. Linux 3.0)?


3.  
If I cannot claim validation from #1, would I
have to get my OE fully certified or can I do a change letter through the
OpenSSL group?


4.  
What are the costs for a change letter?


5.  
Is there any way to see any change letters in
the works already for 1747 that just haven’t been added to the cert (e.g. Linux 
3.0)?
Thanks in advance.

FIPS_mode_set Software Integrity self-test question

[Jason Schultz]

 I've been doing some testing with the latest 2.0 FIPS Object Module I 
downloaded and 1.0.1e OpenSSL and have a question. 


I was wondering what the Software Integrity
self-test is designed to accomplish?  It
seems like it's to ensure the source code or build hasn't been tampered
with.  Out of curiosity, I added a
comment line in the file ...\fips\fips.c in the FIPS module.  Also, because I 
wasn't sure if the integrity
check also validated the OpenSSL library, I added a comment line to the file 
...\crypto\evp\evp_enc.c.  I then rebuilt the FIPS Object Module, and the FIPS 
Capable OpenSSL according to the User
Guide directions.  All of the steps
seemed to work.  I then started my
application, calling FIPS_mode_set(), expecting a failure because of the
modifications to the source code files and resulting libraries I had rebuilt.  
However, the call returned success.




Does this make sense to anyone?  Am I misinterpreting what the Software 
Integrity self-test is supposed to do?
Thanks in advance.
  

Does OpenSSL timeout connections waiting for a ClientHello?

[Jason Schultz]

I have a server that implements secure communication using OpenSSL.  The server 
does a listen() on a port and keeps track of what listens are secure/SSL 
listens.  When a peer opens to that IP addr/port, the server sees that it's for 
a secure connection and then makes the calls to set up SSL information for the 
socket:
 
   // error checking and extraneous code removed
sock = accept(listen_sock, (struct sockaddr*)sa_cli, client_len);
SSL_bio = BIO_new(BIO_s_socket()); 
SSL_obj = SSL_new(SSL_ctx);
BIO_set_fd(SSL_bio,sock,BIO_NOCLOSE);
SSL_set_bio(SSL_obj, SSL_bio, SSL_bio);
SSL_set_verify(SSL_obj,SSL_VERIFY_NONE,verify_callback);
SSL_set_accept_state(SSL_obj);

At that point, the server should be waiting for the ClientHello, and will use 
SSL_read/write to perform the handshake.
 
Let's say the client/peer never sends in the ClientHello.  In other words, the 
client probably called connect() but not SSL_connect() or some similar scenario.
 
Does OpenSSL eventually time out this connection and abort it somehow?  Are 
there OpenSSL API calls the server should be using to ensure it does get timed 
out?  Or is this something the server application should keep track of and 
handle on it's own?
 
Thanks in advance.
  

Thread safety questions in OpenSSL 1.0.1

[Jason Schultz]

Back in November a question(and response) were posted regarding thread safety 
in the 1.0.1 branch of OpenSSL:
 
http://www.mail-archive.com/openssl-users@openssl.org/msg69322.html
 
In the response to the questions, the user states he removed the thread ID 
callback function and the call to CRYPTO_set_id_callback(). However, there was 
nothing as far as follow up to verify this was correct.
 
Is there information out there(perhaps another thread on this list I am unable 
to find) someone could link me to that discusses the differences in ensuring 
thread safety between 0.9.8 and 1.0.1?
 
Thanks.
 
  

RE: Unexpected message during renegotiate attempt

[Jason Schultz]

Has there been any response to this?  I dealt with a similar situation about 6 
months ago.  It turned out, at first my application was handling some responses 
to SSL_write() and SSL_read incorrectly: 
http://www.mail-archive.com/openssl-users@openssl.org/msg67276.html However, 
after furthur investitgation and fixing of my application issues, I found that 
OpenSSL was not able to handle the renegotaion scenario I described.  Which is 
basically the one in the 2nd bug ticket link you posted; Peer A initiates a 
renegotiation while Peer B is sending data.  The behavior wasn't exactly the 
same, I don't think I ever got a failure, but the ClientHello was never read by 
the server and renegotaion wouldn't take place until after Peer B was done 
sending data. Just curious if this is something that has been resolved. Thanks.
Jason
 From: rezaul.ha...@nsn.com
To: openssl-users@openssl.org
CC: iftekhar.1.ma...@nsn.com; michael.b...@nsn.com
Subject: Unexpected message during renegotiate attempt
Date: Tue, 19 Mar 2013 16:55:01 +









Hello All,
 
I am using openssl 0.9.8r on one Linux box (BoxA) communicating with another  
Linux box running
openssl 1.0.0e  (BoxB).
 
There are certain curl uploads  that need to occur  fromBoxA 
à BoxB.
 
Usually we don’t have any problems. But in a simulated environment, where there 
could be significant delay/latency (~2 to 3 seconds) in traffic between  BoxA  
and  BoxB, we are seeing that the curl operations are not completing as 
expected. 

 
Curl is sending the HTTP-100 message, in the middle of TLS Re-Negotiation, and 
causing BoxB to send a Fatal Alert and closing the connection.  According to 
the TLS spec, apparently, the TLS implementation should simply ignore those 
unexpected
 messages and continue with re-negotiation??
 
Upon digging some openssl bug reports, we came across these two Bug Tickets. 
And looks like they were never addressed ?
 
http://rt.openssl.org/Ticket/Display.html?id=2146user=guestpass=guest

http://rt.openssl.org/Ticket/Display.html?id=2481user=guestpass=guest
 
Just was trying to find out if the openssl community ever addressed this “bug” 
? If so what openssl version(s) have a fix for this?
 
Any additional information related to the bug mentioned above would be greatly 
appreciated.

 
Thanks,
 
-Rezaul.
 
 
  

RE: OpenSSL linking question; handling 1.0.0 vs 0.9.8

[Jason Schultz]

Christian- Thanks very much for your response.  That information is definitely 
helpful.  I'll take some time to process this and work towards your solution.
  Date: Thu, 21 Jun 2012 07:25:24 +0200
 From: christ...@hohnstaedt.de
 To: openssl-users@openssl.org
 Subject: Re: OpenSSL linking question; handling 1.0.0 vs 0.9.8
 
 Hi Jason,
 
 some general things about linking:
 
 - The symbolic link(s) libcrypto.so pointing to libcrypto.so.0.9.8
   are only needed during BUILD time. On a host where no compiling
   happens the symbolic links are not required.
 
 - While linking the application, the linker opens the library
   libcrypto.so.0.9.8 by accessing the symbolic link
   libcrypto.so and reads its SONAME:
 $ objdump -x /usr/lib/libcrypto.so | grep SONAME
   This name (which has no path) is added to your application:
 $ objdump -x /usr/bin/openssl | grep NEEDED
 
 - When executing the application, the /lib/ld-linux.so link helper
   searches in the well known places $LD_LIBRARY_PATH:/lib:/usr/lib
   for the libraries and opens them recursively.
   To show which library file is actually used during execution, call:
 $ ldd /usr/bin/openssl
 
 
 To solve your problem, I suggest to compile but not install openssl-1.0.1c
 on the second machine and only copy the resulting libraries libssl.so.1.0.0
 and libcrypto.so.1.0.0 to /usr/lib without touching their names, the 
 symlinks
 nor the include/openssl.
 
 This way, any application compiled on that host will link to 0.9.8,
 while applications compiled against 1.0.x will also run smoothly.
 
 HTH
 
   Christian
 
 
 On Wed, Jun 20, 2012 at 05:56:07PM +, Jason Schultz wrote:
  
  
  
  
  I'm building and running an application that uses OpenSSL on SUSE Linux.  I 
  don't know a lot about linking in general, just very basic stuff, so my 
  question might be better posed to a Linux forum, but it might be specific 
  to OpenSSL.  Let me describe the scenario.
   
  I have built installed OpenSSL 1.0.1c on one machine; built as a shared 
  library(with shared option on ./config).  I build my application and run 
  it on this machine, dynamically linking OpenSSL.  After some trial and 
  error(to get the application to use the new OpenSSL instead of the the 
  previous install of 0.9.8r), everything works fine, my application is using 
  OpenSSL 1.0.1c. Now, let's say I want to run my application on another SUSE 
  Linux machine.  However, this machine has 0.9.8r(or any 0.9.8 level) 
  installed.  When I try to run the application, I get an error saying it 
  can't find OpenSSL 1.0.0.  I know that there are symbolic links set up when 
  installing OpenSSL, so libssl.so will be linked to libssl.so.1.0.0 after 
  installing OpenSSL 1.0.1c. (Similar for libcrypto.so) But in the old 
  branch, the link is set up with libssl.so pointing to libssl.so.0.9.8.  
  When I build my application, it seems to know that it's looking for 
  libssl.so.1.0.0, instead of just the generic libssl.so.  I'm basing this on 
  doing a readelf -d on my the .so file my make produces, and seeing the 
  following line:  (NEEDED) Shared library: [libssl.so.1.0.0]
  On the machine I moved my application to(with the older OpenSSL), the link 
  where OpenSSL exists shows libssl.so linked to libssl.so.0.9.8, obviously. 
  I started messing around with trying to build 1.0.1c to look like 0.9.8 
  by changing the SHLIB_VERSION_NUMBER in Makefile.org and 
  /crypto/opensslv.h, but that started getting confusing and is probably 
  beyond the scope of my knowledge at this point. I've done it before with, 
  for example, going from 0.9.8i to 0.9.8r and didn't have any problems.  I 
  suppose because the symbolic links look the same. Has anyone had to do this 
  before?  A point in the right direction would be appreciated.  Is this even 
  possible to go between branches like that?  

 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
  

OpenSSL linking question; handling 1.0.0 vs 0.9.8

[Jason Schultz]

I'm building and running an application that uses OpenSSL on SUSE Linux.  I 
don't know a lot about linking in general, just very basic stuff, so my 
question might be better posed to a Linux forum, but it might be specific to 
OpenSSL.  Let me describe the scenario.
 
I have built installed OpenSSL 1.0.1c on one machine; built as a shared 
library(with shared option on ./config).  I build my application and run it 
on this machine, dynamically linking OpenSSL.  After some trial and error(to 
get the application to use the new OpenSSL instead of the the previous install 
of 0.9.8r), everything works fine, my application is using OpenSSL 1.0.1c. Now, 
let's say I want to run my application on another SUSE Linux machine.  However, 
this machine has 0.9.8r(or any 0.9.8 level) installed.  When I try to run the 
application, I get an error saying it can't find OpenSSL 1.0.0.  I know that 
there are symbolic links set up when installing OpenSSL, so libssl.so will be 
linked to libssl.so.1.0.0 after installing OpenSSL 1.0.1c. (Similar for 
libcrypto.so) But in the old branch, the link is set up with libssl.so pointing 
to libssl.so.0.9.8.  When I build my application, it seems to know that it's 
looking for libssl.so.1.0.0, instead of just the generic libssl.so.  I'm basing 
this on doing a readelf -d on my the .so file my make produces, and seeing the 
following line:  (NEEDED) Shared library: [libssl.so.1.0.0]
On the machine I moved my application to(with the older OpenSSL), the link 
where OpenSSL exists shows libssl.so linked to libssl.so.0.9.8, obviously. I 
started messing around with trying to build 1.0.1c to look like 0.9.8 by 
changing the SHLIB_VERSION_NUMBER in Makefile.org and /crypto/opensslv.h, but 
that started getting confusing and is probably beyond the scope of my knowledge 
at this point. I've done it before with, for example, going from 0.9.8i to 
0.9.8r and didn't have any problems.  I suppose because the symbolic links look 
the same. Has anyone had to do this before?  A point in the right direction 
would be appreciated.  Is this even possible to go between branches like that?  
  

RE: TLSv1.2 backward compatibility

[Jason Schultz]

I have a question on how this situation happens, exactly, when using TLS 1.1 or 
1.2.  From ticket 2771, I see that the length of the ClientHello is what causes 
the problem.  But what needs to happen in order to make a ClientHello get too 
big?  My OpenSSL application only supports around 25 cipher suites, so let's 
say all 25 are included in a ClientHello.  Would that make a TLS 1.1 or 1.2 
ClientHello long enough to cause this issue?  I don't think my application does 
anything else to add length to a ClientHello.  From the bug report, I see there 
are ways to reproduce the problem, like adding -servername (very long string) 
to a call to s_client, but again my application doesn't do anything to add 
length to the ClientHello, and will at most propose around 25 ciphers. Another 
question, which may be sort of related to this bug.  If I'm using 1.0.1c and my 
application calls SSL_CTX_set_options(ctx, SSL_OP_ALL | 
SSL_OP_NO_SSLv2);
will a ClientHello still try to use TLS 1.2 first in the ClientHello? What 
about if it calls: SSL_CTX_set_options(ctx, SSL_OP_ALL | 
SSL_OP_NO_SSLv2 |
SSL_OP_NO_TLSv1);
or: SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 |
SSL_OP_NO_SSLv3);
to eliminate TLS 1.0 or SSL 3.0, respectively?  My understanding is that TLS 
1.2/1.1 would still be used initially, unless I explicitely eliminate them with 
SSL_OP_NO_TLSv1_1 | SSL_OP_NO_TLSv1_2.  Is that correct? Thanks.
  Date: Thu, 14 Jun 2012 03:46:23 +0200
 From: st...@openssl.org
 To: openssl-users@openssl.org
 Subject: Re: TLSv1.2 backward compatibility
 
 On Wed, Jun 13, 2012, Garrison, Jim (ETW) wrote:
 
   -Original Message-
   From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
   us...@openssl.org] On Behalf Of Dr. Stephen Henson
   Sent: Wednesday, June 13, 2012 5:23 PM
   To: openssl-users@openssl.org
   Subject: Re: TLSv1.2 backward compatibility
   
   On Wed, Jun 13, 2012, Garrison, Jim (ETW) wrote:
   
Is anybody else having trouble with newer SSL clients (1.0.1c
   specifically) causing older servers to hang?
   
   
   Yes, see PR#2771.
   
   
Reading the 1.0.1c release notes I see
   
3. If all else fails setting OPENSSL_NO_TLS1_2_CLIENT will
   disable
TLS 1.2 client support entirely.
   
Is this something that can be set at runtime, or is it purely a
   compile-time option?
   
   Yes you can set SSL_OP_NO_TLSv1_2 and possibly SSL_OP_NO_TLSv1_1 too.
  
  Sorry if I seem dense, but how do I set this at runtime? I tried 
  creating an environment variable as in:
  
  export SSL_OP_NO_TLSv1_2=1
  export SSL_OP_NO_TLSv1_1=1
  openssl s_client -connect remoteserver:443
  
  but this gets the same hang, both with s_client and the svn client, and 
  Wireshark shows it's still sending a TLSv1.2 handshake.
  
 
 Ah I see, the application needs to support it for that to work. For example a
 call to:
 
 SSL_CTX_set_options(ctx, SSL_OP_NO_TLSv1_1);
 
 after SSL_CTX_new. But that will need modification to the application (but not
 OpenSSL itself). There isn't an environment variable to set this.
 
 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
  

RE: Renegotiation

[Jason Schultz]

Dr. Henson, (and the rest of the list)- I'm still having problems getting my 
server to renegotiate correctly.  I'll describe the basic scenario again and 
how I'm handling it, then ask some questions.  Again, I'm running 0.9.8r 1.  My 
server is sending a large amount of data to the peer, so SSL_write() is being 
called over and over, getting blocked several time, then continuing when the 
socket is writeable again. 2.  While the server is sending data, the client 
sends a ClientHello(with renegotation info).  I verify this with traces in the 
client. 3.  After that, a call to SSL_write() returns -1, and calling 
SSL_get_error() returns SSL_ERROR_WANT_WRITE.* As I understand it, at this 
point, I need to make sure the socket is writeable and then call SSL_write() 
again. 4. The server poll()s on the socket several times until the file 
descriptor is writeable.  I should note that when the server polls, it doesn't 
even poll for readability on the socket, POLLIN is removed from events in the 
pollinfo struct.  The server doesn't care if it's readable, it needs to call 
SSL_write() for the socket.  (I mention this because when I did poll for reads, 
I encountered the error scenario in my previous email.  The socket would be 
readable, and the server would call SSL_read(), the ClientHello would be read 
in, but the server gets a bad write retry error.  The way my server is coded, 
its' easier to not even ask for readability on the socket. 5.  The socket tells 
me it is writeable, so the server calls SSL_write().  I have message callbacks 
implemented in my server so I can examine SSL packets coming in.  I would 
expect the SSL_write() to read in the ClientHello at this point, since the peer 
sent it.  But why wouldn't the SSL_write have returned WANT_READ at this point, 
when the ClientHello is coming in?  Just curious, but I am doing what the 
protocol tells me to do by calling SSL_write() 6.  The call to SSL_write 
essentially just keeps sending the data that in the buffer I was sending from.  
I also know that internally in OpenSSL, there is data to write in it's buffer.  
In the function do_ssl3_write(), I log what's in s-s3-wbuf.left if it is not 
zero, which it's not at this point.  So after SSL_write() keeps returning 
either the number of bytes it has written, or that it's blocked and I need to 
poll again, I keep calling it, all of the data is written out, and the 
ClientHello is never read by the protocol.  Once the data is all written, my 
server closes the connection. So my most general question is, is there 
something obvious I'm doing wrong? Do I need to be polling for reads in step 4? 
 I don't think I should care if the socket is readable, since I need to wait 
until the socket is writable before calling SSL_write() again.  At least that's 
what OpenSSL is telling me. Why does SSL_write() never return WANT_READ when 
the ClientHello will be read in internally by the protocol?  Seems backwards to 
me. Do I need to do anything in particular in step 5 when calling SSL_write()?  
If I understand correctly, I'm supposed to call the function with the same 
params as the last call, which is what I'm pretty sure I'm doing.  So why does 
the protocol never see the ClientHello? Any help is appreciated, because I 
think I'm doing what OpenSSL is telling me to do.
  Date: Tue, 7 Feb 2012 19:47:59 +0100
 From: st...@openssl.org
 To: jetso...@hotmail.com
 Subject: Re: Renegotiation
 
 On Tue, Feb 07, 2012, Jason Schultz wrote:
 
  
  Dr. Henson-
   
  I've sent this question to the OpenSSL mailing list, but have not received 
  any responses to this point.   I hope I am sending it to the correct list.  
  I know you're one of the main OpenSSL developers, so I'm sending this 
  directly to you to hopefully help figure out what might be happening.  I 
  know it's somewhat of an involved question, but I'm struggling to figure it 
  out.  At this point, it seems like OpenSSL is not handling the situation 
  correctly.  I would be willing to do some more diagnostic work to drill 
  down into what the problem is, per your suggestions, or anyone elses.  The 
  following is the original message to the list.  Thanks for any help you can 
  provide.
   
  I have implemented a server using OpenSSL 0.9.8r.  If I use s_client to 
  open a 
  connection to a listenening SSL port on the server, and use the R commend 
  to 
  initiate a rehandshake, the rehandshake completes successfully(as 
  expected).  I 
  have verified this using both SSL 3.0 and TLS 1.0. 
  
   
  Another client(non-OpenSSL) opens a connection to my server with a 
  successful 
  initial handshake as well.  The client is basically an FTP client, and it 
  then 
  initiates a data transfer with a get, so my server is sending data to the 
  client.  During this transfer, the client sends a Client Hello to 
  renegotiate.  
  My server, using poll() to look for activated sockets, ends up calling 
  SSL_read() and reads in the Client Hello.  However

RE: Renegotiation question

[Jason Schultz]

My apologies for accidently spamming the list with this message, my web based 
email was having issues.
 
I am still unable to successfully rehandshake in the scenario below, and was 
wondering if anyone might have some ideas.  Is this the proper list for this 
email?
 
Thanks.
 



From: jetso...@hotmail.com
To: openssl-users@openssl.org
Subject: Renegotiation question
Date: Fri, 27 Jan 2012 15:33:36 +






I have implemented a server using OpenSSL 0.9.8r.  If I use s_client to open a 
connection to a listenening SSL port on the server, and use the R commend to 
initiate a rehandshake, the rehandshake completes successfully(as expected).  I 
have verified this using both SSL 3.0 and TLS 1.0.
 
Another client(non-OpenSSL) opens a connection to my server with a successful 
initial handshake as well.  The client is basically an FTP client, and it then 
initiates a data transfer with a get, so my server is sending data to the 
client.  During this transfer, the client sends a Client Hello to renegotiate.  
My server, using poll() to look for activated sockets, ends up calling 
SSL_read() and reads in the Client Hello.  However, OpenSSL gets an error, 
“SSL3_WRITE_PENDING:bad write retry”.  I’ve dug around a little in the OpenSSL 
code and added some debug code to try to follow what is happening.  From what I 
can tell, the following is taking place:
 
-  Client and server establish a connection and my server is sending 
data with repeated calls to SSL_write()
-  While server is writing data, client initiates a renegotiation, and 
sends a Client Hello
-  SSL_write() on the server returns -1 with SSL_ERROR_WANT_READ, 
presumably after the Client Hello comes in
-  Server calls SSL_read() and reads in the Client Hello
(I have info_cb functionality implemented that dump out handshake messages, the 
message looks OK)
-  OpenSSL calls ssl3_get_client_hello(); I added a syslog() when the 
state changes to SSL3_ST_SR_CLNT_HELLO_B
-  ssl3_get_client_hello() returns successfully; I added a syslog when 
the state gets changed to SSL3_ST_SW_SRVR_HELLO_A to verify this.
-  ssl3_send_server_hello() is called
-  The ssl3_send_server_hello() will lead to calls to the following 
functions, in order: ssl3_write_bytes(), do_ssl3_write(), and 
ssl3_write_pending().
-  Meanwhile, the previous calls to SSL_write have data left to send 
and a call to ssl3_write_pending() is being made from do_ssl3_write().  I’m not 
sure of the code path from the server calling SSL_write() to 
do_ssl3_write()/ssl3_write_pending(), but I see do_ssl3_write() calling 
ssl3_write_pending() several times during the file transfer.
 
Does this scenario sound like it should be working?  I’m not sure what my 
server could be doing wrong?  A couple notes, 
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is not set on my server.  I’m not sure that 
it should or needs to be, I did notice in the code that that mode is one of the 
conditions that is checked for when throwing the SSL_R_BAD_WRITE_RETRY error.  
From what I’ve read, the SSL3_WRITE_PENDING error is caused by calling 
SSL_write() after getting SSL_ERROR_WANT_READ/WRITE with a different buffer 
than before.  However, my server is not calling SSL_write() after it gets the 
SSL_ERROR_WANT_READ error when the Client Hello comes in.  So it seems to me 
the error is being thrown because OpenSSL is internally calling 
ssl3_write_pending() incorrectly.
 
I have some traces of the scenario but I did not include them, they may make 
things more confusing.  They exists in two different places, logging in my 
server before/after SSL_read and SSL_write 
calls(SSL_get_error()/ERR_error_string() calls) as well as info_cb and msg_cb 
message that display the SSL records coming in and going out.  A separate trace 
exists of some syslog() calls I added to the OpenSSL code.  I know there is a 
way to build OpenSSL in debug mode, but I haven’t taken the time to do this 
yet.  Please advise if I should look at doing that, or include the logging I do 
have.
 
Thanks in advance. 
  

Renegotiation question (one more try)

[Jason Schultz]

My apologies again, my posts were somehow got attached to an earlier 
conversation.  Posting one more time to place the message at the top of the 
list:
 
I have implemented a server using OpenSSL 0.9.8r.  If I use s_client to open a 
connection to a listenening SSL port on the server, and use the R commend to 
initiate a rehandshake, the rehandshake completes successfully(as expected).  I 
have verified this using both SSL 3.0 and TLS 1.0. 

 
Another client(non-OpenSSL) opens a connection to my server with a successful 
initial handshake as well.  The client is basically an FTP client, and it then 
initiates a data transfer with a get, so my server is sending data to the 
client.  During this transfer, the client sends a Client Hello to renegotiate.  
My server, using poll() to look for activated sockets, ends up calling 
SSL_read() and reads in the Client Hello.  However, OpenSSL gets an error, 
“SSL3_WRITE_PENDING:bad write retry”.  I’ve dug around a little in the OpenSSL 
code and added some debug code to try to follow what is happening.  
 
From what I can tell, the following is taking place: 

-  Client and server establish a connection and my server is sending 
data with repeated calls to SSL_write() 
-  While server is writing data, client initiates a renegotiation, and 
sends a Client Hello 
-  SSL_write() on the server returns -1 with SSL_ERROR_WANT_READ, 
presumably after the Client Hello comes in 
-  Server calls SSL_read() and reads in the Client Hello 
(I have info_cb functionality implemented that dump out handshake messages, the 
message looks OK) 
-  OpenSSL calls ssl3_get_client_hello(); I added a syslog() when the 
state changes to SSL3_ST_SR_CLNT_HELLO_B 
-  ssl3_get_client_hello() returns successfully; I added a syslog when 
the state gets changed to SSL3_ST_SW_SRVR_HELLO_A to verify this. 
-  ssl3_send_server_hello() is called 
-  The ssl3_send_server_hello() will lead to calls to the following 
functions, in order: ssl3_write_bytes(), do_ssl3_write(), and 
ssl3_write_pending(). 
-  Meanwhile, the previous calls to SSL_write have data left to send 
and a call to ssl3_write_pending() is being made from do_ssl3_write().  I’m not 
sure of the code path from the server calling SSL_write() to 
do_ssl3_write()/ssl3_write_pending(), but I see do_ssl3_write() calling 
ssl3_write_pending() several times during the file transfer. 

 
Does this scenario sound like it should be working?  I’m not sure what my 
server could be doing wrong?  A couple notes, 
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is not set on my server.  I’m not sure that 
it should or needs to be, I did notice in the code that that mode is one of the 
conditions that is checked for when throwing the SSL_R_BAD_WRITE_RETRY error.  
From what I’ve read, the SSL3_WRITE_PENDING error is caused by calling 
SSL_write() after getting SSL_ERROR_WANT_READ/WRITE with a different buffer 
than before.  However, my server is not calling SSL_write() after it gets the 
SSL_ERROR_WANT_READ error when the Client Hello comes in.  So it seems to me 
the error is being thrown because OpenSSL is internally calling 
ssl3_write_pending() incorrectly. 

 
I have some traces of the scenario but I did not include them, they may make 
things more confusing.  They exists in two different places, logging in my 
server before/after SSL_read and SSL_write 
calls(SSL_get_error()/ERR_error_string() calls) as well as info_cb and msg_cb 
message that display the SSL records coming in and going out.  A separate trace 
exists of some syslog() calls I added to the OpenSSL code.  I know there is a 
way to build OpenSSL in debug mode, but I haven’t taken the time to do this 
yet.  Please advise if I should look at doing that, or include the logging I do 
have. 

Thanks in advance. 

  

Renegotiation question

[Jason Schultz]

I have implemented a server using OpenSSL 0.9.8r.  If I use s_client to open a 
connection to a listenening SSL port on the server, and use the R commend to 
initiate a rehandshake, the rehandshake completes successfully(as expected).  I 
have verified this using both SSL 3.0 and TLS 1.0.
 
Another client(non-OpenSSL) opens a connection to my server with a successful 
initial handshake as well.  The client is basically an FTP client, and it then 
initiates a data transfer with a get, so my server is sending data to the 
client.  During this transfer, the client sends a Client Hello to renegotiate.  
My server, using poll() to look for activated sockets, ends up calling 
SSL_read() and reads in the Client Hello.  However, OpenSSL gets an error, 
“SSL3_WRITE_PENDING:bad write retry”.  I’ve dug around a little in the OpenSSL 
code and added some debug code to try to follow what is happening.  From what I 
can tell, the following is taking place:
 
-  Client and server establish a connection and my server is sending 
data with repeated calls to SSL_write()
-  While server is writing data, client initiates a renegotiation, and 
sends a Client Hello
-  SSL_write() on the server returns -1 with SSL_ERROR_WANT_READ, 
presumably after the Client Hello comes in
-  Server calls SSL_read() and reads in the Client Hello
(I have info_cb functionality implemented that dump out handshake messages, the 
message looks OK)
-  OpenSSL calls ssl3_get_client_hello(); I added a syslog() when the 
state changes to SSL3_ST_SR_CLNT_HELLO_B
-  ssl3_get_client_hello() returns successfully; I added a syslog when 
the state gets changed to SSL3_ST_SW_SRVR_HELLO_A to verify this.
-  ssl3_send_server_hello() is called
-  The ssl3_send_server_hello() will lead to calls to the following 
functions, in order: ssl3_write_bytes(), do_ssl3_write(), and 
ssl3_write_pending().
-  Meanwhile, the previous calls to SSL_write have data left to send 
and a call to ssl3_write_pending() is being made from do_ssl3_write().  I’m not 
sure of the code path from the server calling SSL_write() to 
do_ssl3_write()/ssl3_write_pending(), but I see do_ssl3_write() calling 
ssl3_write_pending() several times during the file transfer.
 
Does this scenario sound like it should be working?  I’m not sure what my 
server could be doing wrong?  A couple notes, 
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is not set on my server.  I’m not sure that 
it should or needs to be, I did notice in the code that that mode is one of the 
conditions that is checked for when throwing the SSL_R_BAD_WRITE_RETRY error.  
From what I’ve read, the SSL3_WRITE_PENDING error is caused by calling 
SSL_write() after getting SSL_ERROR_WANT_READ/WRITE with a different buffer 
than before.  However, my server is not calling SSL_write() after it gets the 
SSL_ERROR_WANT_READ error when the Client Hello comes in.  So it seems to me 
the error is being thrown because OpenSSL is internally calling 
ssl3_write_pending() incorrectly.
 
I have some traces of the scenario but I did not include them, they may make 
things more confusing.  They exists in two different places, logging in my 
server before/after SSL_read and SSL_write 
calls(SSL_get_error()/ERR_error_string() calls) as well as info_cb and msg_cb 
message that display the SSL records coming in and going out.  A separate trace 
exists of some syslog() calls I added to the OpenSSL code.  I know there is a 
way to build OpenSSL in debug mode, but I haven’t taken the time to do this 
yet.  Please advise if I should look at doing that, or include the logging I do 
have.
 
Thanks in advance.
  

Renegotiation question

[Jason Schultz]

I have implemented a server using OpenSSL 0.9.8r.  If I use s_client to open a 
connection to a listenening SSL port on the server, and use the R commend to 
initiate a rehandshake, the rehandshake completes successfully(as expected).  I 
have verified this using both SSL 3.0 and TLS 1.0.
 
Another client(non-OpenSSL) opens a connection to my server with a successful 
initial handshake as well.  The client is basically an FTP client, and it then 
initiates a data transfer with a get, so my server is sending data to the 
client.  During this transfer, the client sends a Client Hello to renegotiate.  
My server, using poll() to look for activated sockets, ends up calling 
SSL_read() and reads in the Client Hello.  However, OpenSSL gets an error, 
“SSL3_WRITE_PENDING:bad write retry”.  I’ve dug around a little in the OpenSSL 
code and added some debug code to try to follow what is happening.  From what I 
can tell, the following is taking place:
 
-  Client and server establish a connection and my server is sending 
data with repeated calls to SSL_write()
-  While server is writing data, client initiates a renegotiation, and 
sends a Client Hello
-  SSL_write() on the server returns -1 with SSL_ERROR_WANT_READ, 
presumably after the Client Hello comes in
-  Server calls SSL_read() and reads in the Client Hello
(I have info_cb functionality implemented that dump out handshake messages, the 
message looks OK)
-  OpenSSL calls ssl3_get_client_hello(); I added a syslog() when the 
state changes to SSL3_ST_SR_CLNT_HELLO_B
-  ssl3_get_client_hello() returns successfully; I added a syslog when 
the state gets changed to SSL3_ST_SW_SRVR_HELLO_A to verify this.
-  ssl3_send_server_hello() is called
-  The ssl3_send_server_hello() will lead to calls to the following 
functions, in order: ssl3_write_bytes(), do_ssl3_write(), and 
ssl3_write_pending().
-  Meanwhile, the previous calls to SSL_write have data left to send 
and a call to ssl3_write_pending() is being made from do_ssl3_write().  I’m not 
sure of the code path from the server calling SSL_write() to 
do_ssl3_write()/ssl3_write_pending(), but I see do_ssl3_write() calling 
ssl3_write_pending() several times during the file transfer.
 
Does this scenario sound like it should be working?  I’m not sure what my 
server could be doing wrong?  A couple notes, 
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is not set on my server.  I’m not sure that 
it should or needs to be, I did notice in the code that that mode is one of the 
conditions that is checked for when throwing the SSL_R_BAD_WRITE_RETRY error.  
From what I’ve read, the SSL3_WRITE_PENDING error is caused by calling 
SSL_write() after getting SSL_ERROR_WANT_READ/WRITE with a different buffer 
than before.  However, my server is not calling SSL_write() after it gets the 
SSL_ERROR_WANT_READ error when the Client Hello comes in.  So it seems to me 
the error is being thrown because OpenSSL is internally calling 
ssl3_write_pending() incorrectly.
 
I have some traces of the scenario but I did not include them, they may make 
things more confusing.  They exists in two different places, logging in my 
server before/after SSL_read and SSL_write 
calls(SSL_get_error()/ERR_error_string() calls) as well as info_cb and msg_cb 
message that display the SSL records coming in and going out.  A separate trace 
exists of some syslog() calls I added to the OpenSSL code.  I know there is a 
way to build OpenSSL in debug mode, but I haven’t taken the time to do this 
yet.  Please advise if I should look at doing that, or include the logging I do 
have.
 
Thanks in advance.
  

Renegotiation question

[Jason Schultz]

I have implemented a server using OpenSSL 0.9.8r.  If I use s_client to open a 
connection to a listenening SSL port on the server, and use the R commend to 
initiate a rehandshake, the rehandshake completes successfully(as expected).  I 
have verified this using both SSL 3.0 and TLS 1.0.
 
Another client(non-OpenSSL) opens a connection to my server with a successful 
initial handshake as well.  The client is basically an FTP client, and it then 
initiates a data transfer with a get, so my server is sending data to the 
client.  During this transfer, the client sends a Client Hello to renegotiate.  
My server, using poll() to look for activated sockets, ends up calling 
SSL_read() and reads in the Client Hello.  However, OpenSSL gets an error, 
“SSL3_WRITE_PENDING:bad write retry”.  I’ve dug around a little in the OpenSSL 
code and added some debug code to try to follow what is happening.  From what I 
can tell, the following is taking place:
 
-  Client and server establish a connection and my server is sending 
data with repeated calls to SSL_write()
-  While server is writing data, client initiates a renegotiation, and 
sends a Client Hello
-  SSL_write() on the server returns -1 with SSL_ERROR_WANT_READ, 
presumably after the Client Hello comes in
-  Server calls SSL_read() and reads in the Client Hello
(I have info_cb functionality implemented that dump out handshake messages, the 
message looks OK)
-  OpenSSL calls ssl3_get_client_hello(); I added a syslog() when the 
state changes to SSL3_ST_SR_CLNT_HELLO_B
-  ssl3_get_client_hello() returns successfully; I added a syslog when 
the state gets changed to SSL3_ST_SW_SRVR_HELLO_A to verify this.
-  ssl3_send_server_hello() is called
-  The ssl3_send_server_hello() will lead to calls to the following 
functions, in order: ssl3_write_bytes(), do_ssl3_write(), and 
ssl3_write_pending().
-  Meanwhile, the previous calls to SSL_write have data left to send 
and a call to ssl3_write_pending() is being made from do_ssl3_write().  I’m not 
sure of the code path from the server calling SSL_write() to 
do_ssl3_write()/ssl3_write_pending(), but I see do_ssl3_write() calling 
ssl3_write_pending() several times during the file transfer.
 
Does this scenario sound like it should be working?  I’m not sure what my 
server could be doing wrong?  A couple notes, 
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is not set on my server.  I’m not sure that 
it should or needs to be, I did notice in the code that that mode is one of the 
conditions that is checked for when throwing the SSL_R_BAD_WRITE_RETRY error.  
From what I’ve read, the SSL3_WRITE_PENDING error is caused by calling 
SSL_write() after getting SSL_ERROR_WANT_READ/WRITE with a different buffer 
than before.  However, my server is not calling SSL_write() after it gets the 
SSL_ERROR_WANT_READ error when the Client Hello comes in.  So it seems to me 
the error is being thrown because OpenSSL is internally calling 
ssl3_write_pending() incorrectly.
 
I have some traces of the scenario but I did not include them, they may make 
things more confusing.  They exists in two different places, logging in my 
server before/after SSL_read and SSL_write 
calls(SSL_get_error()/ERR_error_string() calls) as well as info_cb and msg_cb 
message that display the SSL records coming in and going out.  A separate trace 
exists of some syslog() calls I added to the OpenSSL code.  I know there is a 
way to build OpenSSL in debug mode, but I haven’t taken the time to do this 
yet.  Please advise if I should look at doing that, or include the logging I do 
have.
 
Thanks in advance.
  

RE: OpenSSL server problems

[Jason Schultz]

I think it does, but don't know for sure.  Can you just try it on your system?

 

 openssl dgst -sha256 filename

 


 
 Subject: RE: OpenSSL server problems
 Date: Tue, 9 Mar 2010 12:28:28 -0500
 From: chr...@motorola.com
 To: openssl-users@openssl.org
 CC: openssl-...@openssl.org
 
 Hi All,
 
 I am somewhat of a newbie to openssl, so apologize in advance for my
 ignorance :-)
 
 I have openssl version 0.9.8g on my custom Linux 2.6.27 distro.
 
 I need to make sure that SHA-2 (specifically SHA-256 algorithm) is
 supported with this version of openssl. 
 The sha-256 algorithm will be used during IPSec link establishment,
 Certificates Verification, and for general TLS/SSL Cipher suites.
 
 From the quick online reading, I am getting mixed messages of whether
 sha-2 algorithms (specifically sha-256) is truly supported or not ?!?
 Supposedly things might still be hard-coded to sha-1 even when sha-2
 algorithms are 'supported' ?...
 
 1. Would you kindly clarify if openssl version 0.9.8g does infact meet
 my needs ? That is, does it in fact support sha-256 to be used in IPSec,
 Certificate verification, and general TLS/SSL.
 
 2. If 0.9.8g is not adequate, what version of openssl does infact
 support my needs described above ?
 
 Thanks soo much in advance.
 
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing List openssl-users@openssl.org
 Automated List Manager majord...@openssl.org
  

RE: Another memory growing on AIX (fwd)

[Jason Schultz]

I'm just curious, what was the offending library?  I have seen similar memory 
issues in the past that I never had a chance to get to the bottom of, actually 
openssl behaved differently between 0.9.8i and 0.9.8j.  But I'm wondering what 
library you had to work around.

 

Thanks.


 
 From: psu...@pittstate.edu
 Subject: Re: Another memory growing on AIX (fwd)
 To: openssl-users@openssl.org
 Date: Mon, 1 Mar 2010 13:21:31 -0600
 
  
  Tim Hudson wrote:
  
   Can you make a small test program which demonstrates this behaviour?
  
   Typically some cleanup code is being missed when this is sort of thing is 
   raised; however a bit of test code makes it fairly easy to track down 
   using a 
   combination of the malloc wrapper functions, valgrind and purify.
  
  I'll try. Currently all the functionality is in a library that
  wraps openssl, but I should be able to make single test program.
  I'll be out of the office until Monday, and will try to get to it
  then. Thanks.
  
  -Mike
 
 Update: The memory leak is NOT in openssl. 
 
 While getrusage() did indeed indicate that all growth in process size 
 occurred within SSL_connect(), it seems likely that's because some other
 non-openssl library was not properly freeing some small amounts of
 memory (136 bytes per connection); and this caused memory avaiable for
 reallocation to gradually decline over the hundreds (and indeed thousands)
 of connections being performed. As this progressed, SSL_connect()
 occasionally requested more than was available, and so the process size 
 increased. But to reiterate, the problem is actually in a different library, 
 not in openssl. I was able to work around the offending library, and when I 
 did the process memory size was steady over 24,000 connections.
 
 My sincere apologies for the false alarm.
 
 -Mike
 
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing List openssl-users@openssl.org
 Automated List Manager majord...@openssl.org
  

RE: Post-2010 future of the OpenSSL FIPS Object Module?

[Jason Schultz]

One point of confusion for me, I read this email to say the OpenSSL FIPS Object 
Module v1.2 will(may?) not be usable beyond 2010.  But in the first discussion 
link, I read that to say that the v1.2 Module will not be suitable for private 
label validations(which require changes to FIPS module code and/or build 
process).  

 

Is it accurate to say that using the FIPS module as described in the 2nd bullet 
here: http://openssl.org/docs/fips/fipsnotes.html, with no changes and building 
as described on your platform, that it can be used as a validated cryptographic 
module beyond 2010? 

 

I beleive the above to be true, this email cast some doubt, however.

 

Thanks.


 
 Date: Thu, 18 Feb 2010 17:27:54 -0500
 From: marqu...@opensslfoundation.com
 To: openssl-users@openssl.org
 Subject: Post-2010 future of the OpenSSL FIPS Object Module?
 
 In the three years since the open source based FIPS 140-2 validated 
 OpenSSL FIPS Object Module became available many software vendors have 
 directly or indirectly utilized it to realize substantial cost and 
 schedule savings. We're glad to see the widespread benefits of these 
 hard won validations.
 
 Recently I've been contacted by many OpenSSL users and software vendors 
 concerned about upcoming changes announced by the CMVP (the government 
 agency responsible for FIPS 140-2 validations). Briefly stated, these 
 changes will mean that the current OpenSSl FIPS Object Module v1.2 may 
 not be usable beyond the current year (see 
 http://openssl.org/docs/fips/fipsnotes.html for some more discussion).
 
 Those concerns are not relieved when I respond that we have no plans at 
 present to pursue a new validation that would result in a OpenSSL FIPS 
 Object Module usable after 2010. However, that situation is due to a 
 lack of funding and not a lack of interest on our part. We will tackle 
 a new validation with enthusiasm at the first opportunity.
 
 The purpose of this open message is twofold:
 
 First, to note that we are actively soliciting sponsors for a post-2010 
 FIPS 140-2 validation of the OpenSSL FIPS Object Module. We don't know 
 the precise cost for several reasons including the number of platforms 
 that would be covered, the degree of refactoring that would be 
 appropriate, or the resolution of several ambiguous areas in the draft 
 CMVP transition announcements. However, we're fairly comfortable that 
 the total cost would be in the range of US$50,000 to US$150,000. That's 
 a huge sum to us but a relatively modest amount for some major 
 corporations utilizing OpenSSL.
 
 Second, to note that I consider it highly probable that we will 
 eventually find funding for this effort, the real question is whether 
 that funding will materialize in time to obtain a new validation before 
 the current one becomes obsolete. The economics are simply too 
 compelling for any of a number of large software vendors that would 
 otherwise be faced with paying a comparable cost for commercial 
 proprietary licenses. One or more of these vendors will do the math 
 and, reluctantly, step forward to make it happen. The reluctance is 
 understandable because that vendor will effectively be carrying the 
 burden for the entire industry; that's one of the dilemmas of the open 
 source world.
 
 It would make more sense for multiple vendors to jointly sponsor the 
 cost. I encourage any potential sponsors to contact us with the amount 
 they would be willing to sponsor and the specific platforms they would 
 want included. We'll keep track of the total until we think we have 
 enough to launch a validation effort. then pull everyone together to 
 make it happen.
 
 As for timing, note that a six month timeframe to obtain a validation is 
 the most optimistic I would dare hope for. Nine or more months is more 
 realistic. One apparently uncomplicated validation we worked on took 
 thirteen months, and the very first open source based validation took 
 five years. It's not a speedy process and it can't be hurried once the 
 paperwork is submitted to the CMVP, and that's the stage that consumes 
 the most time. The sooner we can start the better.
 
 Thanks,
 
 -Steve M.
 
 -- 
 Steve Marquess
 OpenSSL Software Foundation, Inc.
 1829 Mount Ephraim Road
 Adamstown, MD 21710
 USA
 +1 877-673-6775
 marqu...@opensslfoundation.com
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing List openssl-users@openssl.org
 Automated List Manager majord...@openssl.org
  

Memory utilization in openssl 0.9.8j

[Jason Schultz]

Greetings.
 
I have recently done some testing with OpenSSL versions 0.9.8i and 0.9.8j.  
Basically, the application is opening 10,000 connections between a client and 
server on the same Linux machine.  I've noticed quite a difference in memory 
utilization when monitered with the top command.
 
0.9.8i will show an increase in memory from before the connections being opened 
to after of maybe 1-2 GB.  (The system has 32 GB available)  With 0.9.8j, from 
before the connections being opened to after, an increase of 12+ GB is 
observed.  This is quite a difference, and may be causing some problems.  At 
one point, the program seg faulted with a double free or corruption error.  I 
can  not reproduce this consistently, however.
 
Everything runs well with version 0.9.8i.  I'm wondering if anyone might know 
what is responsible for the significant difference in memory usage between the 
two versions?  I have done some searching, and found one issue with a memory 
leak in version 0.9.8j:
 
http://article.gmane.org/gmane.comp.encryption.openssl.devel/14996
 
But I don't think this is what I am seeing.
 
From the CHANGES log, I noticed that TLS extensions are enabled by default in 
0.9.8j, but don't know if that's the reason for the increase in memory usage.
 
Thanks in advance.




__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

[no subject]

[Jason Schultz]

Greetings.
 
I have recently done some testing with OpenSSL versions 0.9.8i and 0.9.8j.  
Basically, the application is opening 10,000 connections between a client and 
server on the same Linux machine.  I've noticed quite a difference in memory 
utilization when monitered with the Linux top command.
 
0.9.8i will show an increase in memory from before the connections being opened 
to after of maybe 1 GB.  (The system has 32 GB available)  With 0.9.8j, from 
before the connections being opened to after, an increase of 12+ GB is 
observed.  This is quite a difference, and may be causing some problems.  At 
one point, the program seg faulted with a double free or corruption error.  I 
can  not reproduce this consistently, however.
 
Everything runs well with version 0.9.8i.  I'm wondering if anyone might know 
what is responsible for the significant difference in memory usage between the 
two versions?  I should be using the same SSL CTX for all of the connections.  
Hopefully I'm providing enough information.
 
I have done some searching, and found one issue with a memory leak in version 
0.9.8j:
 
http://article.gmane.org/gmane.comp.encryption.openssl.devel/14996
 
But I don't think this is the issue I am seeing.
 
From the CHANGES log, I noticed that TLS extensions are enabled by default in 
0.9.8j, but don't know if that's the reason for the increase in memory usage?
 
Thanks in advance.

 __
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Memory untilization in version 0.9.8j

[Jason Schultz]

Forgot to include a subject line, my apoligies.  


 From: jetso...@hotmail.com
 To: openssl-users@openssl.org
 Subject:
 Date: Tue, 24 Feb 2009 14:48:01 +


 Greetings.

 I have recently done some testing with OpenSSL versions 0.9.8i and 0.9.8j. 
 Basically, the application is opening 10,000 connections between a client and 
 server on the same Linux machine. I've noticed quite a difference in memory 
 utilization when monitered with the Linux top command.

 0.9.8i will show an increase in memory from before the connections being 
 opened to after of maybe 1 GB. (The system has 32 GB available) With 0.9.8j, 
 from before the connections being opened to after, an increase of 12+ GB is 
 observed. This is quite a difference, and may be causing some problems. At 
 one point, the program seg faulted with a double free or corruption error. 
 I can not reproduce this consistently, however.

 Everything runs well with version 0.9.8i. I'm wondering if anyone might know 
 what is responsible for the significant difference in memory usage between 
 the two versions? I should be using the same SSL CTX for all of the 
 connections. Hopefully I'm providing enough information.

 I have done some searching, and found one issue with a memory leak in version 
 0.9.8j:

 http://article.gmane.org/gmane.comp.encryption.openssl.devel/14996

 But I don't think this is the issue I am seeing.

 From the CHANGES log, I noticed that TLS extensions are enabled by default in 
 0.9.8j, but don't know if that's the reason for the increase in memory usage?

 Thanks in advance.

 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing List openssl-users@openssl.org
 Automated List Manager 
 majord...@openssl.org__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org