Opened 6 years ago

Closed 3 years ago

Last modified 14 months ago

#667 closed Bug / Defect (fixed)

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

Reported by: ValdikSS Owned by:
Priority: minor Milestone:
Component: Generic / unclassified Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: openssl
Cc: Steffan Karger


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

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)

Change History (11)

comment:1 Changed 6 years ago by 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.

comment:2 Changed 6 years ago by Gert Döring

Cc: Steffan Karger added

comment:3 Changed 3 years ago by jennifersharpe

--Deleted SPAM--

Last edited 3 years ago by Eric Crist (previous) (diff)

comment:4 Changed 3 years ago by 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.

comment:5 Changed 3 years ago by sarataylor


Last edited 3 years ago by plaisthos (previous) (diff)

comment:6 Changed 3 years ago by sweetzzz


Last edited 3 years ago by plaisthos (previous) (diff)

comment:7 Changed 3 years ago by 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], 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.

comment:8 Changed 3 years ago by plaisthos

Resolution: fixed
Status: newclosed

comment:9 Changed 3 years ago by emilywilliamson349

Technology now more advanced and nowadays you created your own public-private key which you use anytime anywhere. If you are using a Private key then it's very hard anyone can encode your information. If you see the public portion, which forms of a Credential Signing Request willpower, at for private documentation admission.

Version 0, edited 3 years ago by emilywilliamson349 (next)

comment:10 Changed 17 months ago by edharvey

Last edited 17 months ago by Antonio Quartulli (previous) (diff)

comment:11 Changed 14 months ago by nicoleallen

lame spam

Last edited 14 months ago by Gert Döring (previous) (diff)
Note: See TracTickets for help on using tickets.