Opened 7 years ago

Last modified 6 years ago

#712 reopened Bug / Defect

connection issue with PKCS#11 support

Reported by: eworm Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version: OpenVPN 2.3.11 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: David Sommerseth


For the Arch Linux OpenVPN package [0] I enabled PKCS#11 support recently [1]. The new package has issues connecting to servers that worked before. The issue has been reported in downstream bug tracker [2]. Note the affected connections do not use PKCS#11 at all, support has just been enabled in the package.


Attachments (1)

0001-Have-the-same-username-password-length-regardless-of.patch (1.3 KB) - added by David Sommerseth 6 years ago.
PATCH] Have the same username/password length regardless of PKCS#11 enablement

Download all attachments as: .zip

Change History (7)

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

Cc: David Sommerseth added

Since this seems to happen *only* with PIA, maybe something on their side is reacting differently to builds with/without --enable-pkcs11?

@dazo, any idea how to tackle this?

comment:2 Changed 7 years ago by David Sommerseth

Resolution: notabug
Status: newclosed

Please open up a support ticket with PIA instead. As this works well with non-PIA servers, it's a strong indication something is happening in the way PIA have configured their servers. And we would need to see server logs to come further. I've looked through comments and log files from, so I fail to see this being an upstream issue.

For now, closing this issue as "notabug". If there are new evidence making this an upstream issue, we can re-open this issue.

comment:3 Changed 6 years ago by eworm

Resolution: notabug
Status: closedreopened

We know the details now. The server is running an OpenVPN instance without PKCS#11 support. Password length is limited to 128 chars (see src/openvpn/misc.h, line 203 and below) there. However PIA accepts to set longer passwords.

A client without PKCS#11 support connects without issues. The password is truncated to 128 chars on both sides.

A client with PKCS#11 support uses longer passwords (up to 4096 chars) and fails to connect. If you manually truncate the password to 128 chars the connection is established successfully.

We have an easy workaround now, but how to handle this in openvpn correctly?

Changed 6 years ago by David Sommerseth

PATCH] Have the same username/password length regardless of PKCS#11 enablement

comment:4 Changed 6 years ago by David Sommerseth

I just sent the attached patch to the mailing list for review (haven't appeared on the ML yet - Message-Id: <1474538677-23301-1-git-send-email-davids@…>)

commit f514b9d2ed9865be191b18d53c466098823208d8
Author: David Sommerseth <>
Date:   Thu Sep 22 12:01:37 2016 +0200

    Have the same username/password length regardless of PKCS#11 enablement
    If running an OpenVPN client with --enable-pkcs11 and a server without
    and having a username and/or password with more than 128 characters,
    the authentication will fail as the server truncates the password
    to 128 bytes.
    This makes things easier and more predictable.  Username/passwords
    can be up to 4096 bytes, regardless of the --enable-pkcs11 state.
    Signed-off-by: David Sommerseth <>

I see I forgot to add the Trac reference to the commit, I'll ensure that happens during the commit if it gets approved.

comment:6 Changed 6 years ago by David Sommerseth

After some discussions on #openvpn-devel, we are not too happy about this approach either. The memory usage due to this change is extended with at least 11.5KB which really isn't needed in most cases. That amount isn't much on a common computer these days, but as OpenVPN is used on embedded systems that amount of additional memory usage can definitely be noticed.

So first question is: How long usernames/passwords do you expect to handle?

Another thing we need to investigate is how this will impact the PKCS#11 implementation if we decrease the 4KB to something a lower value. We want client and server to have equally large buffers, regardless of --enable-pkcs11; to avoid situations like this bug ticket.

Note: See TracTickets for help on using tickets.