Opened 13 months ago

Last modified 12 months ago

#764 assigned Bug / Defect

--management-external-key sometimes requests signatures for too long data

Reported by: jarit Owned by: mattock
Priority: major Milestone: release 2.3.15
Component: Generic / unclassified Version: OpenVPN 2.3.12 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: syzzer


According to, the ">RSA_SIGN" notification should be responded with "rsa-sig" command where the signature should be a "Base64 encoded output of RSA_sign(NID_md5_sha1,... ".

The normal case is that OpenVPN requests signatures for 36 bytes of data, but with some clients we see a notification requesting a signature for 83 bytes:


OpenSSL RSA_sign with NID_md5_sha1 expects that the data is exactly 36 bytes and will refuse to sign this and gives an error about invalid message length:

Either the documentation is wrong and the signature should be generated in another way or the request for signing 83 bytes is a bug.

This seems to happen only with certain clients/versions (Android) and is reproducible always with those.

OpenSSL version is 1.0.2d and OpenVPN version:

OpenVPN 2.3.12 arm-poky-linux-gnueabi [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Nov  9 2016
library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <>
Compile time defines: enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_http_proxy=yes enable_iproute2=no enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=no enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_win32_dll=yes enable_x509_alt_username=no with_crypto_library=openssl with_gnu_ld=yes with_lzo_headers=/include with_lzo_lib=/lib with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_ssl_headers=/include with_ssl_lib=/lib with_sysroot=no

Change History (8)

comment:1 Changed 13 months ago by cron2

  • Cc syzzer added
  • Milestone set to release 2.3.15

@syzzer: any idea?

comment:2 Changed 13 months ago by syzzer

  • Owner set to syzzer
  • Status changed from new to accepted

The documentation is wrong (or actually, not up to date). What is happening is that you client and server negotiate TLS 1.2, which no longer restricts transcript digests to SHA1_MD5. Instead a stronger digest like SHA256 or SHA384 is likely negotiated.

I'll put this on my list, but can't make promises on the timeline. So, if anyone else want to take a stab at it: patches are welcome.

comment:3 Changed 13 months ago by syzzer

BTW, if your management software can't deal with this, you can (temporarily, please) disable TLS 1.2 until you've updated the software, by setting tls-version-max 1.1 in the openvpn config (either server or client).

comment:4 Changed 13 months ago by jarit

Thanks for the prompt response. As a workaround, could you then briefly instruct on what is the correct way to generate the signature in case of TLS 1.2 ?

comment:5 Changed 13 months ago by jarit

And also, if TLS 1.2 allows multiple different digests, how should the management software know what kind of signature to generate? Based on the data length?

comment:6 Changed 13 months ago by syzzer

The management software is expected to simple create a PKCS#1 1.5 signatures, as described here: (In most crypto libraries this is known as a 'raw rsa signature'.) See for a little extra context.

The OpenVPN software already calculates the correct digest, and does all the proper formatting of metadata. All the management software has to do is create the PKCS#1 signature. (I.e. you don't need to know anything about the used digest.)

Last edited 13 months ago by syzzer (previous) (diff)

comment:7 Changed 13 months ago by jarit

Thanks. That makes it clear and simple. OpenSSL method RSA_private_encrypt() with RSA_PKCS1_PADDING seems to do the job.

comment:8 Changed 12 months ago by syzzer

  • Owner changed from syzzer to mattock
  • Status changed from accepted to assigned

I just sent a patch to the list to update the documentation:

Samuli, can you look into updating the web page once this patch has been applied?

Last edited 12 months ago by syzzer (previous) (diff)
Note: See TracTickets for help on using tickets.