Apparently Amazon SES changed their security cert about a week ago. I found out yesterday that ALL of my outgoing mail from my server has been bouncing. I took this opportunity to alter my postfix config so that my mail sends mail via SES using an smtp gateway. HOWEVER, I get a warning that the amazon gateway is not trusted:

Oct  2 20:02:04 ip-10-64-70-28 postfix/pickup[2877]: D330110180: uid=33 from=<www-data>
Oct  2 20:02:04 ip-10-64-70-28 postfix/cleanup[3245]: D330110180: message-id=<20151002200204.D330110180@www.mydomain.com>
Oct  2 20:02:04 ip-10-64-70-28 postfix/qmgr[2878]: D330110180: from=<noreply@myplan.com>, size=1164, nrcpt=1 (queue active)
Oct  2 20:02:04 ip-10-64-70-28 postfix/error[3247]: D330110180: to=<someuser@example.com>, relay=none, delay=0.09, delays=0.05/0.01/0/0.03, dsn=4.7.5, status=deferred (delivery temporarily suspended: Server certificate not trusted)

I see in my postfix main.cf that we use certain settings:

smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = plain
smtp_sasl_password_maps = hash:/etc/postfix/password
smtp_sasl_security_options = noanonymous
#smtp_tls_CApath = /etc/ssl/certs
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_loglevel = 1
smtp_tls_security_level = secure

I'm guessing that for some reason, amazon's cert is not trusted by /etc/ssl/certs/ca-certificates.crt . Does that sound right?

How does one solve this problem? There are bazillions of certs in /etc/ssl/certs.

Why would my server not trust email-smtp.us-east-1.amazonaws.com ?

    I'm not sure if this is helpful but I tried to verify the amazon cert with openssl:

    $ openssl s_client -showcerts -starttls smtp -connect email-smtp.us-east-1.amazonaws.com:587
CONNECTED(00000003)
depth=1 /C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com, Inc./CN=email-smtp.us-east-1.amazonaws.com
   i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
-----BEGIN CERTIFICATE-----
MIIFATCCA+mgAwIBAgIQJMmbV805Lh/ROGQ0D75k9DANBgkqhkiG9w0BAQsFADB+
MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd
BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLzAtBgNVBAMTJlN5bWFudGVj
IENsYXNzIDMgU2VjdXJlIFNlcnZlciBDQSAtIEc0MB4XDTE1MDUyOTAwMDAwMFoX
DTE2MDYxMTIzNTk1OVowfDELMAkGA1UEBhMCVVMxEzARBgNVBAgMCldhc2hpbmd0
b24xEDAOBgNVBAcMB1NlYXR0bGUxGTAXBgNVBAoMEEFtYXpvbi5jb20sIEluYy4x
KzApBgNVBAMMImVtYWlsLXNtdHAudXMtZWFzdC0xLmFtYXpvbmF3cy5jb20wggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDI75hUISWYRukJ6hjTKHUiFzO
QkNogMNlzmpkTFisxS+I+jrzfbkp/a7dDSrQjtowTJ8PFjLea+5ehGBPMlP30ade
9a5hy2sb5QFylPN50ZkTDKS2NTOiktj2HBCmfPIfjEx+Mrl5eGqcnRyF5pViSyVi
PsSmLY6tZAAFSBm9XrvC9iuP1FluMhz1+zUSYU6KDdrMe4qUoYNyLEeYUdGqN5tx
+m5AciYKTJ8jFARAJ89+fXefUiGZfk+1rkEDf+Ny1hJQSdw5jMWso8vlrcJpN+Vl
uLq/LZ2vcEFixl33zronYwlQDdjewaTZA4Esa7m0AOL/jTzBukSj6QYViUUJAgMB
AAGjggF7MIIBdzAtBgNVHREEJjAkgiJlbWFpbC1zbXRwLnVzLWVhc3QtMS5hbWF6
b25hd3MuY29tMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG
CCsGAQUFBwMBBggrBgEFBQcDAjBlBgNVHSAEXjBcMFoGCmCGSAGG+EUBBzYwTDAj
BggrBgEFBQcCARYXaHR0cHM6Ly9kLnN5bWNiLmNvbS9jcHMwJQYIKwYBBQUHAgIw
GRoXaHR0cHM6Ly9kLnN5bWNiLmNvbS9ycGEwHwYDVR0jBBgwFoAUX2DPYZBV34RD
FIpgKrL1evRDGO8wKwYDVR0fBCQwIjAgoB6gHIYaaHR0cDovL3NzLnN5bWNiLmNv
bS9zcy5jcmwwVwYIKwYBBQUHAQEESzBJMB8GCCsGAQUFBzABhhNodHRwOi8vc3Mu
c3ltY2QuY29tMCYGCCsGAQUFBzAChhpodHRwOi8vc3Muc3ltY2IuY29tL3NzLmNy
dDANBgkqhkiG9w0BAQsFAAOCAQEAr0s70iTQEDCkWDS9kB44kppE/YBk785E3mvh
wGQ66KN14hjE5FWD4rUge2H5SDFYBdwqaOficcVlStG5wC7YHTW+45VOckROJAfk
g/dX+lsbE7hbISvhS4TSdbOQq0IpRIXB+mn+TpEvtX039N+E5bDA1DFHOtg9W64U
zHcPLzEVYwxOEP9aTu5gtHeztI884DJ7Gf1orhEURZMrciNJ2XwC/DwnDouZBEUZ
8tDmXTfAB/KzcSeJaC1BjizoMX0R1rFSAIBdjsk/dClaQVUpb/CqNE4E+zpD0I3F
cmcMeeo3TpWIqVcWP4Vzjm1yDAu2ErR9akihVNIGXihCygzRjw==
-----END CERTIFICATE-----
 1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
-----BEGIN CERTIFICATE-----
MIIFODCCBCCgAwIBAgIQUT+5dDhwtzRAQY0wkwaZ/zANBgkqhkiG9w0BAQsFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMTMxMDMxMDAwMDAwWhcNMjMxMDMwMjM1OTU5WjB+MQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV
BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLzAtBgNVBAMTJlN5bWFudGVjIENs
YXNzIDMgU2VjdXJlIFNlcnZlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAstgFyhx0LbUXVjnFSlIJluhL2AzxaJ+aQihiw6UwU35VEYJb
A3oNL+F5BMm0lncZgQGUWfm893qZJ4Itt4PdWid/sgN6nFMl6UgfRk/InSn4vnlW
9vf92Tpo2otLgjNBEsPIPMzWlnqEIRoiBAMnF4scaGGTDw5RgDMdtLXO637QYqzu
s3sBdO9pNevK1T2p7peYyo2qRA4lmUoVlqTObQJUHypqJuIGOmNIrLRM0XWTUP8T
L9ba4cYY9Z/JJV3zADreJk20KQnNDz0jbxZKgRb78oMQw7jW2FUyPfG9D72MUpVK
Fpd6UiFjdS8W+cRmvvW1Cdj/JwDNRHxvSz+w9wIDAQABo4IBYzCCAV8wEgYDVR0T
AQH/BAgwBgEB/wIBADAwBgNVHR8EKTAnMCWgI6Ahhh9odHRwOi8vczEuc3ltY2Iu
Y29tL3BjYTMtZzUuY3JsMA4GA1UdDwEB/wQEAwIBBjAvBggrBgEFBQcBAQQjMCEw
HwYIKwYBBQUHMAGGE2h0dHA6Ly9zMi5zeW1jYi5jb20wawYDVR0gBGQwYjBgBgpg
hkgBhvhFAQc2MFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v
Y3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vcnBhMCkG
A1UdEQQiMCCkHjAcMRowGAYDVQQDExFTeW1hbnRlY1BLSS0xLTUzNDAdBgNVHQ4E
FgQUX2DPYZBV34RDFIpgKrL1evRDGO8wHwYDVR0jBBgwFoAUf9Nlp8Ld7LvwMAnz
Qzn6Aq8zMTMwDQYJKoZIhvcNAQELBQADggEBAF6UVkndji1l9cE2UbYD49qecxny
H1mrWH5sJgUs+oHXXCMXIiw3k/eG7IXmsKP9H+IyqEVv4dn7ua/ScKAyQmW/hP4W
Ko8/xabWo5N9Q+l0IZE1KPRj6S7t9/Vcf0uatSDpCr3gRRAMFJSaXaXjS5HoJJtG
QGX0InLNmfiIEfXzf+YzguaoxX7+0AjiJVgIcWjmzaLmFN5OUiQt/eV5E1PnXi8t
TRttQBVSK/eHiXgSgW7ZTaoteNTCLD0IX4eRnh8OsN4wUmSGiaqdZpwOdgyA8nTY
Kvi4Os7X1g8RvmurFPW9QaAiY4nxug9vKWNmLT+sjHLF+8fk1A/yO0+MKcc=
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=Washington/L=Seattle/O=Amazon.com, Inc./CN=email-smtp.us-east-1.amazonaws.com
issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
---
No client certificate CA names sent
---
SSL handshake has read 3005 bytes and written 482 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 560EE6B9ADBE5B4B2C30C3BBB5E346395E62F35505A2269924A062E3A0AC36BF
    Session-ID-ctx: 
    Master-Key: BCBE7CC4D10820EF4A9B9D695BD13FA6185C063263D8A6728BDAC2183F5647C51B64E49A86251ADE5530136D9148B09B
    Key-Arg   : None
    Start Time: 1443817145
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
250 Ok
421 Timeout waiting for data from client.
closed

      Dunno much about PostFix. Why's this line commented?

      #smtp_tls_CApath = /etc/ssl/certs

      My first thought was that this might make a program not trust ANY other server ... 😕

        dalecosp;11051183 wrote:

        Dunno much about PostFix. Why's this line commented?

        #smtp_tls_CApath = /etc/ssl/certs

        My first thought was that this might make a program not trust ANY other server ... 😕

        Well you'll notice I specified the CAfile exactly. I've also tried it with just a CApath and with both at CApath and CAfile. It's currently set to this:

        smtp_sasl_auth_enable = yes 
smtp_sasl_mechanism_filter = plain 
smtp_sasl_password_maps = hash:/etc/postfix/password 
smtp_sasl_security_options = noanonymous 
# this doesn't seem to work
smtp_tls_CApath = /etc/ssl/certs 
# changed it to this on 2015-10-02 because was having trouble verifying amazon cert
smtp_tls_CAfile = /etc/ssl/certs/VeriSign-Class-3-Public-Primary-Certification-Authority-G5.pem
smtp_tls_loglevel = 1 
smtp_tls_security_level = verify

        Even with security level reduced to "verify" it's still untrusted:

        Oct  2 21:07:49 ip-10-64-70-28 postfix/smtp[6422]: Untrusted TLS connection established to email-smtp.us-east-1.amazonaws.com[54.225.164.33]:587: TLSv1 with cipher AES256-SHA (256/256 bits)
Oct  2 21:07:49 ip-10-64-70-28 postfix/smtp[6422]: C12EB308F3: Server certificate not trusted
Oct  2 21:07:49 ip-10-64-70-28 postfix/smtp[6422]: setting up TLS connection to email-smtp.us-east-1.amazonaws.com[54.243.161.229]:587
Oct  2 21:07:49 ip-10-64-70-28 postfix/smtp[6422]: CA certificate verification failed for email-smtp.us-east-1.amazonaws.com[54.243.161.229]:587: num=7:certificate signature failure
Oct  2 21:07:49 ip-10-64-70-28 postfix/smtp[6422]: Untrusted TLS connection established to email-smtp.us-east-1.amazonaws.com[54.243.161.229]:587: TLSv1 with cipher AES256-SHA (256/256 bits)
Oct  2 21:07:49 ip-10-64-70-28 postfix/smtp[6422]: C12EB308F3: Server certificate not trusted
Oct  2 21:07:49 ip-10-64-70-28 postfix/smtp[6422]: setting up TLS connection to email-smtp.us-east-1.amazonaws.com[54.243.97.84]:587
Oct  2 21:07:49 ip-10-64-70-28 postfix/smtp[6422]: CA certificate verification failed for email-smtp.us-east-1.amazonaws.com[54.243.97.84]:587: num=7:certificate signature failure
Oct  2 21:07:49 ip-10-64-70-28 postfix/smtp[6422]: Untrusted TLS connection established to email-smtp.us-east-1.amazonaws.com[54.243.97.84]:587: TLSv1 with cipher AES256-SHA (256/256 bits)
Oct  2 21:07:49 ip-10-64-70-28 postfix/smtp[6422]: C12EB308F3: to=<someuser@hotmail.com>, relay=email-smtp.us-east-1.amazonaws.com[54.243.97.84]:587, delay=0.37, delays=0.02/0/0.34/0, dsn=4.7.5, status=deferred (Server certificate not trusted)

        I wonder if perhaps the certificate cannot be verified because postfix is old or something? or openssl is old or something?

          sneakyimp;11051185 wrote:

          I wonder if perhaps the certificate cannot be verified because postfix is old or something? or openssl is old or something?

          Good idea to look into that, I think. We had notification recently that someone, possibly our CC processor IIRC, was updating all certs to use SHA2 key signatures, or something like that. Our OpenSSL did have to be upgraded in order to properly decipher those (on a CentOS box ... no such issues with FreeBSD).

          That may have been this issue: https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Authorize-Net-begins-TLS-1-0-Remediation-for-PCI-DSS-compliance/ba-p/51326

          There was also this: https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Authorize-Net-Begins-Infrastructure-and-SHA-2-Certificate/ba-p/49615

            Thanks for chiming in, Dalecosp. This was in fact the problem. The server's running an old version of Ubuntu (10.x LTS) and its old software (not sure if postfix or openssl, but i think the latter) was just unable to verify the cert. Note this is not a problem on Ubuntu 14.x.

              Write a Reply...