I recently renewed my email certificate and discovered that I cannot import it in my email client. I had no problem doing so with last year’s certificate, or with another SSL certificate from CACert.org
Has something changed in the structure of the certificate bundle that caused this fault? Every time it fails to accept a passphrase to secure the pkcs12 file in the certificate manager. If I convert the pkcs12 into a pem key & certificate bundle it fails with a BER error. This is what the log shows when I try to import the pem file:
These “invalid radix64 character” errors shown above indicate that there are some characters in the certificate that the gnupg manager barfs over. Any idea what these are and if there is something I can do using openssl to fix this?
There seems to be no problem using the CLI to read either the pkcs12 or the pem files.
I have to be more detailed in how the failure occurs:
I back up the certificate from Firefox as a pkcs12 file. No problem there.
Then importing it into Kleopatra will only work if I have used a short passphrase to encrypt it. It imports fine if at the time of exporting it from FF I have used a short passphrase (say 8 alphanumeric characters). Once imported into Kleopatra the length of the passphrase is no longer important, as it fails every time I try to used it.
When I try to sign or encrypt a message in Kmail with the new certificate the passphrase will not work:
[2010-05-12T19:51:45] Log cleared
6 - 2010-05-12 19:52:12 gpg-agent[13563]: failed to unprotect the secret key: Bad passphrase
6 - 2010-05-12 19:52:12 gpg-agent[13563]: failed to read the secret key
6 - 2010-05-12 19:52:12 gpg-agent[13563]: command pksign failed: Bad passphrase
6 - 2010-05-12 19:52:12 gpg-agent[13563.6] DBG: -> ERR 67108875 Bad passphrase <GPG Agent>
4 - 2010-05-12 19:52:12 gpgsm[16759]: error creating signature: Bad passphrase <GPG Agent>
4 - 2010-05-12 19:52:12 gpgsm[16759.0] DBG: -> ERR 67108875 Bad passphrase <GPG Agent>
4 - 2010-05-12 19:52:12 gpgsm[16759.0] DBG: <- BYE
4 - 2010-05-12 19:52:12 gpgsm[16759.0] DBG: -> OK closing connection
[client at fd 4 disconnected]
5 - 2010-05-12 19:52:12 dirmngr[16760.0] DBG: <- [EOF]
6 - 2010-05-12 19:52:12 gpg-agent[13563.6] DBG: <- [EOF]
6 - 2010-05-12 19:52:12 gpg-agent[13563]: handler 0xbf04c0 for fd 6 terminated
[client at fd 5 disconnected]
Converting the pkcs12 file with openssl into pem format and then trying to import that into Kleopatra fails with the error I have shown in the previous message. I have the same version of Kleopatra like you, but with one version up on Qt:
$ kleopatra --version
Statup timing: 20 ms elapsed: Command line args created
Qt: 4.6.2
KDE: 4.3.5 (KDE 4.3.5)
Kleopatra: 2.0.9
Not sure if this is a pinentry error …
Can you use it to sign messages? Can you in any way unencrypt it (e.g. to change the passphrase) after Kleopatra has accepted it for import? This is rather debilitating and if my webmail did not have the ability to use S/MIME certs I would be in trouble!
I’m now on KDE-4.4.5 and still have the same problem. Could it be that my desktop is using UTF8 character set and the Comodo certificate won’t play nicely with it - is there such a possibility?
At long last! I found what is wrong with my system!
It seems that gnupg-2.0.14 onwards contains a regression bug which affects gpg-agent. The certificate works fine as long as the passphrase is not changed at all. The solution is to export the certificate from the browser and use the same passphrase all the way through when importing it in the certificate store.
I was successful in importing it with ‘gpgsm --import’ and using the same passphrase as used during export, after I deleted the private key:
