On 2024/3/23 04:57, Wietse Venema via Postfix-users wrote:
Unleess you can hand over the certificate that Postfix complained
about, you have not proven that Postfix was in error.
You are right, I can't guarantee if the certificate openssl dumped was
the one Postfix encountered.
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
Yes, make sense. It's possible that the backend of smtp.gmail.com
produced self-signed certificates in certain period.
I grep the logs last time the problem happened, smtp.gmail.com resolved
to "64.233.189.108" and "64.233.189.109" but all were out of luck to me.
--------8<--------8<--------8<--------
$ grep -i self-signed /var/log/mail.log
Mar 20 20:41:09 s6 postfix/smtp[1097]: certificate verification failed
for smtp.gmail.com[64.233.189.108]:465: self-signed certificate
Mar 20 20:50:54 s6 postfix/smtp[3661]: certificate verification failed
for smtp.gmail.com[64.233.189.109]:465: self-signed certificate
Mar 20 21:03:59 s6 postfix/smtp[6635]: certificate verification failed
for smtp.gmail.com[64.233.189.109]:465: self-signed certificate
Mar 20 21:27:38 s6 postfix/smtp[15534]: certificate verification failed
for smtp.gmail.com[64.233.189.109]:465: self-signed certificate
--------8<--------8<--------8<--------
Then I deleted this mail from the queue by using the postsuper.
On 2024/3/23 04:26, Viktor Dukhovni via Postfix-users wrote:
> 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.
>
Happy to know this.
>
> 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"?
>
My smtp_tls_policy_maps points to a hash table and the relevant entry is
[smtp.gmail.com]:465 secure
The smtp_tls_security_level in main.cf is
smtp_tls_security_level = may
>> 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.
>
Ok, you should be correct. The more precise statement from the Wikipedia
is "self-signed certificates are public key certificates that are not
issued by a certificate authority (CA)." So maybe that once the CA isn't
listed in the CAfile the Postfix or the ssl library treats it as a
self-signed certificate.
>> 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.
>
I will do your suggestions next time I encounter this issue.
I'm afraid, however, at last time I encountered this problem, I managed
to use openssl s_client to test the smtp.gmail.com while the Postfix
continue to encounter this problem (as I answered to Wietse that I grep
the log).
Though I still can't guarantee both Postfix and openssl got the same
certificate from the smtp.gmail.com and I didn't use the IP address for
openssl s_client.
> 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).
Ok, I see.
>
>> 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.
>
I know. :)
>> 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.
>
I understand what you mean.
>> 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.
>
It's good to me.
> 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 GMT; NotAfter: Jan 28
00:00:42 2028 GMT
>
> $ openssl s_client -noservername -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: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
> v:NotBefore: Feb 26 08:17:53 2024 GMT; NotAfter: May 20
08:17:52 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 GMT; NotAfter: Jan 28
00:00:42 2028 GMT
>
> With posttls-finger, I see:
>
> $ posttls-finger -wc -F /etc/ssl/cert.pem -lsecure
"[64.233.189.109]:465" smtp.gmail.com
> posttls-finger: 64.233.189.109[64.233.189.109]:465: matched
peername: smtp.gmail.com
> posttls-finger: 64.233.189.109[64.233.189.109]:465:
subject_CN=smtp.gmail.com, issuer=GTS CA 1C3, cert
fingerprint=F7:5F:AA:8D:B5:7A:A7:A4:8A:34:0C:C3:12:18:D8:77:3B:A9:F7:75:E1:EC:76:25:76:79:41:B2:AB:46:34:E1,
pkey
fingerprint=E9:BB:66:2D:A5:7C:05:FD:C4:EE:2D:CD:33:9C:32:6D:F7:99:7E:66:29:1F:F0:A4:5E:42:05:57:32:10:7C:96
> posttls-finger: Verified TLS connection established to
64.233.189.109[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
>
> At this time, nothing that matches your reported symptoms.
>
Me too.
So, I will collect necessary information next time I encounter this
issue as what Viktor suggested.
Thanks! :)
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
