[pfx] Re: Postfix thinks smtp.gmail.com uses self-signed certificate
Unleess you can hand over the certificate that Postfix complained about, you have not proven that Postfix was in error. Specifically, yout tests with curl and openssl s_client may have used a different IP address than Postfix, because the smtp.gmail.com IP address changes frequently. The smtp.gmail.com A record has a TTL of 300s, but it changes every few seconds (it not only depends on when you ask, it also depends on where you are). Here is a small sample, asked from an IP address near New York city: Fri Mar 22 04:54:12 PM EDT 2024 172.253.62.109 Fri Mar 22 04:54:13 PM EDT 2024 172.253.62.109 Fri Mar 22 04:54:14 PM EDT 2024 172.253.62.108 Fri Mar 22 04:54:16 PM EDT 2024 172.253.62.109 Fri Mar 22 04:54:17 PM EDT 2024 172.253.62.108 Fri Mar 22 04:54:18 PM EDT 2024 172.253.62.108 Fri Mar 22 04:54:19 PM EDT 2024 172.253.62.108 Fri Mar 22 04:54:20 PM EDT 2024 172.253.62.109 Fri Mar 22 04:54:21 PM EDT 2024 172.253.62.109 Fri Mar 22 04:54:22 PM EDT 2024 172.253.62.108 Fri Mar 22 04:54:23 PM EDT 2024 172.253.62.108 Even if your tests did use the same IP address as Postfix, each connection may be serviced by a different backend behind a load balancer. Even if you connected to the same backend, its configuration may have changed. Like other providers, Google rolls out (SMTP) server updates frequently. It updates a few servers and if the error rate remains small it updates more servers, otherwise it rolls back the change. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix thinks smtp.gmail.com uses self-signed certificate
On Wed, Mar 20, 2024 at 10:25:26PM +0800, Cowbay via Postfix-users wrote: > I'm using debian 10, an old debian distribution. The Postfix version is > 3.4.23. The base 4.0 release is ~5 years old, but not materially different in its core TLS functionality. You'd see the same results with the latest Postfix 3.9.0. > I found below in the log, it says "certificate verification failed for > smtp.gmail.com[64.233.189.109]:465: self-signed certificate" > 8<8<8< > Mar 20 21:27:38 SERVER postfix/qmgr[12913]: DC7D0140531: > from=, size=122883, nrcpt=1 (queue active) > Mar 20 21:27:38 SERVER postfix/smtp[15534]: certificate verification failed > for smtp.gmail.com[64.233.189.109]:465: self-signed certificate > Mar 20 21:27:38 SERVER postfix/smtp[15534]: Untrusted TLS connection > established to smtp.gmail.com[64.233.189.109]:465: TLSv1.3 with cipher > TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature > RSA-PSS (2048 bits) server-digest SHA256 > Mar 20 21:27:38 SERVER postfix/smtp[15534]: DC7D0140531: > to=, relay=smtp.gmail.com[64.233.189.109]:465, delay=2789, > delays=2789/0.08/0.06/0, dsn=4.7.5, status=deferred (Server certificate not > trusted) Perhaps this is a result of not sending SNI? > I have configured sender_dependent_default_transport_maps so the mail sender > @gmail.com would use smtp.gmail:[smtp.gmail.com]:465 > > The smtp.gmail is below > 8<8<8< > smtp.gmail unix - - n - - smtp > -o smtp_generic_maps=regexp:/etc/postfix/smtp_generic_maps > -o smtp_header_checks=pcre:/etc/postfix/smtp_header_checks > -o smtp_helo_name=localhost > -o smtp_tls_wrappermode=yes > -o smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt > 8<8<8< What is the "security level"? You must have something in "smtp_tls_policy_maps" to require TLS for this destination. What is the relevant entry there? What is the main.cf value of "smtp_tls_security_level"? > I believe my transport and sasl configurations are well since the > problem is postfix thinks smtp.gmail.com:465 uses self-signed > certificate. No, the self-signed certificate might have been some root CA that isn't listed in your CAfile. Or perhaps the Gmail load-balancer did present a self-signed certificate for some reason. > Do you have idea to solve this problem? If it isn't reproducible, it is unlikely that much can be determined long after the fact. Please share your TLS policy table entry, and when comparing Postfix against openssl sclient, specify the same IP address as the target host, at most minutes after observing any failure to verify the chain from Postfix. For example: openssl s_client ... -verify_hostname smtp.gmail.com -connect 64.233.189.109:465 You should try with each of "-servername smtp.google.com" and "-noservername" options. On Sat, Mar 23, 2024 at 12:20:40AM +0800, Cowbay via Postfix-users wrote: > Today the problem was vanished. Postfix can connect to smtp.gmail.com:465 > without problem. There are many datacentres in which smtp.gmail.com might be found, and they don't necessarily always present the same certificate (rollouts of new cert chains and software take place earlier in some locations than others). > I found that this time the IP address of smtp.gmail.com becomes > 74.125.23.109 and its certificate is different from last time. There are many more. > This means there exists some cases that Postfix will make a mistake to > detect the certificate as self-signed. No, Postfix correctly reports what it finds. There was no "mistake", don't blame the messenger. > In gmail's case, the mail might eventually be sent as long as the DNS > resolves to certain IP address that has compatible certificate for Postfix. > > Of course it's my bad that use such old Postfix and Debian, sorry. Postfix 3.4 is a bit dated, but there is no reason to expect any issues. When I test with s_client, I see the same certificate chain at that address regardless of whether SNI is used: $ openssl s_client -servername smtp.gmail.com -verify_hostname smtp.gmail.com -connect 64.233.189.109:465 < /dev/null ... Certificate chain 0 s:CN = smtp.gmail.com i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3 a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256 v:NotBefore: Feb 26 08:18:13 2024 GMT; NotAfter: May 20 08:18:12 2024 GMT 1 s:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3 i:C = US, O = Google Trust Services LLC, CN = GTS Root R1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Aug 13 00:00:42 2020 GMT; NotAfter: Sep 30 00:00:42 2027 GMT 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1 i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Jun 19 00:00:42 2020
[pfx] Re: Postfix thinks smtp.gmail.com uses self-signed certificate
On 2024/3/20 22:25, Cowbay via Postfix-users wrote: Below is openssl example: 8<8<8< $ openssl s_client -4 -connect smtp.gmail.com:465 -CAfile /etc/ssl/certs/ca-certificates.crt CONNECTED(0003) depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1 verify return:1 depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3 verify return:1 depth=0 CN = smtp.gmail.com verify return:1 --- Certificate chain 0 s:CN = smtp.gmail.com i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3 1 s:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3 i:C = US, O = Google Trust Services LLC, CN = GTS Root R1 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1 i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA --- Server certificate -BEGIN CERTIFICATE- MIIEhzCCA2+gAwIBAgIQCrASK3egcWgQSjqRjoQ8iDANBgkqhkiG9w0BAQsFADBG MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM QzETMBEGA1UEAxMKR1RTIENBIDFDMzAeFw0yNDAyMTkwODE4MTVaFw0yNDA1MTMw ODE4MTRaMBkxFzAVBgNVBAMTDnNtdHAuZ21haWwuY29tMFkwEwYHKoZIzj0CAQYI KoZIzj0DAQcDQgAEzMkkeWMHpTkBU1wI2rgLq8jtzauypsQYFrc52brXD+yH50u3 0cVzi6ejSjhGni0d7fWxo+A4R91kOrCSsYDwYqOCAmcwggJjMA4GA1UdDwEB/wQE AwIHgDATBgNVHSUEDDAKBggrBgEFBQcDATAMBgNVHRMBAf8EAjAAMB0GA1UdDgQW BBRaOURu5t91CGymCb0ym2q68LcxVzAfBgNVHSMEGDAWgBSKdH+vhc3ulc09nNDi RhTzcTUdJzBqBggrBgEFBQcBAQReMFwwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3Nw LnBraS5nb29nL2d0czFjMzAxBggrBgEFBQcwAoYlaHR0cDovL3BraS5nb29nL3Jl cG8vY2VydHMvZ3RzMWMzLmRlcjAZBgNVHREEEjAQgg5zbXRwLmdtYWlsLmNvbTAh BgNVHSAEGjAYMAgGBmeBDAECATAMBgorBgEEAdZ5AgUDMDwGA1UdHwQ1MDMwMaAv oC2GK2h0dHA6Ly9jcmxzLnBraS5nb29nL2d0czFjMy9mVkp4YlYtS3Rtay5jcmww ggEEBgorBgEEAdZ5AgQCBIH1BIHyAPAAdgDuzdBk1dsazsVct520zROiModGfLzs 3sNRSFlGcR+1mwAAAY3AqKz3AAAEAwBHMEUCIQDODj3d6tB3O52F9JGeHcoQHvHa slsfd24LzJkh4vaT8QIgRYpJ5/KtmHRedvtIMpk5cphz7YQtNR9xCJqS/HZp+RkA dgDatr9rP7W2Ip+bwrtca+hwkXFsu1GEhTS9pD0wSNf7qwAAAY3AqK5zAAAEAwBH MEUCIGnYz1wq87LoxyEFmfNJMUpu3tbe+SoXEICpiSMb0QT2AiEA6RfPUZfe+KL4 d+1tNrMI7JcbS/7i1iluGfg7i7qvAzQwDQYJKoZIhvcNAQELBQADggEBAAedT7Wd Wf65c+210Rukhm/D3Gpku3QsYzo0fnAgGP4pTaH1w9DZN9YUSOoxlsfxBdldDdjy OBTOyf/anQCZGyTb6RTJcCDq39xRiDBxp/S5p/hOhSMqezjQkj4r+dNg3yBMQ9vM YVXjxQMNkEnBuaqF6gmymJITZ96cEiY7csPUemQp2qvBpwwkTlk09r36tg2llyN8 H2sGfiI+aMP+zTcCl96kBWh4W+dT+C90bjbZQvhzzuUT+sInPtUqcsCQ8ZNUeaY1 cwZlzV1fHFnDfHaMZN+3PO2eVHlbxR97v7FO6wLZYCPmcqlB2sj1uxucMT4tXaE7 pV0EwxaTDEzCaUs= -END CERTIFICATE- subject=CN = smtp.gmail.com issuer=C = US, O = Google Trust Services LLC, CN = GTS CA 1C3 --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 4295 bytes and written 386 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 256 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: BF3720957764F292088B747CAB9764DC744CF9D40FD60FBB743AFADE7B74D5F6 Session-ID-ctx: Resumption PSK: 52E8D459E26A5E1C0005DEAA70BFEAE44CDFA2E884A26709BD4FF34DF08639F74A4AE17B2C400C3EFBC0BD19164458B4 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 172800 (seconds) TLS session ticket: - 02 c4 7d 37 12 90 68 40-1e 21 95 25 51 12 e3 10 ..}7..h@.!.%Q... 0010 - 40 19 02 72 c3 8c 08 cd-bf dd d0 43 95 8f d0 d3 @..r...C 0020 - 42 2f d3 20 a8 56 03 24-74 3e a6 90 bc ac 3c 34 B/. .V.$t><4 0030 - f2 54 d5 69 7a 30 88 cb-6d c0 e9 a6 95 56 05 1e .T.iz0..mV.. 0040 - 94 57 e7 46 b8 36 8a fc-19 1e c3 a2 13 9b 52 b8 .W.F.6R. 0050 - 1c b1 2a b1 5e a0 24 f1-64 5f 43 f2 d8 eb 00 6e ..*.^.$.d_Cn 0060 - f1 93 e3 d3 05 ea 27 fb-e0 77 8d 85 0a 44 09 cb ..'..w...D.. 0070 - c2 7a 3b c5 86 40 03 98-eb 60 53 79 1b db 37 90 .z;..@...`Sy..7. 0080 - df 9b 39 5c bf 00 65 ba-09 5e a0 78 f6 f3 0c 44 ..9\..e..^.x...D 0090 - a6 fb c5 86 57 7f 66 11-db 42 6f ba df c5 04 cd W.f..Bo. 00a0 - 88 f5 3b 85 49 f0 89 6e-14 39 72 e1 64 7f e5 26 ..;.I..n.9r.d..& 00b0 - ec da 76 cd 8e c6 22 ea-49 8a 95 0e 50 82 d8 ec ..v...".I...P... 00c0 - ae 79 81 fb 43 e7 88 dd-dd 15 4d 66 c2 b0 6a 3a .y..C.Mf..j: 00d0 - 12 1f fb cd b9 dc 15 35-49 bd b4 f6 5c 2a 99 1a ...5I...\*.. 00e0 - 7f df 1b ae 54 50 45 4c-cd 6a 25 b7 c3 6e 58 TPEL.j%..nX Start Time: 1710942237 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- read R BLOCK --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID:
