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

Solution 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.

Solution 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

Comments

[Etan Reisner]

I believe that novell documentation is decidedly incorrect about including the key in the file being used as the cert (in this situation). Some servers use split cert and key file locations and some use a combined file. postfix seems to use the split form so combining the key and the cert is just likely to cause you to accidentally leak your key (when you forget it is in the concatenated pem file).

[peris]

Thanks for the quick reply Etan, how should i proceed to pull out the root certificate? Do you mean i should just use sf_bundle.crt?

[Etan Reisner]

If you look in sf_bundle.crt you should see two certificate blocks (possibly with plain text certificate information "headers"). If you copy the block that represents the root certificate into its own file you can use if with -CAfile as I said and that should make the error go away. If you can't tell which block is which then split them both out and then you can use openssl x509 -text -noout -in <file> | less to find out which file is which.

[peris]

Thanks a lot for your patience and explanations, which i'm reading carefully but i don't seem to understand. Right now Postfix is configured like this:smtpd_tls_cert_file=/etc/ssl/certs/domain.crt smtpd_tls_key_file=/etc/ssl/private/domain.key The key file was generated by me and the crt is the one provided by Godaddy, if i split sf_bundle into two files and use any oen of them - no matter which one as i've tried both - i get the following error write:errno=104 --- no peer certificate available

[Etan Reisner]

I didn't suggest using that in place of domain.crt in the postfix config. I suggested using the split out piece in the openssl command you were using to test your postfix configuration.

[peris]

Etan, but first sten shouldn't be to get Postfix configuration pointing the right files? Right now, which file should point smtpd_tls_cert_file statement? Thanks,

[Etan Reisner]

Your original file selection was correct.

[peris]

Hi Ethan, thanks a lot for your detailed explanation and please excuse me for the delayed response. After following your steps i could connect to imap.domain.ltd:465 using block2.crt withouth recieving any errors/warnings but if i configure postfix to use block2.crt as certificate then i recieve the following error when trying to connect: CONNECTED(00000003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent

[Etan Reisner]

You shouldn't be configuring postfix to use block2.crt. You don't have the private key for that cert (nor should you as that is the Starfield root certificate). You configure postfix to use domain.crt (and domain.key) for itself and to use block1.crt (or sf_bundle.crt) as the intermediate/chain certificates.