TLS Issues. certificate unknown: SSL alert number 46:

[Simon Brereton]

this is obseleted (I'm running 2.7.1) and to use
smtpd_tls_security_level = may instead - however, vim tells me that
the former is a valid configurable (it's highlighted) whilst the
latter is not.  That's part of my confusion.

The authors of vim are not Postfix experts.

Among the other things it's not practical enough to know is how vim does this anyway.  I assumed there was some sort of file it checks in the postfix sources.  But I'll amend this.

No, it's a vim syntax file IIRC.

Yes.

It might be useful for someone senior in Postfix development to look this over?

Postfix evolves, the vim syntax file hasn't.  Updating the current
vim syntax file probably isn't terribly complicated, but is well
outside the scope of postfix and would be an ongoing project.
If you want to fix it,  just go through the postconf(5) and
master(5) man pages and make sure all valid parameters are included
in the vim file (Probably near 800 if you also include all the valid
smptd_*_restrictions options).
My solution would be to remove the misleading vim syntax file.

With all due respect to Mr Jones - for the inexperienced among us that
would be like amputating the leg to fix a broken ACL. No, the message
is clear - believe the postconf (5) more than the pretty colours in
vim. Problem solved.

If it bugged me enough I'd file a bug report with the vim people. I
may yet do that in the spirit of contributing to opensource since I
can't code worth a fig.

I'd still like some more hand-holding on my earlier questions in
response to Viktor..

With no other settings for the SMTP client, outgoing TLS is disabled
on your machine. You need "smtp_tls_security_level = may".

Thanks - you've already made the TLS_README more understandable. I've
added that. Do I need to add other parameters?

smtp_tls_security_level = may
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtp_tls_CAfile = ?
smtp_tls_cert_file = ?
smtp_tls_key_file = ?
smtp_tls_loglevel = 1

smtpd_tls_CAfile = /etc/ssl/keys/ca.crt smtpd_tls_cert_file =
/etc/ssl/keys/mail..net.crt

Not needed, you neither ask for nor verify client certs.

Should I be? And if so, how do I do that? Bearing in mind, I think
I'd only want to verify them if they are actually used.

But the errors in my log are down and so for now I can live with it
unless anyone has anything more to add. The problem with TLS/SSL is
one always has the horrible suspicion one has left a gaping back-door
open...



Simon

[Noel Jones]

Post by Simon Brereton
smtp_tls_CAfile = ?
smtp_tls_cert_file = ?
smtp_tls_key_file = ?

Typcially these would be set to the same cert & keys as used by smtpd.

Post by Simon Brereton

Not needed, you neither ask for nor verify client certs.

Should I be? And if so, how do I do that? Bearing in mind, I think
I'd only want to verify them if they are actually used.

With opportunistic TLS there is no need to verify client
certificates -- you're willing to accept an unencrypted connection,
so it doesn't matter if an encrypted connection uses an invalid
certificate. Also, some clients choke on a certificate request, so
it improves interoperability to just ignore them.

The only time you care about the client certificate if if you are
setting up a "secure" channel with another server that requires
verified TLS. This is not needed with a general-purpose MX.

Post by Simon Brereton
But the errors in my log are down and so for now I can live with it
unless anyone has anything more to add. The problem with TLS/SSL is
one always has the horrible suspicion one has left a gaping back-door
open...

As a general rule, you shouldn't care very much. TLS generally
either works (noted in the log with tls_loglevel=1), or doesn't work
(no mail is transferred), or isn't used (noted in the log by an
absence of TLS logging at tls_loglevel=1).

Since this is opportunistic use-it-if-you-can-but-not-required TLS,
on a very basic level it doesn't matter if it's used or not, which
is why tls_loglevel default is 0.

The only place you should really care about encryption is if your
own clients submit SASL authenticated mail -- the far most common
auth mechanisms are PLAIN and LOGIN which really should be protected
inside a TLS connection. This is commonly controlled by using
"smtpd_tls_auth_only = yes", and if you use the recommended
submission port, setting '-o smtpd_enforce_tls=yes' on the
submission entry in master.cf. In these cases, if TLS isn't used or
doesn't work, the client can't transfer mail.



-- Noel Jones

[Viktor Dukhovni]

Typically these would be set to the same cert & keys as used by smtpd.

My recommendation is to leave the client key/cert settings empty.
These should only be set for transports used with TLS client auth
by mutual arrangement with a destination server that requires TLS
client auth.

Post by Simon Brereton
I'd only want to verify them if they are actually used.

With opportunistic TLS there is no need to verify client
certificates -- you're willing to accept an unencrypted connection,
so it doesn't matter if an encrypted connection uses an invalid
certificate.

No opportunity either, since it is best to not request client certs,
and thus none will ever be sent.

Also, some clients choke on a certificate request, so
it improves interoperability to just ignore them.

To not ask for them, and thus none will ever be sent.

The only place you should really care about encryption is if your
own clients submit SASL authenticated mail [...]

Well protection against passive wiretaps can be helpful in many
cases. So I would not discourage the use of opportunistic outbound
TLS.

[Simon Brereton]

Post by Noel Jones

Post by Simon Brereton
smtp_tls_CAfile = ?
smtp_tls_cert_file = ?
smtp_tls_key_file = ?

Typcially these would be set to the same cert & keys as used by smtpd.

Since these are self-signed certificates, would it be possible to use
a URL for the CA file?

Simon

[Noel Jones]

Post by Simon Brereton

Post by Noel Jones

Post by Simon Brereton
smtp_tls_CAfile = ?
smtp_tls_cert_file = ?
smtp_tls_key_file = ?

Typcially these would be set to the same cert & keys as used by smtpd.

Since these are self-signed certificates, would it be possible to use
a URL for the CA file?
Simon

No, the documentation says a file, not a URL.
Or just leave these settings empty as Viktor and the documentation
suggests.


-- Noel Jones

[Viktor Dukhovni]

Post by Noel Jones

Post by Simon Brereton

Typically these would be set to the same cert & keys as used by smtpd.

Since these are self-signed certificates, would it be possible to use
a URL for the CA file?

No, the documentation says a file, not a URL.
Or just leave these settings empty as Viktor and the documentation
suggests.

FWIW, that's not really two sources, I wrote that part of the documentation :-)

[Simon Brereton]

Post by Noel Jones
The only place you should really care about encryption is if your
own clients submit SASL authenticated mail -- the far most common
auth mechanisms are PLAIN and LOGIN which really should be protected
inside a TLS connection.  This is commonly controlled by using
"smtpd_tls_auth_only = yes", and if you use the recommended
submission port, setting '-o smtpd_enforce_tls=yes' on the
submission entry in master.cf.  In these cases, if TLS isn't used or
doesn't work, the client can't transfer mail.

Sorry to resurrect this - and gmail won't let me amend the subject.
After reading this, I was concerned about my submission port
settings.. I have:

10 submission inet n - n - - smtpd
11 -o smtpd_delay_reject=yes
12 -o receive_override_options=no_address_mappings
13 -o content_filter=dksign:[127.0.0.1]:10028
14 -o smtpd_enforce_tls=yes
15 -o smtpd_sasl_auth_enable=yes
16 -o smtpd_client_restrictions=permit_sasl_authenticated,reject


Is "smtpd_enforce_tls=yes" a suitable replacement/substitute for
"smtpd_tls_auth_only = yes?

The TLS readme only talks about smtpd_tls_auth_only (and warns
against it) for server-server connections.

Simon

[Charles Marcus]

Post by Simon Brereton
Is "smtpd_enforce_tls=yes" a suitable replacement/substitute for
"smtpd_tls_auth_only = yes?

No, they are two different things.

What version of postfix? For current/latest version of postfix I use both:

smtpd_tls_security_level=encrypt
smtpd_tls_auth_only=yes

[Noel Jones]

Post by Simon Brereton

Post by Noel Jones
The only place you should really care about encryption is if your
own clients submit SASL authenticated mail -- the far most common
auth mechanisms are PLAIN and LOGIN which really should be protected
inside a TLS connection. This is commonly controlled by using
"smtpd_tls_auth_only = yes", and if you use the recommended
submission port, setting '-o smtpd_enforce_tls=yes' on the
submission entry in master.cf. In these cases, if TLS isn't used or
doesn't work, the client can't transfer mail.

Sorry to resurrect this - and gmail won't let me amend the subject.
After reading this, I was concerned about my submission port
10 submission inet n - n - - smtpd
11 -o smtpd_delay_reject=yes
12 -o receive_override_options=no_address_mappings
13 -o content_filter=dksign:[127.0.0.1]:10028
14 -o smtpd_enforce_tls=yes
15 -o smtpd_sasl_auth_enable=yes
16 -o smtpd_client_restrictions=permit_sasl_authenticated,reject
Is "smtpd_enforce_tls=yes" a suitable replacement/substitute for
"smtpd_tls_auth_only = yes?

They do different things; I expect most people use both.

smtpd_enforce_tls is obsolete, instead use
-o smtpd_tls_security_level=encrypt
This setting will reject all mail from unencrypted connections. The
"encrypt" setting must not be used on a public-facing port 25, but
is widely used and recommended on the submission port.

smtpd_tls_auth_only prevents postfix from offering or accepting the
AUTH command until after an encrypted session is started. It is
commonly used on both the submission port and on port 25.

Post by Simon Brereton
The TLS readme only talks about smtpd_tls_auth_only (and warns
against it) for server-server connections.

I don't see that.

http://www.postfix.org/TLS_README.html#server_tls_auth doesn't
mention servers.

http://www.postfix.org/TLS_README.html#server_enable mentions both
smtpd_tls_security_level and the obsolete smtpd_enforce_tls, and
warns that encryption must not be required on public-facing SMTP
servers (that means your MX on port 25).


-- Noel Jones

[Simon Brereton]

Post by Noel Jones

Post by Simon Brereton

Post by Noel Jones
The only place you should really care about encryption is if your
own clients submit SASL authenticated mail -- the far most common
auth mechanisms are PLAIN and LOGIN which really should be protected
inside a TLS connection.  This is commonly controlled by using
"smtpd_tls_auth_only = yes", and if you use the recommended
submission port, setting '-o smtpd_enforce_tls=yes' on the
submission entry in master.cf.  In these cases, if TLS isn't used or
doesn't work, the client can't transfer mail.

Sorry to resurrect this - and gmail won't let me amend the subject.
After reading this, I was concerned about my submission port
 10 submission inet n       -       n       -       -       smtpd
 11    -o smtpd_delay_reject=yes
 12    -o receive_override_options=no_address_mappings
 13    -o content_filter=dksign:[127.0.0.1]:10028
 14    -o smtpd_enforce_tls=yes
 15    -o smtpd_sasl_auth_enable=yes
 16    -o smtpd_client_restrictions=permit_sasl_authenticated,reject
Is  "smtpd_enforce_tls=yes" a suitable replacement/substitute for
"smtpd_tls_auth_only = yes?

They do different things; I expect most people use both.
smtpd_enforce_tls is obsolete, instead use
 -o smtpd_tls_security_level=encrypt
This setting will reject all mail from unencrypted connections.  The
"encrypt" setting must not be used on a public-facing port 25, but
is widely used and recommended on the submission port.
smtpd_tls_auth_only prevents postfix from offering or accepting the
AUTH command until after an encrypted session is started.  It is
commonly used on both the submission port and on port 25.

Thanks for the clarification. I'm using both without an issue (so far
- I'm waiting for the one user - and there's always one) to tell me
their client has stopped working.

Cheers

Simon

[Noel Jones]

Post by Simon Brereton

Post by Noel Jones
smtpd_enforce_tls is obsolete, instead use
-o smtpd_tls_security_level=encrypt
This setting will reject all mail from unencrypted connections. The
"encrypt" setting must not be used on a public-facing port 25, but
is widely used and recommended on the submission port.
smtpd_tls_auth_only prevents postfix from offering or accepting the
AUTH command until after an encrypted session is started. It is
commonly used on both the submission port and on port 25.

Thanks for the clarification. I'm using both without an issue (so far
- I'm waiting for the one user - and there's always one) to tell me
their client has stopped working.

The only problem you might see is with older clients and some
portable devices that don't support STARTTLS.

To get those stragglers, you can also enable smtps port 465 in
master.cf. Use the same options as submission adding
-o smtpd_tls_wrappermode=yes



-- Noel Jones

[Viktor Dukhovni]

Post by Simon Brereton
Is "smtpd_enforce_tls=yes" a suitable replacement/substitute for
"smtpd_tls_auth_only = yes?

With smtpd_tls_security_level=encrypt (or its legacy form) the
smtpd_tls_auth_only feature is arguably reduntant, but it is
harmless, and can prevent issues of the TLS requirement is relaxed.
Feel free to leave it in place.