Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Untrusted TLS connection established headache
3,454 views
Skip to first unread message
Istvan Prosinger
Nov 17, 2015, 2:03:01 PM11/17/15
to
Hi,
I'm trying to install the signed STARTSSL certificates to Postfix, but
I'm getting this entry whatever I do:
Nov 17 18:41:39 knox postfix/smtp[32153]: Untrusted TLS connection
established to gmail-smtp-in.l.google.com[74.125.133.26]:25: TLSv1.2
with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
I'm out of ideas, starting experimenting with certs, and that won't lead
me to understanding the problem. Here's the TLS config:
[root@knox certs]# postconf -n | grep tls
smtp_tls_CAfile = /etc/ssl/certs/startssl-ca-bundle.pem
smtp_tls_CApath = /etc/ssl/certs/
smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/prosinger_new_bundle.crt
smtpd_tls_key_file = /etc/ssl/certs/prosinger_new.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtpd_use_tls = yes
BTW, when I do a test with
http://checktls.com/
(try ist...@prosinger.net) - I get all "green"/
Best Regards,
Istvan
I'm trying to install the signed STARTSSL certificates to Postfix, but
I'm getting this entry whatever I do:
Nov 17 18:41:39 knox postfix/smtp[32153]: Untrusted TLS connection
established to gmail-smtp-in.l.google.com[74.125.133.26]:25: TLSv1.2
with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
I'm out of ideas, starting experimenting with certs, and that won't lead
me to understanding the problem. Here's the TLS config:
[root@knox certs]# postconf -n | grep tls
smtp_tls_CAfile = /etc/ssl/certs/startssl-ca-bundle.pem
smtp_tls_CApath = /etc/ssl/certs/
smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/prosinger_new_bundle.crt
smtpd_tls_key_file = /etc/ssl/certs/prosinger_new.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtpd_use_tls = yes
BTW, when I do a test with
http://checktls.com/
(try ist...@prosinger.net) - I get all "green"/
Best Regards,
Istvan
Viktor Dukhovni
Nov 17, 2015, 2:14:43 PM11/17/15
to
On Tue, Nov 17, 2015 at 08:02:35PM +0100, Istvan Prosinger wrote:
> I'm trying to install the signed STARTSSL certificates to Postfix, but I'm
> getting this entry whatever I do:
>
> Nov 17 18:41:39 knox postfix/smtp[32153]: Untrusted TLS connection
> established to gmail-smtp-in.l.google.com[74.125.133.26]:25: TLSv1.2 with
> cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
These are logs from your local Postfix SMTP client that sends mail
> I'm trying to install the signed STARTSSL certificates to Postfix, but I'm
> getting this entry whatever I do:
>
> Nov 17 18:41:39 knox postfix/smtp[32153]: Untrusted TLS connection
> established to gmail-smtp-in.l.google.com[74.125.133.26]:25: TLSv1.2 with
> cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
to remote domains.
Well, you can't replace Google's certificates unless you're
administering Google's servers. Perhaps you mean that you're trying
to install trust-anchor certificates (that is, certificate authority
certificates, not server certificates).
> [root@knox certs]# postconf -n | grep tls
> smtp_tls_CAfile = /etc/ssl/certs/startssl-ca-bundle.pem
> smtp_tls_CApath = /etc/ssl/certs/
> smtp_tls_loglevel = 1
> smtp_tls_security_level = may
and so are never "Trusted".
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/ssl/certs/prosinger_new_bundle.crt
> smtpd_tls_key_file = /etc/ssl/certs/prosinger_new.key
SMTP server expecting you to use these to authenticate yourself
for mail submission?
> BTW, when I do a test with
> http://checktls.com/
>
> (try ist...@prosinger.net) - I get all "green"/
remote domains. Don't confuse the two services.
--
Viktor.
Viktor Dukhovni
Nov 17, 2015, 7:38:23 PM11/17/15
to
On Tue, Nov 17, 2015 at 07:14:21PM +0000, Viktor Dukhovni wrote:
> > smtp_tls_CAfile = /etc/ssl/certs/startssl-ca-bundle.pem
> > smtp_tls_CApath = /etc/ssl/certs/
> > smtp_tls_loglevel = 1
> > smtp_tls_security_level = may
>
> With opportunistic TLS ("may") certificates are never verified,
> and so are never "Trusted".
>
> > smtpd_tls_auth_only = yes
> > smtpd_tls_cert_file = /etc/ssl/certs/prosinger_new_bundle.crt
> > smtpd_tls_key_file = /etc/ssl/certs/prosinger_new.key
>
> Enabling client certificates is generally a bad idea. Is remote
> SMTP server expecting you to use these to authenticate yourself
> for mail submission?
Note, that the comment was related to your client logs, not
> > smtp_tls_CAfile = /etc/ssl/certs/startssl-ca-bundle.pem
> > smtp_tls_CApath = /etc/ssl/certs/
> > smtp_tls_loglevel = 1
> > smtp_tls_security_level = may
>
> With opportunistic TLS ("may") certificates are never verified,
> and so are never "Trusted".
>
> > smtpd_tls_auth_only = yes
> > smtpd_tls_cert_file = /etc/ssl/certs/prosinger_new_bundle.crt
> > smtpd_tls_key_file = /etc/ssl/certs/prosinger_new.key
>
> Enabling client certificates is generally a bad idea. Is remote
> SMTP server expecting you to use these to authenticate yourself
> for mail submission?
the configuration above it, those are server certificates.
--
Viktor.
Bill Cole
Nov 17, 2015, 10:58:50 PM11/17/15
to
On 17 Nov 2015, at 14:02, Istvan Prosinger wrote:
> Hi,
postfix/smtpd (the receiving server) so no Postfix setting that starts
with 'smtpd' is involved.
NOTE 2: This is *probably* not a problem. It only means that your smtp
process can't verify the certificates being used by Google. If that's
really Google.... It might be someone hijacking your port 25
connections to Google. However, if someone is able to do that well
enough that you are making untrusted TLS connections, you won't fix it
short of requiring verified TLS encryption all connections, which is not
a working config for a mail server that talks to the likes of Google.
> I'm out of ideas, starting experimenting with certs, and that won't
> lead me to understanding the problem. Here's the TLS config:
>
directory where there are some CA certs. Read the docs (man 5 postconf).
Either unset that parameter, figure out where you have a correctly
populated CA directory, or create such a directory. If you have the smtp
service in a chroot jail (see master.cf) the CApath needs to be relative
to that jail.
> smtp_tls_loglevel = 1
Switch that to 2 to see the details of the verification failure. Don't
leave it at 2 for normal use.
[...]
Irrelevant: that checks your smtpd. This is NOT smtpd, it is smtp. Those
are two completely different programs, both parts of Postfix but
otherwise not related to each other in any way.
One thing to try to find whether the problem is due to your system's
default CA configuration:
openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp
That sets up a SMTP STARTTLS session with one of Google's inbound
servers. It will show you the certs and verification details. (Type
'quit' to terminate the SMTP session and exit at the end)
If s_client reports "Verify return code: 0 (ok)" near the end of the
setup, you should be able to get Postfix's smtp program to verify its
connections as well by getting Postfix to use the same CA collection as
the openssl tool is using.
If s_client doesn't report "Verify return code: 0 (ok)" then earlier in
its output it will show the full CA chain and where verification broke.
For example, here's my run of that, with the middle part of the output
snipped out for clarity:
# openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp
CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN =
mx.google.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
[...]
0080 - 41 8d c0 f7 38 67 b3 8f-19 3b 31 df 6b da 61 ea
A...8g...;1.k.a.
0090 - 1c f6 57 5c 9f 75 30 48-a2 4d 27 b7 0e 48 57 12
..W\.u0H.M'..HW.
00a0 - e8 68 58 90 .hX.
Start Time: 1447818970
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
250 SMTPUTF8
quit
221 2.0.0 closing connection w124si854343ywe.389 - gsmtp
read:errno=0
> Hi,
>
> I'm trying to install the signed STARTSSL certificates to Postfix, but
> I'm getting this entry whatever I do:
>
> Nov 17 18:41:39 knox postfix/smtp[32153]: Untrusted TLS connection
> established to gmail-smtp-in.l.google.com[74.125.133.26]:25: TLSv1.2
> with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
NOTE 1: This is logged by postfix/smtp (the sending client) NOT
> I'm trying to install the signed STARTSSL certificates to Postfix, but
> I'm getting this entry whatever I do:
>
> Nov 17 18:41:39 knox postfix/smtp[32153]: Untrusted TLS connection
> established to gmail-smtp-in.l.google.com[74.125.133.26]:25: TLSv1.2
> with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
postfix/smtpd (the receiving server) so no Postfix setting that starts
with 'smtpd' is involved.
NOTE 2: This is *probably* not a problem. It only means that your smtp
process can't verify the certificates being used by Google. If that's
really Google.... It might be someone hijacking your port 25
connections to Google. However, if someone is able to do that well
enough that you are making untrusted TLS connections, you won't fix it
short of requiring verified TLS encryption all connections, which is not
a working config for a mail server that talks to the likes of Google.
> I'm out of ideas, starting experimenting with certs, and that won't
> lead me to understanding the problem. Here's the TLS config:
>
> [root@knox certs]# postconf -n | grep tls
> smtp_tls_CAfile = /etc/ssl/certs/startssl-ca-bundle.pem
> smtp_tls_CApath = /etc/ssl/certs/
That's likely to be wrong. smtp_tls_CApath needs to be more than just a
> smtp_tls_CApath = /etc/ssl/certs/
directory where there are some CA certs. Read the docs (man 5 postconf).
Either unset that parameter, figure out where you have a correctly
populated CA directory, or create such a directory. If you have the smtp
service in a chroot jail (see master.cf) the CApath needs to be relative
to that jail.
> smtp_tls_loglevel = 1
Switch that to 2 to see the details of the verification failure. Don't
leave it at 2 for normal use.
[...]
Irrelevant: that checks your smtpd. This is NOT smtpd, it is smtp. Those
are two completely different programs, both parts of Postfix but
otherwise not related to each other in any way.
One thing to try to find whether the problem is due to your system's
default CA configuration:
openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp
That sets up a SMTP STARTTLS session with one of Google's inbound
servers. It will show you the certs and verification details. (Type
'quit' to terminate the SMTP session and exit at the end)
If s_client reports "Verify return code: 0 (ok)" near the end of the
setup, you should be able to get Postfix's smtp program to verify its
connections as well by getting Postfix to use the same CA collection as
the openssl tool is using.
If s_client doesn't report "Verify return code: 0 (ok)" then earlier in
its output it will show the full CA chain and where verification broke.
For example, here's my run of that, with the middle part of the output
snipped out for clarity:
# openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp
CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN =
mx.google.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
[...]
0080 - 41 8d c0 f7 38 67 b3 8f-19 3b 31 df 6b da 61 ea
A...8g...;1.k.a.
0090 - 1c f6 57 5c 9f 75 30 48-a2 4d 27 b7 0e 48 57 12
..W\.u0H.M'..HW.
00a0 - e8 68 58 90 .hX.
Start Time: 1447818970
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
250 SMTPUTF8
quit
221 2.0.0 closing connection w124si854343ywe.389 - gsmtp
read:errno=0
Viktor Dukhovni
Nov 17, 2015, 11:06:34 PM11/17/15
to
On Tue, Nov 17, 2015 at 10:58:13PM -0500, Bill Cole wrote:
> >[root@knox certs]# postconf -n | grep tls
> >smtp_tls_CAfile = /etc/ssl/certs/startssl-ca-bundle.pem
> >smtp_tls_CApath = /etc/ssl/certs/
>
> That's likely to be wrong. smtp_tls_CApath needs to be more than just a
> directory where there are some CA certs.
On many a Debian system, /etc/ssl/certs is automatically c_rehash'ed
> >[root@knox certs]# postconf -n | grep tls
> >smtp_tls_CAfile = /etc/ssl/certs/startssl-ca-bundle.pem
> >smtp_tls_CApath = /etc/ssl/certs/
>
> That's likely to be wrong. smtp_tls_CApath needs to be more than just a
> directory where there are some CA certs.
by the Debian package that manages trusted CAs. So it could well
be right. Of course chroot voids the warranty.
> >smtp_tls_loglevel = 1
>
> Switch that to 2 to see the details of the verification failure. Don't leave
> it at 2 for normal use.
peer is *never* "Trusted".
> One thing to try to find whether the problem is due to your system's
> default CA configuration:
--
Viktor.
0 new messages