OpenVPN's OpenSSL backend does not support certificate chain pushed from server

[ValdikSS]

OpenVPN compiled with OpenSSL can't validate server certificate if it's signed by the intermediate CA, which is pushed from server.

Example:
We have the following PKI structure:

CA ⇒ Intermediate ⇒ Server certificate
CA ⇒ Client certificate

Server is configured like this:

ca ca.crt
cert (server certificate + intermediate certificate)
key server.key

Client is configured as follows:

ca ca.crt
cert client.crt
key client.key

Server pushes both server and intermediate certificates (certificate chain), and the client should successfully validate it, which is true for PolarSSL, but not OpenSSL backend.
It seems that OpenSSL backend can only handle one certificate pushed from server.

Works fine with:

• OpenVPN 2.3.10 and git master with PolarSSL backend
• OpenVPN Connect for Android (built with PolarSSL)

Doesn't work:

• OpenVPN 2.3.10 and git master with OpenSSL backend
• OpenVPN for Android (Arne's)

[ValdikSS]

I've checked OpenSSL backend and unfortunately my knowledge is not enough to fix this.
From what I understand, OpenVPN writes TLS handshake (and all other TLS data before establishing data channel) directly to OpenVPN using BIOs, and for some reason OpenSSL doesn't get second certificate. Validation callback function verify_callback gets preverify_ok = 0 and there's nothing we can do inside the callback.

[jennifersharpe]

--Deleted SPAM--

[Selva Nair]

@ValdikSS, is this report still valid? I recall using an intermediate ca without error.

Looking at the sources don't see why this should not work either -- extra certs in the cert file are loaded into the context using SSL_CTX_add_extra_chain_cert() in ssl_openssl.c, so should get presented to the client in the "Certificate message".

Just did a test with a new server cert, and quoting from client log:

Tue Feb 5 21:35:17 2019 VERIFY OK: depth=2, C=CA, ST=ON, L=Toronto, O=Foo, OU=xx, CN=Foo CA, emailAddress=selva@...
Tue Feb 5 21:35:17 2019 VERIFY OK: depth=1, C=CA, ST=Ontario, O=Foo, OU=xx, CN=Foo Intermediate CA, emailAddress=selva@...
Tue Feb 5 21:35:17 2019 VERIFY OK: nsCertType=SERVER
Tue Feb 5 21:35:17 2019 VERIFY OK: depth=0, C=CA, ST=Ontario, O=Foo, OU=xx, CN=foo-vpn, emailAddress=selva@...

Here the server and clients are configured as in your example.

The above log is using a build based on git:master/253f015558d3ce3c -- i.e., a few months old, but that's unlikely to matter as the relevant code has not changed for a while, I think.

[sarataylor]

spam

[sweetzzz]

spam

[ValdikSS]

@selvanair, seems to work fine now, at least with:

OpenVPN 2.4.7 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 20 2019
library versions: OpenSSL 1.1.1c FIPS  28 May 2019, LZO 2.08

TLS: Initial packet from [AF_INET]127.0.0.1:1194, sid=06fafdf1 1251e258
VERIFY OK: depth=2, CN=OpenVPN Test RootCA
VERIFY OK: depth=1, CN=OpenVPN Test SubCA
VERIFY OK: depth=0, CN=server-of-subca
Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA

Let's assume this bug is fixed.

[emilywilliamson349]

lame spam

[nicoleallen]

lame spam