Re: configuring callbacks (or not) and SNI vs not... no shared cipher from server end

[Viktor Dukhovni]

On Wed, May 08, 2019 at 05:23:38PM -0500, Benjamin Kaduk via openssl-users 
wrote:

> > > In Postfix, it is configured with the same settings as the initial
> > > SSL_CTX, *but* no server certificates.  During the SNI callback I
> > > interpose the certificate-less context, and then set the certificate
> > > chain on the connection handle (SSL *) instead.
> > 
> > okay, I'll use Postfix as my reference :-)
> 
> For "how to use and switch SSL_CTXs" I'm sure it's admirable, but my
> understanding is that it's still using the legacy server_name callback
> (as opposed to the new client_hello_cb), and the new callback has a lot
> of advantages for architectural cleanliness and avoiding some surprising
> behavior with respect to the ordering of certain processing in the
> server.  So for a greenfield application I'd still suggest using the
> client_hello_cb (not that I'm entirely unbiased...).

The reason for the choice in Postfix is that we still support OpenSSL
1.0.2, which does not have the new interface.  So for now I'm using
the older interface which works with both 1.0.2 and 1.1.1.

Since in Postfix we not also doing anything exciting like ALPN, or
other exciting extensions, I don't expect any trouble from the
original callback, but perhaps I've not looked closely enough at
the potential drawbacks.  If there's good reason to expect trouble,
I'd like to hear what specifically might go wrong.

-- 
Viktor.

Re: Problems building for IOS and linking to libssh2

[Teja Prabhu]

https://stackoverflow.com/questions/6429494/undefined-symbols-for-architecture-armv7

Look at common cause 3 in the first answer. These are the undefined symbols:

"_ENGINE_load_builtin_engines", referenced from:
 _libssh2_init in global.c.o
 __libssh2_init_if_needed in global.c.o
 "_ENGINE_register_all_complete", referenced from:
 _libssh2_init in global.c.o
 __libssh2_init_if_needed in global.c.o

presumably you didn't recompile them for iOS.

Teja Prabhu


On Thu, May 9, 2019 at 12:11 AM rollas...@gmail.com 
wrote:

> Hello.
>
> I have built libssh2 with openssl in windows (MVC 2017), linux (GCC >6),
> mac (clang 8 - 10), android (NDK19 / API 21-24 / clang) successfully.
> Now I am stuck trying to build it for iOS. The error I get is about an
> undefined symbol as folows
>
> ld: warning: -headerpad_max_install_names is ignored when used with
> -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES)
> undefined symbols for architecture armv7:
>  "_ENGINE_load_builtin_engines", referenced from:
>  _libssh2_init in global.c.o
>  __libssh2_init_if_needed in global.c.o
>  "_ENGINE_register_all_complete", referenced from:
>  _libssh2_init in global.c.o
>  __libssh2_init_if_needed in global.c.o
> ld: symbol(s) not found for architecture armv7
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
>  From what I understand, the problem is that the static lib is not
> including a symbol?
>
> I am using XCode 10.2.1 and the command I used to build OpenSSL is
>
> ./Configure iphoneos-cross
> -lsysroot/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.2.sdk
>
> -mios-version-min=10.0 -fembed-bitcode -O3
> --sysroot=/Application/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.2.sdk
>
> -fPIC --with-zlib-include=/Users/roll/sdks/zlib/include
> --with-zlib-lib=/Users/roll/sdks/zlib/lib
>
> the build process ends without error and a libcrypto.a and libssl.a
> files are created.
>
> Can anybody point me what am I doing wrong or misunderstanding?
>
> Thanks in advance.
>
>

Re: configuring callbacks (or not) and SNI vs not... no shared cipher from server end

[Benjamin Kaduk via openssl-users]

On Wed, May 08, 2019 at 04:40:07PM -0400, Michael Richardson wrote:
> 
> Viktor Dukhovni  wrote:
> >> Diversionary issue:
> >> 
> https://www.openssl.org/docs/manmaster/man3/SSL_set_tlsext_host_name.html
> >> and:
> >> 
> https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_client_hello_cb.html
> >>
> >> are pretty vague.  I think that SSL_set_tlsext_host_name() is probably
> >> intended to be used on the client to set the SNI, but I'm not sure.
> 
> > Yes, e.g. in the Postfix TLS client:
> 
> > 
> https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1035-L1045
> 
> So, okay.
> Either this URL can go into the man page, or some short code extract could go 
> in.

Probably better to have a code snippet (filing a github issue or sending
a pull request would probably be good).

> >> The legacy cb function returns int, but it's values are not
> >> documented.
> 
> > On the server side I'm using SSL_CTX_set_tlsext_servername_callback():
> 
> > 
> https://github.com/vdukhovni/postfix/blob/2399e9e179ee025d03155fa3637cccab0a23ddce/postfix/src/tls/tls_misc.c#L1040-L1043
> > 
> https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_misc.c#L668
> 
> >> I guess the point is that CB can set the server certificate to
> >> something appropriate, or I think, it could just decide to ignore the
> >> SNI value completely and force the certificate regardless.
> 
> > Yes.
> 
> I can see that the CB provides comprehensive functionality, but I worry about
> applications trying to parse ClientHello extensions themselves and getting it 
> wrong.

It turns out that the server_name TLS extension is something of an
unfortunate exception in terms of the unneeded complexity in its
encoding.  When I wrote the client_hello_cb functionality (at the time,
know as the early_cb), I thought about whether I wanted to add a
dedicated API just for the SNI value, due to the level of complexity
involved.  I ended up not doing so in the initial submission, both
because I figured it could safely be added later as an incremental
change, and because I was worried (IIRC) about being tempted to expose
some of the PACKET_* APIs in the process, which is not really the right
architectural choice for OpenSSL.

There is, however, an existing implementation for extracting the SNI
value in the test code at
https://github.com/openssl/openssl/blob/master/test/handshake_helper.c#L150-L187
that has been successfully extracted and used in a couple places I know
of.

> >> What is the SNI functionality otherwise on the server?
> 
> > You can interpose a secondary "virtual-host-specific" SSL_CTX for for
> > the rest of the handshake.  This carries the server certificate, but
> > also the trust store settings for validating client certificates, the
> > settings to request (or not) client certificates, the verification
> > callbacks, ...  It is a rather heavyweight object, best cached and
> > re-used for multiple connections.
> 
> So, it's okay to change the SSL_CTX for an SSL* after creation.
> That is rather surprising to me, but I guess it's okay.
> I suppose I feel that there ought to be reference counts, but this is C, not 
> Rust.

There *are* reference counts.

> > In Postfix, it is configured with the same settings as the initial
> > SSL_CTX, *but* no server certificates.  During the SNI callback I
> > interpose the certificate-less context, and then set the certificate
> > chain on the connection handle (SSL *) instead.
> 
> okay, I'll use Postfix as my reference :-)

For "how to use and switch SSL_CTXs" I'm sure it's admirable, but my
understanding is that it's still using the legacy server_name callback
(as opposed to the new client_hello_cb), and the new callback has a lot
of advantages for architectural cleanliness and avoiding some surprising
behavior with respect to the ordering of certain processing in the
server.  So for a greenfield application I'd still suggest using the
client_hello_cb (not that I'm entirely unbiased...).

-Ben

> >> Is there any support for picking a certificate based upon the SNI
> >> name?
> 
> > The application does the "picking"...  The application sets one or more
> > certificate chains (one per supported public key algorithm) that best
> > match the SNI name, and then OpenSSL chooses one of these based on the
> > client's advertised supported signature algorithms, ...
> 
> What I was observing (wrongly) was that maybe the server was doing something
> itself if there was no callback, and it was failing.  This was from looking
> at the code around the error code that came out.
> This (see other email) proved to wildly incorrect.
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  

Problems building for IOS and linking to libssh2

[rollas...@gmail.com]

Hello.

I have built libssh2 with openssl in windows (MVC 2017), linux (GCC >6), 
mac (clang 8 - 10), android (NDK19 / API 21-24 / clang) successfully. 
Now I am stuck trying to build it for iOS. The error I get is about an 
undefined symbol as folows


ld: warning: -headerpad_max_install_names is ignored when used with 
-bitcode_bundle (Xcode setting ENABLE_BITCODE=YES)

undefined symbols for architecture armv7:
    "_ENGINE_load_builtin_engines", referenced from:
    _libssh2_init in global.c.o
    __libssh2_init_if_needed in global.c.o
    "_ENGINE_register_all_complete", referenced from:
    _libssh2_init in global.c.o
    __libssh2_init_if_needed in global.c.o
ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)


From what I understand, the problem is that the static lib is not 
including a symbol?


I am using XCode 10.2.1 and the command I used to build OpenSSL is

./Configure iphoneos-cross 
-lsysroot/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.2.sdk 
-mios-version-min=10.0 -fembed-bitcode -O3 
--sysroot=/Application/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.2.sdk 
-fPIC --with-zlib-include=/Users/roll/sdks/zlib/include 
--with-zlib-lib=/Users/roll/sdks/zlib/lib


the build process ends without error and a libcrypto.a and libssl.a 
files are created.


Can anybody point me what am I doing wrong or misunderstanding?

Thanks in advance.

Re: configuring callbacks (or not) and SNI vs not... no shared cipher from server end

[Viktor Dukhovni]

On Wed, May 08, 2019 at 04:40:07PM -0400, Michael Richardson wrote:

> > You can interpose a secondary "virtual-host-specific" SSL_CTX for for
> > the rest of the handshake.  This carries the server certificate, but
> > also the trust store settings for validating client certificates, the
> > settings to request (or not) client certificates, the verification
> > callbacks, ...  It is a rather heavyweight object, best cached and
> > re-used for multiple connections.
> 
> So, it's okay to change the SSL_CTX for an SSL* after creation.
> That is rather surprising to me, but I guess it's okay.
> I suppose I feel that there ought to be reference counts, but this is C, not 
> Rust.

It is not that sort of change "change", there's a call to insert a
an additional CTX that interposes between the SSL handle and its
parent context for most of the relevant data and function pointers.
The SSL handle is still ultimately tied to the same parent context.

> > In Postfix, it is configured with the same settings as the initial
> > SSL_CTX, *but* no server certificates.  During the SNI callback I
> > interpose the certificate-less context, and then set the certificate
> > chain on the connection handle (SSL *) instead.
> 
> okay, I'll use Postfix as my reference :-)

Fine by me. :-)

-- 
Viktor.

Re: configuring callbacks (or not) and SNI vs not... no shared cipher from server end

[Michael Richardson]

Viktor Dukhovni  wrote:
>> Diversionary issue:
>> https://www.openssl.org/docs/manmaster/man3/SSL_set_tlsext_host_name.html
>> and:
>> 
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_client_hello_cb.html
>>
>> are pretty vague.  I think that SSL_set_tlsext_host_name() is probably
>> intended to be used on the client to set the SNI, but I'm not sure.

> Yes, e.g. in the Postfix TLS client:

> 
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1035-L1045

So, okay.
Either this URL can go into the man page, or some short code extract could go 
in.

>> The legacy cb function returns int, but it's values are not
>> documented.

> On the server side I'm using SSL_CTX_set_tlsext_servername_callback():

> 
https://github.com/vdukhovni/postfix/blob/2399e9e179ee025d03155fa3637cccab0a23ddce/postfix/src/tls/tls_misc.c#L1040-L1043
> 
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_misc.c#L668

>> I guess the point is that CB can set the server certificate to
>> something appropriate, or I think, it could just decide to ignore the
>> SNI value completely and force the certificate regardless.

> Yes.

I can see that the CB provides comprehensive functionality, but I worry about
applications trying to parse ClientHello extensions themselves and getting it 
wrong.

>> What is the SNI functionality otherwise on the server?

> You can interpose a secondary "virtual-host-specific" SSL_CTX for for
> the rest of the handshake.  This carries the server certificate, but
> also the trust store settings for validating client certificates, the
> settings to request (or not) client certificates, the verification
> callbacks, ...  It is a rather heavyweight object, best cached and
> re-used for multiple connections.

So, it's okay to change the SSL_CTX for an SSL* after creation.
That is rather surprising to me, but I guess it's okay.
I suppose I feel that there ought to be reference counts, but this is C, not 
Rust.

> In Postfix, it is configured with the same settings as the initial
> SSL_CTX, *but* no server certificates.  During the SNI callback I
> interpose the certificate-less context, and then set the certificate
> chain on the connection handle (SSL *) instead.

okay, I'll use Postfix as my reference :-)

>> Is there any support for picking a certificate based upon the SNI
>> name?

> The application does the "picking"...  The application sets one or more
> certificate chains (one per supported public key algorithm) that best
> match the SNI name, and then OpenSSL chooses one of these based on the
> client's advertised supported signature algorithms, ...

What I was observing (wrongly) was that maybe the server was doing something
itself if there was no callback, and it was failing.  This was from looking
at the code around the error code that came out.
This (see other email) proved to wildly incorrect.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[




signature.asc
Description: PGP signature

Re: configuring callbacks (or not) and SNI vs not... no shared cipher from server end

[Viktor Dukhovni]

> On May 8, 2019, at 4:23 PM, Michael Richardson  wrote:
> 
> My questions about the documentation of the callbacks remain.
> Having solved the problem, I'm pretty certain the the "no shared cipher"
> error message is way too overloaded.

It sounds like you failed to load a matching key pair into the server's
SSL context (something that you would typically check as part of setting
the certificate chain and private key).  Once the server context has no
signing keys, it can only negotiate anon-DHE and anon-ECDHE ciphers, but
the client did not offer these, so you got "no shared cipher", which is
fact correct.

> Some piece of code is clearly doing something useful, which is to check if
> the public/private key match.  Unfortunately, that code is not announcing
> the mismatch in a useful way.

The check is done at configuration time.  You're likely not doing the key
setup "by the book":

   
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_certkey.c#L600-L623

-- 
Viktor.



-- 
Viktor.

Re: configuring callbacks (or not) and SNI vs not... no shared cipher from server end

[Michael Richardson]

My questions about the documentation of the callbacks remain.
Having solved the problem, I'm pretty certain the the "no shared cipher"
error message is way too overloaded.

Some piece of code is clearly doing something useful, which is to check if
the public/private key match.  Unfortunately, that code is not announcing
the mismatch in a useful way.

My provisioning script, due to a typo, was generating new CSRs, but sending
an ancient CSR with an old public key.  Writing up the problem, I eventually
noticed the public key dump from the private key file did not match the
dump from the certificate.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[





signature.asc
Description: PGP signature

Re: configuring callbacks (or not) and SNI vs not... no shared cipher from server end

[Viktor Dukhovni]

On Wed, May 08, 2019 at 02:15:43PM -0400, Michael Richardson wrote:

> Diversionary issue:
>  https://www.openssl.org/docs/manmaster/man3/SSL_set_tlsext_host_name.html
> and: 
> https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_client_hello_cb.html
> 
> are pretty vague.  I think that SSL_set_tlsext_host_name() is probably
> intended to be used on the client to set the SNI, but I'm not sure.

Yes, e.g. in the Postfix TLS client:


https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1035-L1045

> The legacy cb function returns int, but it's values are not documented.

On the server side I'm using SSL_CTX_set_tlsext_servername_callback():


https://github.com/vdukhovni/postfix/blob/2399e9e179ee025d03155fa3637cccab0a23ddce/postfix/src/tls/tls_misc.c#L1040-L1043

https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_misc.c#L668

> I guess the point is that CB can set the server certificate to something
> appropriate, or I think, it could just decide to ignore the SNI value
> completely and force the certificate regardless.

Yes.

> What is the SNI functionality otherwise on the server?

You can interpose a secondary "virtual-host-specific" SSL_CTX for
for the rest of the handshake.  This carries the server certificate,
but also the trust store settings for validating client certificates,
the settings to request (or not) client certificates, the verification
callbacks, ...  It is a rather heavyweight object, best cached and
re-used for multiple connections.

In Postfix, it is configured with the same settings as the initial
SSL_CTX, *but* no server certificates.  During the SNI callback I
interpose the certificate-less context, and then set the certificate
chain on the connection handle (SSL *) instead.

> Is there any support for picking a certificate based upon the SNI name?

The application does the "picking"...  The application sets one or
more certificate chains (one per supported public key algorithm)
that best match the SNI name, and then OpenSSL chooses one of these
based on the client's advertised supported signature algorithms,
...

-- 
Viktor.

OpenSSL 1.1.1b tests fail on Solaris

[John Unsworth]

I have build OpenSSL 1.1.1b 64 bit on Solaris SunOS 5.10 Generic_Virtual sun4v 
sparc SUNW,T5140.

./Configure -lrt solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 
-xldscope=hidden

It builds fine but all the tests fail, with or without no-asm. Can anyone help 
please? Here is the start of the test run:

$ make test
make depend && make _tests
( cd test; \
  mkdir -p test-runs; \
  SRCTOP=../. \
  BLDTOP=../. \
  RESULT_D=test-runs \
 PERL="/opt/perl-5.26.1/bin/perl" \
  EXE_EXT= \
  OPENSSL_ENGINES=`cd .././engines 2>/dev/null && pwd` \
  OPENSSL_DEBUG_MEMORY=on \
/opt/perl-5.26.1/bin/perl .././test/run_tests.pl  )
../test/recipes/01-test_abort.t  ok
../test/recipes/01-test_sanity.t ... Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/01-test_symbol_presence.t .. skipped: Only useful when 
building shared libraries
../test/recipes/01-test_test.t . Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/02-test_errstr.t ... Dubious, test returned 60 
(wstat 15360, 0x3c00)
Failed 60/76 subtests
(less 16 skipped subtests: 0 okay)
../test/recipes/02-test_internal_ctype.t ... Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/02-test_lhash.t  Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/02-test_ordinals.t . ok
../test/recipes/02-test_stack.t  Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/03-test_exdata.t ... Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/03-test_internal_asn1.t  Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/03-test_internal_chacha.t .. Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/03-test_internal_curve448.t  Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/03-test_internal_ec.t .. Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/03-test_internal_mdc2.t  Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/03-test_internal_modes.t ... Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/03-test_internal_poly1305.t  Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/03-test_internal_siphash.t . Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/03-test_internal_sm2.t . Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/03-test_internal_sm4.t . Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/03-test_internal_ssl_cert_table.t .. Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/03-test_internal_x509.t  Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/03-test_ui.t ... Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/04-test_asn1_decode.t .. Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/04-test_asn1_encode.t .. Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/04-test_asn1_string_table.t  Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/04-test_bio_callback.t . Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/1 subtests

Regards,
John.

configuring callbacks (or not) and SNI vs not... no shared cipher from server end

[Michael Richardson]

Diversionary issue:
 https://www.openssl.org/docs/manmaster/man3/SSL_set_tlsext_host_name.html
and: 
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_client_hello_cb.html

are pretty vague.  I think that SSL_set_tlsext_host_name() is probably
intended to be used on the client to set the SNI, but I'm not sure.
The legacy cb function returns int, but it's values are not documented.
The newer cb function is better documented, but I'm a bit at a loss as to
what SSL_client_hello_get0_ext() extracts.  Is the CB expected to parse the
extensions itself?

I guess the point is that CB can set the server certificate to something
appropriate, or I think, it could just decide to ignore the SNI value
completely and force the certificate regardless.

What is the SNI functionality otherwise on the server?
Is there any support for picking a certificate based upon the SNI name?

EXEC SUMMARY


I am asking because I seem to have run into a situation where it does not
seem to do the right thing, but I'm not sure that the error that I'm getting
is really about selecting the right certificate, or if there is something
else going on.  Well, I'm pretty sure that the "no shared cipher" (on server)
is wrong.  This comes out stderr upon receipt/processing of ClientHello.

Things I have tried (described below):
1) making sure that I'm running 1.1.1, which has ECDSA support, and not
   getting 1.0 shared object by mistake (this has happened before)
2) making sure that the SubjectName contains the target SNI.
   (with working certificate, it does not matter to server if I use wrong name)
3) observed private key was in different (SEC1 vs PKCS8) format, tried
   switching that.

Many details at: http://www.sandelman.ca/tmp/certprob201905/


A longer story
--

In testing of a rails-based HTTPS server I have typically just configured a
keypair without a lot of thought to the DN used for the server.  As I have
some (experimental) patches to openssl and ruby-openssl, I often struggle
with having the wrong shared object pulled in and then some things do not
work.  In particular, I would get a message about no shared cipher on the
server emitted when something linked in openssl 1.0.x rather than 1.1.x,
and I had configured an ECDSA keypair.  I'm not sure if it was precisely:

   140639813764864:error:1417A0C1:SSL routines:tls_post_process_client_hello:no
shared cipher:ssl/statem/statem_srvr.c:2131:

(1) which I'm now getting, but it was close to that. I seem to recall that the
file name mentioned was one that was in 1.0.x, but not in 1.1.x, which was
the clue that I had made a linking error.  I got this again yesterday while
testing, and wondered if I could excise 1.0.x completely from my laptop, and
finally found that it was only an old version of libpq5 that linked against
it, and an upgrade (via postgresql.org debian package) eliminated my ruby
process from ever linking 1.0.x.

Yet the error persisted.  I test with the hostname target of
"fountain-test.example.com", which I put into my /etc/hosts as ::2
(an alias on lo), and bind against.

The private keys are test keys, and I could share them if that was useful.

NOTE that both working and failing certificates are generated by ruby code.

(2) I went back to a known working situation where a locally generated
certificate with that name as the CN was present:
(file: http://www.sandelman.ca/tmp/certprob201905/working-cert.txt and .pem)

   Issuer: DC = ca, DC = sandelman, CN = fountain-test.example.com\0A
   Unstrung Fountain Root CA
   Validity
Not Before: May  7 22:56:23 2019 GMT
Not After : Jun  7 08:56:23 2019 GMT
   Subject: DC = ca, DC = sandelman, CN = fountain-test.example.com

And this one works regardless of what name I use to access it.  That is,
given:
::2 fountain-test.sandelman.ca fountain-test.example.com 
n3CE618.router.securehomegateway.ca

all three of:
%curl -k https://fountain-test.sandelman.ca:8443/version.json
{"version":"0.7","revision":"devel"}%
%curl -k https://n3CE618.router.securehomegateway.ca:8443/version.json
{"version":"0.7","revision":"devel"}%
%curl -k https://fountain-test.example.com:8443/version.json
{"version":"0.7","revision":"devel"}%

work.  Using what I think is a similar certificate:

/corp/projects/shg/shg_mud_supervisor/spec/files/product/Smarkaklink-n3ce618/jrc_prime256v1.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 840664151 (0x321b8457)
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = 
highway-test.example.com CA
Validity
Not Before: May  8 17:18:37 2019 GMT
Not After : Dec 31 00:00:00 2999 GMT
Subject: CN = n3CE618.router.securehomegateway.ca
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
  

Re: EVP_aes_128_cbc_hmac_sha256() not working on arm64 architecture

[Mirko J. Ploch]

Thank you Matt. You have been very helpful.

On Tue, May 7, 2019 at 6:40 PM Matt Caswell  wrote:

>
>
> On 07/05/2019 20:47, Mirko J. Ploch wrote:
> > Thank you for your response. You answered my question. It is not
> available on my
> > target platform architecture (arm64).
> >
> > I do have a specific need for that cipher, and it does not have anything
> to do
> > with TLS. An app that I am working on requires it for JSON Web
> Encryption (JWE)
> > as the required encryption algorithm.
> >
> >
> https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-31#appendix-B
>
> Then (in spite of the name) this is not the cipher you want to use. This
> cipher
> can *only* do the AAD specified for TLS - it is not a general purpose
> cipher and
> so will not be capable of doing the AAD specified in that draft.
>
> You can probably achieve what you want using EVP_aes_128_cbc() and then
> using
> HMAC-SHA256 separately.
>
> Matt
>
> >
> > Best Regards,
> > Mirko
> >
> > On Tue, May 7, 2019 at 11:45 AM Matt Caswell  > > wrote:
> >
> >
> >
> > On 06/05/2019 16:41, Mirko J. Ploch wrote:
> > > Hello,
> > >
> > > I'm trying to use EVP_aes_128_cbc_hmac_sha256() for encryption on
> an iOS
> > device
> > > with arm64 architecture. I was able to get it working with the
> x86_64
> > > architecture when running the iOS device simulator on an iMac. Is
> this
> > just not
> > > capable of working on an arm64 platform?
> > >
> > > Looking at the code for EVP_aes_128_cbc_hmac_sha256, it does not
> look like it.
> > > I'm hoping that there is a way to get it working.
> > >
> >
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1b/crypto/evp/e_aes_cbc_hmac_sha256.c
> >
> > This cipher is a special purpose cipher not intended for general
> use. It is
> > specifically targeted at usage in TLS. Unless you're writing a TLS
> stack you
> > probably don't want to use this. It is only available on some
> platforms and does
> > runtime detection to check whether the platform is suitable or not.
> Most
> > importantly the platform must have AES-NI support.
> >
> > It's usefulness even in a TLS stack is somewhat limited these days
> since it is
> > not relevant for TLSv1.3 and does not get used if encrypt-then-mac
> is negotiated
> > (which recent versions of OpenSSL will try to negotiate by default).
> >
> > Matt
> >
>