[gentoo-user] Re: S/MIME passphrase problem with Kleopatra

[Mick]

On Thursday 13 May 2010 11:08:48 you wrote:
> In the last two weeks I renewed an SSL certificate from Comodo for
> email usage.  This time round Kleopatra is having problems with
> recognising the passphrase I use.
>
> I partially suspect a gnupg bug here probably relating to mime
> characters, but I am not sure how to troubleshoot it.  This is a
> sequence of events that show how the problem occurs:
>
> I export the SSL cert from Firefox as a pkcs12 file.  It asks for a
> passphrase to encrypt it with.  It will accept my passphrase and saves
> the exported .p12 bundle as a file on my hard drive.  Then I try to
> import this into Kleopatra.  This is what I have come across here:
>
> If I have used a short passphrase when exporting from Firefox (say 8
> characters long) there's no problem importing it into Kleopatra.
>  If I use a long passphrase then it fails every time:
>
> "Please enter a passphrase to unprotect the PKCS#12 object."
> p4ssPhr4se
> "An error occurred while trying to import the certificate - Decryption
> failed."
>
> The log shows:
> ======================================
> [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]
> ======================================
>
> Now, as I said above if I use a short passphrase to encrypt the
> certificate bundle when exporting it from Firefox, I manage to import
> it into Kleopatra and then I can re-encrypt it with either with the
> same short passphrase or with a longer passphrase.  Kleopatra will
> accept any length at that stage and import it happily.  However, even
> if I import it into Kleopatra I can't use it thereafter!  Every time I
> try to use it in Kmail to sign/encrypt/decrypt a message it will fail
> when I enter the passphrase.  :-(
>
> I have tried to convert the exported pkcs12 file into a pem bundle,
> but Kleopatra then fails to import it right from the start with a BER
> error - it doesn't even ask for a passphrase to decrypt it:
> ======================================
> [2010-05-07T22:24:22] Log cleared
> [client at fd 4 connected]
>   4 - 2010-05-07 22:24:25 gpgsm[14692]: enabled debug flags: assuan
>   4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> # Home: ~/.gnupg
>   4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> # Config:
> /home/michael/.gnupg/gpgsm.conf
>   4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> # AgentInfo:
> /tmp/gpg-yRFiu9/S.gpg-agent:13728:1
>   4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> # DirmngrInfo: [not set]
>   4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> OK GNU Privacy
> Guard's S/M server 2.0.14 ready
>   4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: <- OPTION display=:0.0
>   4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> OK
>   4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: <- OPTION enable-audit-log=1
>   4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> OK
>   4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: <- INPUT FD=21
>   4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> OK
>   4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: <- IMPORT
>   4 - 2010-05-07 22:24:25 gpgsm[14692]: invalid radix64 character 2d
> skipped 4 - 2010-05-07 22:24:25 gpgsm[14692]: invalid radix64 character 3a
> skipped 4 - 2010-05-07 22:24:25 gpgsm[14692]: invalid radix64 character 2c
> skipped 4 - 2010-05-07 22:24:25 gpgsm[14692]: invalid radix64 character 2d
> skipped 4 - 2010-05-07 22:24:25 gpgsm[14692]: invalid radix64 character 3a
> skipped 4 - 2010-05-07 22:24:25 gpgsm[14692]: invalid radix64 character 2d
> skipped 4 - 2010-05-07 22:24:25 gpgsm[14692]: total number processed: 0
>   4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> S IMPORT_RES 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>   4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> ERR 150995078 BER error
> <KSBA> 4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: <- BYE
>   4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> OK closing connection
> [client at fd 4 disconnected]
> ======================================
>
> Any idea why Kleopatra fails with this new Comodo certificate?  It
> had/has no problem using the expired certificate by the same CA (of
> course it is shown as expired now).  How could I troubleshoot this
> thing?
>
> Some things I have tried so far:
>
> I have imported and used this SSL cert on a webmail client (Horde) and
> had no problem with it.
>
> I have also tried the same SSL cert on two different Gentoo PCs (one
> x86 and one amd64) but both fail in the way described above.
>
> Running openssl pkcs12 -in cert_file.p12 seems to work fine and
> displays the priv key and cert bundle on the terminal, without any
> problem, irrespective of the length of passphrase.
>
> I have visually compared the output on the terminal between expired
> and new certificates and cannot see a difference.
>
> Anything else I could try?

I found what's wrong with it - a regression bug in gnupg-2.0.14, which also 
seems to exist in gnupg-2.0.16-r1 that I am running here.

If the passphrase is changed then the bug manifests and there is no way to use 
the certificate again - entering the new passphrase fails.

The solution is to import the new cert using gpgsm --import, stick to the same 
passphrase with which the pkcs12 was secured and things should work 
thereafter, as long as you do not change the passphrase.

See more info here:

http://marc.info/?l=gnupg-users&m=126451730710129&w=2

I've raised bug #336846.
-- 
Regards,
Mick