Postfix ignoring check_recipient_access

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Postfix ignoring check_recipient_access

NeilNjae
Postfix seems to be ignoring the smtpd_recipient_restrictions =
check_recipient_access instruction.

I've got a Postfix + Dovecot + Amavis setup and all works fine. I use address
extensions for the virtual users, so I can "turn off" addresses that have been
included on spammers' lists.

When an email is "To" one of the turned off addresses, the header_checks
detects the message and deletes it.

When an email is only RCPT TO one of the turned off addresses, the
smtpd_recipient_restrictions = check_recipient_access instruction _should_ (I
think) tell Postfix to reject the message. But the messages still end up in my
inbox.

What am I missing here? How do I get check_recipient_access to reject the
addresses specified in the recipient_checks table?

(Postfix 2.11.0 running on Ubuntu 14.04.3 LTS)

Thanks,

Neil.


Logs and config follows:



/var/log/mail.log (This email should be rejected, but is instead accepted)
-----------------

Nov  8 17:48:07 pserver postfix/smtpd[15446]: connect from mail-
db3on0074.outbound.protection.outlook.com[157.55.234.74]                                                                                                                              
Nov  8 17:48:08 pserver postfix/smtpd[15446]: 0FC981C4: client=mail-
db3on0074.outbound.protection.outlook.com[157.55.234.74]                                                                                                                          
Nov  8 17:48:08 pserver postfix/cleanup[15451]: 0FC981C4: message-
id=<2020849.HWx7EOcjLU@desktop>                                                                                                                                                    
Nov  8 17:48:08 pserver postfix/qmgr[2638]: 0FC981C4:
from=<[hidden email]>, size=17198, nrcpt=1 (queue active)                                                                                                                                
Nov  8 17:48:08 pserver postfix/smtpd[15446]: disconnect from mail-
db3on0074.outbound.protection.outlook.com[157.55.234.74]                                                                                                                          
Nov  8 17:48:10 pserver postfix/smtpd[15456]: connect from
localhost[127.0.0.1]                                                                                                                                                                      
Nov  8 17:48:10 pserver postfix/smtpd[15456]: 286381DC:
client=localhost[127.0.0.1]                                                                                                                                                                  
Nov  8 17:48:10 pserver postfix/cleanup[15451]: 286381DC: message-
id=<2020849.HWx7EOcjLU@desktop>                                                                                                                                                    
Nov  8 17:48:10 pserver postfix/qmgr[2638]: 286381DC:
from=<[hidden email]>, size=17633, nrcpt=1 (queue active)                                                                                                                                
Nov  8 17:48:10 pserver postfix/smtpd[15456]: disconnect from
localhost[127.0.0.1]                                                                                                                                                                    
Nov  8 17:48:10 pserver amavis[12838]: (12838-14) Passed CLEAN
{RelayedInbound}, [157.55.234.74]:56949 [137.108.238.2] <[hidden email]>
-> <[hidden email]>, Queue-ID: 0FC981C4, Message-ID:
<2020849.HWx7EOcjLU@desktop>, mail_id: I_IbbLvsH2OU, Hits: -1.902, size:
17184, queued_as: 286381DC, 2017 ms                                                                                                                                                                                      
Nov  8 17:48:10 pserver postfix/smtp[15452]: 0FC981C4:
to=<[hidden email]>, relay=127.0.0.1[127.0.0.1]:10024, delay=2.2,
delays=0.16/0.01/0/2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:
[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 286381DC)                                                                                                                                                                                                                                                  
Nov  8 17:48:10 pserver postfix/qmgr[2638]: 0FC981C4: removed                                                                                                                                                                                        
Nov  8 17:48:10 pserver postfix/pipe[15457]: 286381DC:
to=<[hidden email]>, relay=dovecot, delay=0.22, delays=0.04/0/0/0.18,
dsn=2.0.0, status=sent (delivered via dovecot service)                                                              
Nov  8 17:48:10 pserver postfix/qmgr[2638]: 286381DC: removed


/var/log/mail.err
-----------------
<Nothing>


Config:
-------

root@pserver:/etc/postfix# postconf -nf
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
dovecot_destination_recipient_limit = 1
header_checks = regexp:/etc/postfix/header_checks
home_mailbox = Maildir/
inet_interfaces = all
mailbox_size_limit = 0
mailbox_transport = dovecot
mydestination = $myhostname localhost.$mydomain localhost
mydomain = example.org
myhostname = mail.$mydomain
mynetworks = 127.0.0.0/8, 192.168.1.0/24
myorigin = $mydomain
permit_mx_backup_networks = backup.com backup2.com
proxy_interfaces = 101.11.22.33
readme_directory = no
recipient_delimiter = .
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_restrictions = reject_unknown_helo_hostname
smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks
    permit_mx_backup check_recipient_access hash:/etc/postfix/recipient_checks
    reject_unauth_destination
smtpd_relay_restrictions = permit_sasl_authenticated permit_mynetworks
    permit_mx_backup check_recipient_access hash:/etc/postfix/recipient_checks
    reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_tls_cert_file = /etc/ssl/example/certs/mail-cert.pem
smtpd_tls_key_file = /etc/ssl/example/private/mail-key.pem
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_domains = otherdomain.org.uk other-domain.org.uk
virtual_alias_maps = hash:/etc/postfix/valiases
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/vmail
virtual_mailbox_domains = /etc/postfix/vhosts
virtual_mailbox_maps = hash:/etc/postfix/vmaps
virtual_minimum_uid = 1000
virtual_transport = dovecot
virtual_uid_maps = static:5000



/etc/postfix/recipient_checks
-----------------------------

# Reject messages with these recipient addresses
[hidden email] REJECT
[hidden email] REJECT
[hidden email] REJECT
[hidden email] REJECT
[hidden email] REJECT


Testing the map:
----------------

root@pserver:/etc/postfix# postmap -q [hidden email]
hash:/etc/postfix/recipient_checks
root@pserver:/etc/postfix# postmap -q [hidden email]
hash:/etc/postfix/recipient_checks
REJECT

Reply | Threaded
Open this post in threaded view
|

Re: Postfix ignoring check_recipient_access

Koko Wijatmoko
On Tue, 17 Nov 2015 12:44:12 +0000
Neil Smith <[hidden email]> wrote:

> Postfix seems to be ignoring the smtpd_recipient_restrictions =
> check_recipient_access instruction.
>
did you ran postmap for the hash table?
what inside your /etc/postfix/recipient_checks?
Reply | Threaded
Open this post in threaded view
|

Re: Postfix ignoring check_recipient_access

NeilNjae
On Tuesday 17 Nov 2015 20:50:32 Koko Wijatmoko wrote:
> On Tue, 17 Nov 2015 12:44:12 +0000
> Neil Smith <[hidden email]> wrote:
>
> > Postfix seems to be ignoring the smtpd_recipient_restrictions =
> > check_recipient_access instruction.
> >
> did you ran postmap for the hash table?

Yes, several times, and restarted postfix afterwards.

> what inside your /etc/postfix/recipient_checks?

That was at the bottom of the message:



/etc/postfix/recipient_checks
-----------------------------

# Reject messages with these recipient addresses
[hidden email] REJECT
[hidden email] REJECT
[hidden email] REJECT
[hidden email] REJECT
[hidden email] REJECT


Testing the map:
----------------

root@pserver:/etc/postfix# postmap -q [hidden email]
hash:/etc/postfix/recipient_checks
root@pserver:/etc/postfix# postmap -q [hidden email]
hash:/etc/postfix/recipient_checks
REJECT
Reply | Threaded
Open this post in threaded view
|

Re: Postfix ignoring check_recipient_access

Koko Wijatmoko
On Tue, 17 Nov 2015 13:56:01 +0000
Neil Smith <[hidden email]> wrote:

> > did you ran postmap for the hash table?
>
> Yes, several times, and restarted postfix afterwards.
>
is the file permission allow postfix to read it?
Reply | Threaded
Open this post in threaded view
|

Re: Postfix ignoring check_recipient_access

NeilNjae
On Tuesday 17 Nov 2015 21:04:00 Koko Wijatmoko wrote:
> On Tue, 17 Nov 2015 13:56:01 +0000
> Neil Smith <[hidden email]> wrote:
>
> > > did you ran postmap for the hash table?
> >
> > Yes, several times, and restarted postfix afterwards.
> >
> is the file permission allow postfix to read it?

Yes.

root@pserver:/etc/postfix# ls -lah
total 204K
drwxr-xr-x   3 root root 4.0K Oct  9 09:12 .
drwxr-xr-x 140 root root  12K Nov 17 01:31 ..
-rw-r--r--   1 root root  274 Sep 23  2012 dynamicmaps.cf
-rw-r--r--   1 root root 2.4K Oct  7 17:11 header_checks
-rw-r--r--   1 root root 3.4K Aug 24 11:58 main.cf
-rw-r--r--   1 root root 6.7K Sep 24  2012 master.cf
-rw-r--r--   1 root root  20K Feb  5  2015 postfix-files
-rwxr-xr-x   1 root root 8.7K Feb  5  2015 postfix-script
-rwxr-xr-x   1 root root  28K Feb  5  2015 post-install
-rw-r--r--   1 root root  475 Oct  7 17:25 recipient_checks
-rw-r--r--   1 root root  12K Oct  7 17:25 recipient_checks.db
drwxr-xr-x   2 root root 4.0K Jul 30  2012 sasl
-rw-r--r--   1 root root  640 May 27  2014 valiases
-rw-r--r--   1 root root  12K May 27  2014 valiases.db
-rw-r--r--   1 root root   42 Sep 23  2012 vhosts
-rw-r--r--   1 root root  178 Sep 24  2012 vmaps
-rw-r--r--   1 root root  12K Sep 24  2012 vmaps.db




Reply | Threaded
Open this post in threaded view
|

Re: Postfix ignoring check_recipient_access

Wietse Venema
In reply to this post by NeilNjae
Neil Smith:
> When an email is only RCPT TO one of the turned off addresses, the
> smtpd_recipient_restrictions = check_recipient_access instruction
> _should_ (I think) tell Postfix to reject the message. But the
> messages still end up in my inbox.
...
> smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks
>     permit_mx_backup check_recipient_access hash:/etc/postfix/recipient_checks
>     reject_unauth_destination

Put check_recipient_access at the BEGINNING of smtpd_recipient_restrictions.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Postfix ignoring check_recipient_access

Viktor Dukhovni
In reply to this post by NeilNjae
On Tue, Nov 17, 2015 at 12:44:12PM +0000, Neil Smith wrote:

> Postfix seems to be ignoring the smtpd_recipient_restrictions =
> check_recipient_access instruction.

Yes, "seems".  Postfix does not ignore its configuration.  It does
exactly what it is configured to do.  You really should choose a
better problem description.

    Nov  8 17:48:07 pserver postfix/smtpd[15446]: connect from mail-db3on0074.outbound.protection.outlook.com[157.55.234.74]
    Nov  8 17:48:08 pserver postfix/smtpd[15446]: 0FC981C4: client=mail-db3on0074.outbound.protection.outlook.com[157.55.234.74]
    Nov  8 17:48:08 pserver postfix/cleanup[15451]: 0FC981C4: message-id=<2020849.HWx7EOcjLU@desktop>
    Nov  8 17:48:08 pserver postfix/qmgr[2638]: 0FC981C4: from=<[hidden email]>, size=17198, nrcpt=1 (queue active)
    Nov  8 17:48:08 pserver postfix/smtpd[15446]: disconnect from mail-db3on0074.outbound.protection.outlook.com[157.55.234.74]
    Nov  8 17:48:10 pserver postfix/smtp[15452]: 0FC981C4: to=<[hidden email]>, relay=127.0.0.1[127.0.0.1]:10024, delay=2.2, delays=0.16/0.01/0/2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp: [127.0.0.1]:10025): 250 2.0.0 Ok: queued as 286381DC)
    Nov  8 17:48:10 pserver postfix/qmgr[2638]: 0FC981C4: removed

> root@pserver:/etc/postfix# postconf -nf
> mydestination = $myhostname localhost.$mydomain localhost
> mydomain = example.org
> myhostname = mail.$mydomain
> mynetworks = 127.0.0.0/8, 192.168.1.0/24
> myorigin = $mydomain
> permit_mx_backup_networks = backup.com backup2.com
> proxy_interfaces = 101.11.22.33
> recipient_delimiter = .
> smtpd_recipient_restrictions =
> permit_sasl_authenticated
> permit_mynetworks
>       permit_mx_backup
> check_recipient_access hash:/etc/postfix/recipient_checks
>       reject_unauth_destination

Notice that cute little "permit_mx_backup" in the restriction
list before "check_recipient_access"?  :-)

>
> /etc/postfix/recipient_checks
> -----------------------------
>
> # Reject messages with these recipient addresses
> [hidden email] REJECT
> [hidden email] REJECT
> [hidden email] REJECT
> [hidden email] REJECT
> [hidden email] REJECT

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Postfix ignoring check_recipient_access

NeilNjae
In reply to this post by Wietse Venema
On Tuesday 17 Nov 2015 09:37:44 Wietse Venema wrote:

> Put check_recipient_access at the BEGINNING of smtpd_recipient_restrictions.

Thank you, that seems to have fixed it. But...


On Tuesday 17 Nov 2015 14:43:50 Viktor Dukhovni wrote:

> > smtpd_recipient_restrictions =
> > permit_sasl_authenticated
> > permit_mynetworks
> >       permit_mx_backup
> > check_recipient_access hash:/etc/postfix/recipient_checks
> >       reject_unauth_destination
>
> Notice that cute little "permit_mx_backup" in the restriction
> list before "check_recipient_access"?  :-)

If you don't mind, could you please explain why that's a problem? The
recipient checks addresses aren't for any of the mxbackup domains. I don't
understand how allowing forwarding of mail for backup.com will mean the
acceptance of mail for example.com.

Thanks,

Neil.
Reply | Threaded
Open this post in threaded view
|

Re: Postfix ignoring check_recipient_access

Viktor Dukhovni
On Tue, Nov 17, 2015 at 03:26:55PM +0000, Neil Smith wrote:

> On Tuesday 17 Nov 2015 14:43:50 Viktor Dukhovni wrote:
>
> > > smtpd_recipient_restrictions =
> > > permit_sasl_authenticated
> > > permit_mynetworks
> > >       permit_mx_backup
> > > check_recipient_access hash:/etc/postfix/recipient_checks
> > >       reject_unauth_destination
> >
> > Notice that cute little "permit_mx_backup" in the restriction
> > list before "check_recipient_access"?  :-)
>
> If you don't mind, could you please explain why that's a problem? The
> recipient checks addresses aren't for any of the mxbackup domains. I don't
> understand how allowing forwarding of mail for backup.com will mean the
> acceptance of mail for example.com.

See:

    http://www.postfix.org/postconf.5.html#permit_mx_backup

Read the description attentively.  In general, permit_mx_backup is
a bad idea, instead configure "relay_domains" explicitly and get
rid of permit_mx_backup.  Don't forget about "relay_recipient_maps".

In any case your setting of

    http://www.postfix.org/postconf.5.html#permit_mx_backup_networks

is also suboptimal, these really should be addresses, not hostnames.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Postfix ignoring check_recipient_access

NeilNjae
On Tuesday 17 Nov 2015 15:50:22 Viktor Dukhovni wrote:

> On Tue, Nov 17, 2015 at 03:26:55PM +0000, Neil Smith wrote:
>
> > On Tuesday 17 Nov 2015 14:43:50 Viktor Dukhovni wrote:
> >
> > > > smtpd_recipient_restrictions =
> > > > permit_sasl_authenticated
> > > > permit_mynetworks
> > > >       permit_mx_backup
> > > > check_recipient_access hash:/etc/postfix/recipient_checks
> > > >       reject_unauth_destination
> > >
> > > Notice that cute little "permit_mx_backup" in the restriction
> > > list before "check_recipient_access"?  :-)
> >
> > If you don't mind, could you please explain why that's a problem?
>
> See:
>
>     http://www.postfix.org/postconf.5.html#permit_mx_backup
>
> Read the description attentively.  

OK, I think I understand. The permit_mx_backup directive is seeing that the
message is being delivered to someone on this host, so therefore Postfix
accepts the message before checking the recipient_access.  


> In general, permit_mx_backup is
> a bad idea, instead configure "relay_domains" explicitly and get
> rid of permit_mx_backup.  Don't forget about "relay_recipient_maps".

Thank you. I'll will go off and investigate making that better.

Neil.
Reply | Threaded
Open this post in threaded view
|

Untrusted TLS connection established headache

Istvan Prosinger
In reply to this post by NeilNjae
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 [hidden email]) - I get all "green"/

Best Regards,
Istvan
Reply | Threaded
Open this post in threaded view
|

Re: Untrusted TLS connection established headache

Viktor Dukhovni
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
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

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?

> BTW, when I do a test with
> http://checktls.com/
>
> (try [hidden email]) - I get all "green"/

That tests your Postfix SMTP server that receives mail from
remote domains.  Don't confuse the two services.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Untrusted TLS connection established headache

Viktor Dukhovni
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
the configuration above it, those are server certificates.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Untrusted TLS connection established headache

Bill Cole-3
In reply to this post by Istvan Prosinger
On 17 Nov 2015, at 14:02, Istvan Prosinger wrote:

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

[...]
> BTW, when I do a test with
> http://checktls.com/

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

Reply | Threaded
Open this post in threaded view
|

Re: Untrusted TLS connection established headache

Viktor Dukhovni
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
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.

No need.  That'll just make things more confusing.  With "may" the
peer is *never* "Trusted".

> One thing to try to find whether the problem is  due to your system's
> default CA configuration:

There is no problem.

--
        Viktor.