Opened 8 years ago

Closed 17 months ago

#764 closed Bug / Defect (fixed)

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

Reported by: jarit Owned by: Samuli Seppänen
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: Steffan Karger


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 (9)

comment:1 Changed 8 years ago by Gert Döring

Cc: Steffan Karger added
Milestone: release 2.3.15

@syzzer: any idea?

comment:2 Changed 8 years ago by Steffan Karger

Owner: set to Steffan Karger
Status: newaccepted

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 8 years ago by Steffan Karger

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 8 years 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 8 years 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 8 years ago by Steffan Karger

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 8 years ago by Steffan Karger (previous) (diff)

comment:7 Changed 8 years 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 7 years ago by Steffan Karger

Owner: changed from Steffan Karger to Samuli Seppänen
Status: acceptedassigned

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?

Version 0, edited 7 years ago by Steffan Karger (next)

comment:9 Changed 17 months ago by Gert Döring

Resolution: fixed
Status: assignedclosed

So I think I can close this ticket now? Web page documentation for management-notes has been updated just recently.

Note: See TracTickets for help on using tickets.