Re: TLS Issues. certificate unknown: SSL alert number 46:
On Tue, Oct 18, 2011 at 01:04:30PM -0400, Simon Brereton wrote: > 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. -- Viktor.
Re: TLS Issues. certificate unknown: SSL alert number 46:
On 10/18/2011 1:24 PM, Simon Brereton wrote: >> 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
Re: TLS Issues. certificate unknown: SSL alert number 46:
On 18 October 2011 14:17, Noel Jones wrote: > On 10/18/2011 12:04 PM, Simon Brereton wrote: >> On 13 October 2011 20:11, Noel Jones wrote: >>> 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? > > 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
Re: TLS Issues. certificate unknown: SSL alert number 46:
On 10/18/2011 12:04 PM, Simon Brereton wrote: > On 13 October 2011 20:11, Noel Jones wrote: >> 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? 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. > > 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
Re: TLS Issues. certificate unknown: SSL alert number 46:
On 2011-10-18 1:04 PM, Simon Brereton wrote: 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 -- Best regards, Charles
Re: TLS Issues. certificate unknown: SSL alert number 46:
On 13 October 2011 20:11, Noel Jones wrote: > 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
Re: TLS Issues. certificate unknown: SSL alert number 46:
On Fri, Oct 14, 2011 at 02:04:03PM -0500, Noel Jones wrote: > >> 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 :-) -- Viktor.
Re: TLS Issues. certificate unknown: SSL alert number 46:
On 10/14/2011 1:55 PM, Simon Brereton wrote: > On 13 October 2011 20:11, Noel Jones wrote: >> On 10/13/2011 6:39 PM, Simon Brereton wrote: >>> 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
Re: TLS Issues. certificate unknown: SSL alert number 46:
On 13 October 2011 20:11, Noel Jones wrote: > On 10/13/2011 6:39 PM, Simon Brereton wrote: >> 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
Re: TLS Issues. certificate unknown: SSL alert number 46:
On Thu, Oct 13, 2011 at 07:11:27PM -0500, Noel Jones wrote: > 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. > > 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. -- Viktor.
Re: TLS Issues. certificate unknown: SSL alert number 46:
On 10/13/2011 6:39 PM, Simon Brereton wrote: > 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. >> 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. > > 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
Re: TLS Issues. certificate unknown: SSL alert number 46:
On 13 October 2011 19:16, Noel Jones wrote:
> On 10/13/2011 5:41 PM, Mark Homoky wrote:
>> On 11 Oct 2011, at 15:54, "Simon Brereton"
>> wrote:
>>
>
> 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
Re: TLS Issues. certificate unknown: SSL alert number 46:
On 10/13/2011 5:41 PM, Mark Homoky wrote: > On 11 Oct 2011, at 15:54, "Simon Brereton" > wrote: > 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. -- Noel Jones
Re: TLS Issues. certificate unknown: SSL alert number 46:
On 11 Oct 2011, at 15:54, "Simon Brereton" wrote: >>> >>> 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. It might be useful for someone senior in Postfix development to look this over? >>> Sadly, it is not practical for >> everyone to learn SSL deeply enough to understand all the warnings. > > I'm deeply and painfully aware of this :( > > Simon +1 -- Mark Homoky. Sent from my iPhone.
RE: TLS Issues. certificate unknown: SSL alert number 46:
> -Original Message-
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Viktor Dukhovni
> On Fri, Oct 07, 2011 at 05:15:20PM -0400, Simon Brereton wrote:
>
> > postfix/smtpd[25614]: warning: TLS library problem:
> 25614:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown:s3_pkt.c:1102:SSL alert number 46:
>
> This client could not verify your server certificate, its SSL stack
> sent an "alert" to that effect.
Viktor - as always, I thank you - the help and advice on this is list is
unparalleled.
I presume they couldn't verify it because it's self-signed certificate?
> > I have absolutely no idea if my server is using TLS if it's offered
> for outgoing mail.
> >
> > In main.cf I have smtpd_use_tls = yes but the documentation tells
> me
> > 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.
> > mail:~# postconf -n | grep -i TLS
> > smtp_tls_note_starttls_offer = yes
> > smtp_tls_session_cache_database =
> btree:${data_directory}/smtp_scache
>
> 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.
> > smtpd_tls_loglevel = 2
>
> Too noisy. No more than 1, unless you're debugging a TLS
> interoperability problem
I'd put it at 2 to try and ascertain if it was me or the connecting host at
fault. Your reply above indicates it me (or at least because the host cant
verify my certificate)..
> > smtpd_use_tls = yes
>
> Use "smtpd_tls_security_level = may"
Fixed. Thanks.
> > And how can I be sure those errors in the logs are the connecting
> host and not mine?
>
> Reduce the loglevel to 1, then ignore most TLS warnings that don't
> correlate with non-delivery of mail. Sadly, it is not practical for
> everyone to learn SSL deeply enough to understand all the warnings.
I'm deeply and painfully aware of this :(
Simon
Re: TLS Issues. certificate unknown: SSL alert number 46:
On Fri, Oct 07, 2011 at 05:15:20PM -0400, Simon Brereton wrote:
> postfix/smtpd[25614]: warning: TLS library problem: 25614:error:14094416:SSL
> routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:s3_pkt.c:1102:SSL
> alert number 46:
This client could not verify your server certificate, its SSL stack
sent an "alert" to that effect.
> I have absolutely no idea if my server is using TLS if it's offered for
> outgoing mail.
>
> In main.cf I have smtpd_use_tls = yes but the documentation tells
> me 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.
> mail:~# postconf -n | grep -i TLS
> smtp_tls_note_starttls_offer = yes
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
With no other settings for the SMTP client, outgoing TLS is disabled
on your machine. You need "smtp_tls_security_level = may".
> smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
> smtpd_tls_auth_only = no
> smtpd_tls_key_file = /etc/ssl/private/mail..net.key
> smtpd_tls_received_header = yes
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> smtpd_tls_session_cache_timeout = 3600s
Fine.
> 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.
> smtpd_tls_loglevel = 2
Too noisy. No more than 1, unless you're debugging a TLS interoperability
problem
> smtpd_use_tls = yes
Use "smtpd_tls_security_level = may"
> tls_random_source = dev:/dev/urandom
This should be the default.
> How can I be sure my server is using TLS for hosts that offer it?
See above.
> And how can I be sure those errors in the logs are the connecting host and
> not mine?
Reduce the loglevel to 1, then ignore most TLS warnings that don't
correlate with non-delivery of mail. Sadly, it is not practical for
everyone to learn SSL deeply enough to understand all the warnings.
--
Viktor.
