Re: Establishing connection errors
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, &empty_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
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, &empty_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
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
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 certificate): How do you set up the non_fips_libctx and how do you set up any certificate trust store within the SSL_CTX? -- Tomáš Mráz No matter
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 certificate): How do you set up the non_fips_libctx and how do you set up any certificate trust store within the SSL_CTX? -- 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.]
Establishing connection errors
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: ASN1 <-> DER encoding with application tag
On 04/11/2021 17:39, Max Larsson wrote:
But now I’m wondering how I can “cascade” using this method to influence
the encoding
to avoid the writing of the additional bytes after the OID gest encoded
and before
the innerToken is encoded:
*….. *0x05 0x05 0x02 *0x04 0x76* 0xa0 0x74….(here are a lot of bytes
omitted)
I think this is an entirely different problem.
0x04 corresponds to the universal tag for an OCTET STRING, and 0x76 is
the length of that OCTET STRING.
I assume what you want to see is 0xa0, which means a context specific
constructed type with tag 0, followed by data of length 0x74.
So, basically, it looks to me like your initial definition of the
GSSAPI_CONTEXTTOKEN object is wrong:
typedef struct ContextToken_st {
ASN1_OBJECT *mech;
ASN1_OCTET_STRING *innerContextToken;
} GSSAPI_CONTEXTTOKEN;
Since this clearly shows that the thing after the OID is an OCTET
STRING. So you really need to understand what the actual type is for
innerContextToken in order to correctly encode/decode it.
Matt
Best regards
Max
*From: *openssl-users on behalf of
Matt Caswell
*Date: *Thursday, 4. November 2021 at 17:14
*To: *openssl-users@openssl.org
*Subject: *Re: ASN1 <-> DER encoding with application tag
On 04/11/2021 13:58, Max Larsson wrote:
> i2d_GSSAPI_CONTEXTTOKEN( negToken,&p );
>
You can tell i2d to encode using "application" tagging like this:
ASN1_item_ex_i2d((const ASN1_VALUE **)&negToken, &p,
ASN1_ITEM_rptr(GSSAPI_CONTEXTTOKEN), 0,
ASN1_TFLG_APPLICATION);
Matt
> for( intlen = 0;len < bufferSize;len++ ) {
>
> if( ( len % 8) == 0)
>
> printf( " ");
>
> if( ( len % 16) == 0)
>
> printf( "\n\t\t");
>
> printf( " 0x%02x",(short)buffer[ len ] );
>
> }
>
> printf( "\n");
>
> . . .
>
> The code above output the following DER encoded structure (the
> difference marled in bold):
>
> *0**x**3**0**0**x**81 0x80*0x060x060x2b0x060x010x050x050x02*0x04
> 0x76*0xa00x74
>
> The google result, which I found seems to point into the direction to
> use application tags to encode.
>
> But I haven’t found any example or how to how to achieve this with
> openssl, can anyone give me sone hints?
>
> Best regards
>
> Max Larsson
>
> Mit freundlichen Grüßen
> Best regards
>
> Dipl.-Inform. Max Larsson
> Geschäftsleitung
>
>
>
> phone: +49(0)6151/62908-75
> fax:
> email: max.lars...@facilityboss.biz
>
> web: http://facilityboss.biz
>
>
>
>
> *facilityboss >*
> Bad Nauheimer Str. 4
> 64289 Darmstadt
> Germany
>
> Sitz der Gesellschaft: Darmstadt
> Registergericht: Amtsgericht Darmstadt, HRB 86193
> Geschäftsführer: Dipl.-Inform Max Lars Robert Larsson
>
>
>
> Diese E-Mail enthält unter Umständen vertrauliche und/oder rechtlich
> geschützte Informationen, die allein für den Adressaten bestimmt sind.
> Wenn Sie nicht der zutreffende Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, ist jede Verwendung, Verbreitung, Kopie oder
> Bezugnahme auf den Inhalt dieser E-Mail verboten. Bitte informieren Sie
> uns über einen eventuellen Irrtum per Telefon, per Telefax oder E-Mail.
>
> This e-mail may contain confidential and/or privileged information. If
> you are not the intended recipient, any disclosure, copying,
> distribution or reference on the contents of this e-mail is strictly
> prohibited. If you have received this e-mail in error please notify us
> by e-mail, facsimile or phone call.
>
