SSL Error: self signed certificate in certificate chain

Question

EDIT: AS the following documents describes http://www.novell.com/support/kb/doc.php?id=7002392 i've concatenated those files like this domain.crt sf_bundle.crt >> domain.pem and now the following command openssl s_client -connect domain:465 complains about verify error:num=19:self signed certificate in certificate chain I Hope someone can help to geo out a clue :D

i've just configured our mta through postfix which offers IMAP and SMTP through TLS. During testing i created a self signed certificate but now, to avoid the annoying untrusted certificate warning i bought a cheap certificate at Godaddy; http://www.godaddy.com/compare/gdcompare3_ssl.aspx

The issue here is i'm doing something wrong, probably when installing the Godaddy downloaded certificate, so i'm still seing the warning.

Following is the process i've run into:

openssl genrsa -des3 -out domain.key 1024
openssl req -new -key domain.key -out domain.csr

Went to Godaddy, paste the content of the csr file including being and ending tags. At that point i was able to download the generated certificate, which was a zip file, so now i have the following files:

sf_bundle.crt ;Chain file, on't know how should be used
domain.crt ;Provided along with sf_bundle by Godaddy
domain.csr ;Genrated by me
domain.key ;Genrated by me

I'm not sure how i should proceed but i did the following:

cat domain.crt sf_bundle.crt >> /etc/ssl/certs/domain.pem
ln -sf /path/to/domain.key /etc/ssl/private/domain.key  

But when testing i get the following issue:

    openssl s_client -connect imap.domain.ltd:465
CONNECTED(00000003)
depth=2 C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=webeloping.es
   i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certificates.starfieldtech.com/repository/CN=Starfield Secure Certification Authority/serialNumber=10688435
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certificates.starfieldtech.com/repository/CN=Starfield Secure Certification Authority/serialNumber=10688435
   i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
 2 s:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
   i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFcjCCBFqgAwIBAgIHKx6Jb01O+jANBgkqhkiG9w0BAQUFADCB3DELMAkGA1UE
BhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAj
BgNVBAoTHFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xOTA3BgNVBAsTMGh0
dHA6Ly9jZXJ0aWZpY2F0ZXMuc3RhcmZpZWxkdGVjaC5jb20vcmVwb3NpdG9yeTEx
MC8GA1UEAxMoU3RhcmZpZWxkIFNlY3VyZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTERMA8GA1UEBRMIMTA2ODg0MzUwHhcNMTMwNzEyMDc1NTA0WhcNMTQwNzExMTcz
MTAyWjA7MSEwHwYDVQQLExhEb21haW4gQ29udHJvbCBWYWxpZGF0ZWQxFjAUBgNV
BAMTDXdlYmVsb3BpbmcuZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDTAHQM3SanFxSZWnxls837ySCHB/CfBJXIBoKQdYOf/N3lGt69jnNHF8X2ZmSI
TeW5Xk/wXnjruKD/EhBvAxiYZVWcp5zJGxd6VNqntiFCVTSesSnwM/X6A54vq/57
UnvrqK7ZozWnINiO/LIWxdVCUwcOmXH+fp6mVUsCbNd8Gp1HpMorhzpvBj1E/5I4
HbZjErGfrLlCYhs2cATtTcBtiUxne3CKOsT/sWd3Z2DAKsJQqd5u3Y59EEfiJmDq
xtoCkfYAhZz5FkA9mr2PQD+UKGLOGjvRDI7P8p5RR9ZG7jixdok5qq0OikCPwex4
hatfWEokBjmWcmr8QcUk1cQjAgMBAAGjggHXMIIB0zAPBgNVHRMBAf8EBTADAQEA
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAOBgNVHQ8BAf8EBAMCBaAw
OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5zdGFyZmllbGR0ZWNoLmNvbS9z
ZnMxLTI1LmNybDBZBgNVHSAEUjBQME4GC2CGSAGG/W4BBxcBMD8wPQYIKwYBBQUH
AgEWMWh0dHA6Ly9jZXJ0aWZpY2F0ZXMuc3RhcmZpZWxkdGVjaC5jb20vcmVwb3Np
dG9yeS8wgY0GCCsGAQUFBwEBBIGAMH4wKgYIKwYBBQUHMAGGHmh0dHA6Ly9vY3Nw
LnN0YXJmaWVsZHRlY2guY29tLzBQBggrBgEFBQcwAoZEaHR0cDovL2NlcnRpZmlj
YXRlcy5zdGFyZmllbGR0ZWNoLmNvbS9yZXBvc2l0b3J5L3NmX2ludGVybWVkaWF0
ZS5jcnQwHwYDVR0jBBgwFoAUSUtSJ9EbvPKhIWpie1FCeorX1VYwKwYDVR0RBCQw
IoINd2ViZWxvcGluZy5lc4IRd3d3LndlYmVsb3BpbmcuZXMwHQYDVR0OBBYEFJp4
5TYP4T3BfuI67Ek2vxtUNiVCMA0GCSqGSIb3DQEBBQUAA4IBAQBjXFPi/3e3GJ+J
Pj7Rafieee4Tqcc5QbwKvrFEdK3OW9/XjntchNOsKumKFJeiK8bsUbSTS+wlpyKG
+qHwrf8d1TtZgKiyJTBHcKxItqSrGsULM5ntTFq/gchOkE0hwK4vfwHZD9bHyy20
CqexuaTT3zpAL3zZi5q2QaOpqQxhPmlkIZvmNotw+a/E+3hmOFKpQtVfT7XeAcQr
bIUMZUEbs778VzjnKdg4grD7oZxwPczbaeJLhdvKs8OEJSbqX/820hLQfoX+wMCI
PNI1jPU3th1cu9nPKU41BXIDY1L6w9zCl2DRvQvjFx9YnjQ/R6YiyaCCh39WS+xg
+An9srwv
-----END CERTIFICATE-----

Related configuration in postfix looks like this:

    ## /etc/postfix/main.cf
    ##Provided by Godaddy along with sf_bundle.crt
    smtpd_tls_cert_file=/etc/ssl/certs/domain.crt
    ##Generated by me
    smtpd_tls_key_file=/etc/ssl/private/domain.key
    smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt

Answer 1

You don't need the root certificate in the chain (though I don't believe having it hurts anything).

That error is more of a warning from openssl in this case I think. I believe what it means is just that openssl doesn't know that it should trust the root certificate of that chain. If you pull out just the root certificate from that bundle and point that openssl command at it with the -CAfile argument I expect that "error" should go away.

Inside the sf_bundle.crt file you should see two

-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----

blocks (possibly with plain text above each block showing what certificate the block contains). If you split each of those blocks into its own file so you end up with block1.crt and block2.crt you should be able to run openssl x509 -noout -subject -in <file.crt> on each of them to get their respective certificate subject lines.

Assuming that block2.crt has a subject line of /C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority you should then be able to run openssl s_client -CAfile block2.crt -connect imap.domain.ltd:465 and that should, hopefully, connect without giving you the self-signed certificate error.

Answer 2

If you really did

domain.key domain.crt sf_bundle.crt >> domain.pem

then you included your private key in the chain, which you should not.

Only your server's certificate plus the chain of intermediary certificates are needed, so that the client can match the issuer of the top of them to a trusted root certificate he possesses