Bug#426013: exim4-daemon-heavy Base64 decoding error

[Mark Adams]

Hi Simon, Thanks for the reply.

Apologies for the confusion, I renamed .pem to .key in the middle of the
process for my own clarification. the Certificate file does look like
that, except it is much longer, atleast twice as long. it starts with
the BEGIN line and ends with the END line.

The .key file also begins with the BEGIN RSA PRIVATE KEY and ends with
the right line. 

when I run certtool -k < newserver_co_uk.key the beginning starts with

Public Key Info:
        Public Key Algorithm: RSA

when I run certool -i < newerver_co_uk.crt It begins with the following
output

X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 78712b9b85f057731ea88fb1b9527153
        Issuer: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware
        Validity:
                Not Before: Thu May 10 00:00:00 UTC 2007
                Not After: Sat May  9 23:59:59 UTC 2009
        Subject Public Key Algorithm: RSA

*NOTE* I have removed the Subject: line from this mail.

Best regards,
Mark

On Thu, Feb 28, 2008 at 02:58:36PM +0100, Simon Josefsson wrote:
> Hi!  Looking over the entire bug report, I'm confused by the path names.
> Early in your bug report the files were:
> 
> MAIN_TLS_PRIVATEKEY = /etc/exim4/certificates/newserver_co_uk.pem
> MAIN_TLS_CERTIFICATE = /etc/exim4/certificates/newserver_co_uk.crt
> 
> This means the /etc/exim4/certificates/newserver_co_uk.crt file should
> contain something like:
> 
> -----BEGIN CERTIFICATE-----
> MIICHjCCAYmgAwIBAgIERiYdNzALBgkqhkiG9w0BAQUwGTEXMBUGA1UEAxMOR251
> VExTIHRlc3QgQ0EwHhcNMDcwNDE4MTMyOTI3WhcNMDgwNDE3MTMyOTI3WjAdMRsw
> GQYDVQQDExJHbnVUTFMgdGVzdCBjbGllbnQwgZwwCwYJKoZIhvcNAQEBA4GMADCB
> iAKBgLtmQ/Xyxde2jMzF3/WIO7HJS2oOoa0gUEAIgKFPXKPQ+GzP5jz37AR2ExeL
> ZIkiW8DdU3w77XwEu4C5KL6Om8aOoKUSy/VXHqLnu7czSZ/ju0quak1o/8kR4jKN
> zj2AC41179gAgY8oBAOgIo1hBAf6tjd9IQdJ0glhaZiQo1ipAgMBAAGjdjB0MAwG
> A1UdEwEB/wQCMAAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwDwYDVR0PAQH/BAUDAweg
> ADAdBgNVHQ4EFgQUTLkKm/odNON+3svSBxX+odrLaJEwHwYDVR0jBBgwFoAU6Twc
> +62SbuYGpFYsouHAUyfI8pUwCwYJKoZIhvcNAQEFA4GBALujmBJVZnvaTXr9cFRJ
> jpfc/3X7sLUsMvumcDE01ls/cG5mIatmiyEU9qI3jbgUf82z23ON/acwJf875D3/
> U7jyOsBJ44SEQITbin2yUeJMIm1tievvdNXBDfW95AM507ShzP12sfiJkJfjjdhy
> dc8Siq5JojruiMizAf0pA7in
> -----END CERTIFICATE-----
> 
> and the /etc/exim4/certificates/newserver_co_uk.pem file should contain
> something like:
> 
> -----BEGIN RSA PRIVATE KEY-----
> MIICXAIBAAKBgQC7ZkP18sXXtozMxd/1iDuxyUtqDqGtIFBACIChT1yj0Phsz+Y8
> 9+wEdhMXi2SJIlvA3VN8O+18BLuAuSi+jpvGjqClEsv1Vx6i57u3M0mf47tKrmpN
> aP/JEeIyjc49gAuNde/YAIGPKAQDoCKNYQQH+rY3fSEHSdIJYWmYkKNYqQIDAQAB
> AoGADpmARG5CQxS+AesNkGmpauepiCz1JBF/JwnyiX6vEzUh0Ypd39SZztwrDxvF
> PJjQaKVljml1zkJpIDVsqvHdyVdse8M+Qn6hw4x2p5rogdvhhIL1mdWo7jWeVJTF
> RKB7zLdMPs3ySdtcIQaF9nUAQ2KJEvldkO3m/bRJFEp54k0CQQDYy+RlTmwRD6hy
> 7UtMjR0H3CSZJeQ8svMCxHLmOluG9H1UKk55ZBYfRTsXniqUkJBZ5wuV1L+pR9EK
> ca89a+1VAkEA3UmBelwEv2u9cAU1QjKjmwju1JgXbrjEohK+3B5y0ESEXPAwNQT9
> TrDM1m9AyxYTWLxX93dI5QwNFJtmbtjeBQJARSCWXhsoaDRG8QZrCSjBxfzTCqZD
> ZXtl807ymCipgJm60LiAt0JLr4LiucAsMZz6+j+quQbSakbFCACB8SLV1QJBAKZQ
> YKf+EPNtnmta/rRKKvySsi3GQZZN+Dt3q0r094XgeTsAqrqujVNfPhTMeP4qEVBX
> /iVX2cmMTSh3w3z8MaECQEp0XJWDVKOwcTW6Ajp9SowtmiZ3YDYo1LF9igb4iaLv
> sWZGfbnU3ryjvkb6YuFjgtzbZDZHWQCo8/cOtOBmPdk=
> -----END RSA PRIVATE KEY-----
> 
> Can you confirm that the files, respectively, have the proper headers?
> 
> If the files contain anything else but content like the above, that may
> be the problem.
> 
> I don't understand what the .key file is.  Can you confirm that
> 'certtool -k /etc/exim4/certificates/newserver_co_uk.pem' works?
> 
> It is important to run the tests on the exact same files as the ones
> used by exim.
> 
> Do you still get the exact same exim error message?  Note that if the
> *.crt and *.pem filenames are mixed up, that would explain everything.
> 
> 2007-05-13 22:02:17 TLS error on connection from myhost.net [217.147.xx.xx]
>     (cert/key set up: cert=/etc/exim4/certificates/newserver_co_uk.crt
>      key=/etc/exim4/certificates/newserver_co_uk.pem) : Base64 decoding error.
> 
> /Simon
> 
> Mark Adams <mark at campbell-lange.net> writes:
> 
> > Hi Simon,
> >
> > Apologies for the very late reply.
> >
> > certool works fine on the .crt file, but not on the .key - I get the
> > Base64 decoding error.
> >
> > certtool: Import error: Base64 decoding error.
> >
> > The file appears to be in the correct format.
> >
> > Regards,
> > Mark
> >
> >
> > On Fri, Jan 04, 2008 at 12:22:51PM +0100, Simon Josefsson wrote:
> >> Hi Mark!  I'm trying to help debug this problem.  Could you please post
> >> the output from running:
> >> 
> >> certtool -i < /etc/exim4/certificates/newserver_co_uk.crt
> >> 
> >> Could you also check that
> >> 
> >> certtool -k < /etc/exim4/certificates/newserver_co_uk.pem
> >> 
> >> works?  Don't post the output, as that would compromise your private
> >> key.
> >> 
> >> Do the files contain anything except one certificate and one private key
> >> respectively?
> >> 
> >> The next step would be to install libgnutls-dbg and set a breakpoint on
> >> gnutls_certificate_set_x509_key_file to see where it fails.
> >> 
> >> I'm trying to confirm that the problem only happens inside exim, and not
> >> inside gnutls.  That seems strange, but the discussions in the bug
> >> report earlier suggests this.
> >> 
> >> Fwiw, I believe this problem has nothing to do with a wildcard cert, the
> >> code that fails reads:
> >> 
> >>   DEBUG(D_tls) debug_printf("certificate file = %s\nkey file = %s\n",
> >>     cert_expanded, key_expanded);
> >>   rc = gnutls_certificate_set_x509_key_file(x509_cred, CS cert_expanded,
> >>     CS key_expanded, GNUTLS_X509_FMT_PEM);
> >>   if (rc < 0)
> >>     {
> >>     uschar *msg = string_sprintf("cert/key setup: cert=%s key=%s",
> >>       cert_expanded, key_expanded);
> >>     return tls_error(msg, host, rc);
> >>     }
> >> 
> >> That function does not care whether the certificate is a wildcard one.
> >> 
> >> /Simon