Well that’s the thing. It doesn’t work regardless of whether or not I use the tls-cipher option. So when there is no tls-cipher option in either, it doesn’t work, but when I include it in both config files, and I use TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 (which is what the control channel succesfully uses when employing 1.0.2o on the client side), it still doesn’t work. So I’m a bit confused by this. Is both your client and server using 1.1.0?

something is not right. could you try to remove ecdh-curve parameter from your server config? if it does not change anything what about we try my setup with your keys? you can generate new server and client certs for me - later you can revoke them to maintain your setup security. Or generate all new cert just for this test.

is there any place to clearly list what curves are supported by what software? At the moment it is hit and miss game.

The --show-curves option lists the curves supported by openssl but not necessarily used by ..

I don't have any further information, infact nobody does at this time because I do not believe the developers were aware of this when including EC into openvpn. The openssl library must have some default usage that openvpn has not included options for at this time to manipulate the usage. As it stands, this seems to only effect the client, the server actively uses --ecdh-curve while the client simply ignores it.

So is this occuring because I’m employing BrainpoolP384r1 instead of one of the standard NIST curves?
Does that mean I should change —ecdh-curve to secp384r1? Does it matter if the CA and server and client certs were signed using brainpool?

Does this also mean I don’t need to run the tests dariusz wanted me to? (Thanks for the kind offer to send me some test certs btw)

I switched to 'standard' curve secp384r1 as it was one I was able to make work with all clients (macOS, Windows, iOS and Android). Windows client is now compiled with openssl 1.1 so given the issue described here https://community.openvpn.net/openvpn/ticket/1048 I think the safest bet is to stick to default openssl 1.1 curves - secp256r1, secp521r1, secp384r1 (there is also default x25519 but it cant be used for ECDSA so it is irrelevant). I can confirm that secp256r1 and secp384r1 work. I have never tried secp521r1.

So is this occuring because I’m employing BrainpoolP384r1 instead of one of the standard NIST curves?

Yes.

Ok, I’ll give it a go. Excuse my ignorance though (I’m still quite new to all this) but, just to be clear, is this a bug with openssl 1.1.0, or openvpn? Or a combination of the two? Or is it not even a bug?
I’m just a bit confused. Seems strange that with an “updated” openssl the abilities of openvpn have regressed. As far as I can tell, brainpool is not an unsafe curve (in fact, from what I have read, there is more reason to suspect NIST curves as being potentially purposefully weakened than non-NIST curves). I know you said you weren’t sure what the intended behaviour was, but it would be great if you could point me in the right direction as to where I could find out more on this. Why has brainpool been removed as one of the standard curves in the hello, and can/should this be fixed on the openvpn end? Should I be reporting it to the openssl github?

2. Openvpn know of this problem and will address it when time permits. For now, those are the only curves openvpn can use because there is no way to configure the openvpn client to use any other curve.

In case anyone cares, this is related to the way openvpn, openssl 1.1 and ECC are interacting:
*) Change the ECC default curve list to be this, in order: x25519,
secp256r1, secp521r1, secp384r1.
[Rich Salz]
Somehow openssl defaults to x25519 , and my certificates are using sect571r1, and passing
ecdh-curve to openvpn does not solve it.
I have added a line in src/openvpn/ssl_openssl.c:
SSL_CTX_set1_curves_list(ctx->ctx, "sect571r1");
just under
SSL_CTX_set_default_passwd_cb(ctx->ctx, pem_password_callback);
This seems to have fixed it.

As I understand it the openvpn client compiled with openssl 1.1.0 is not able to set the right curve if it is outside of openssl 1.1.0 default list. So we have to wait for openvpn/openssl dev to find the right way to handle it.