X509 certificates and password length

Using Kleopatra to make a new key pair under X509, I keep running into an error message ‘password is too long’. I was making a password using the KeyPass profile I currently use for Gpg key pairs. I have to shorten it considerably to get it past Kleopatra when making an X509 certificate request.

Is this correct ? Does anybody know why X509 will only take short passwords ?

Only thing I could dig up is something about Windows XP and server 2003 only using 32-character passwords. Here’s a quote:

“On Windows XP or Windows Server 2003, any characters greater or equal to 32 characters are ignored. Windows Server 2008 has no password limit so the code succeeds on that OS. On Windows Server 2003 the code fails to load the PFX because the password is more than 31 characters in length. You might have to shorten the password to make it compatible on Windows Server 2003.”
-bill boyce

…and a link to the forum I found it in:


Maybe this is a legacy issue?

Sean C.

I tried at least five times today to import an X509 key in ‘mykey.p12’ into Gpg4win using Kleopatra. Each time the process seemed to complete without any error message but the final result was always a dialog saying that 1 key failed to import.

Then I thought about the passphrase length. The passphrase I was trying to use and which was apparently accepted twice each attempt with no error message, was only 20 characters long. I have passphrases of this length for other 509 certificates already in Kleopatra.

The last time, I was successful using a passphrase only 12 chars long. The import succeeded.

I then used Kleopatra to change the passphrase to what I wanted, 20 chars. I was invited first to enter the old passphrase so I entered the 12 character phrase used during import. This was rejected as incorrect. So I entered the 20 char phrase originally used to protect the .p12 file on the computer and this was accepted. I then entered it again twice to complete the passphrase change.

What then is the point of defining a new passphrase at import when the act of importing also imports the passphrase used to protect the file in the original directory ? Sounds a bit like a bug ?