TLS Issues. certificate unknown: SSL alert number 46:
Simon Brereton
My log files has a moderate amount of TLS warnings:
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:
I'm aware that this could be (according to an older thread on this list) just an issue with the clients that are connecting to me. However, I'd like to be sure that this is the case.
I've spent all day reading http://www.postfix.org/TLS_README.html but I'm not really any the wiser.
What I would like is:
SMTP
:: MUAs connecting on 587 are required to use TLS
:: MUAs connecting on 25 can use TLS if the want to
SMTPD
:: Hosts connecting to me are offered TLS and use it
:: That my server use TLS if it is offered by a remote host
I think I'm fixed on the first one. My master.cf says:
submission inet n - n - - smtpd
-o smtpd_delay_reject=yes
-o receive_override_options=no_address_mappings
-o content_filter=dksign:[127.0.0.1]:10028
-o smtpd_enforce_tls=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_tls_security_level=encrypt
I think the error is related to the third point.
And 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.
mail:~# postconf -n | grep -i TLS
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
smtpd_tls_CAfile = /etc/ssl/keys/ca.crt
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/ssl/keys/mail..net.crt
smtpd_tls_key_file = /etc/ssl/private/mail..net.key
smtpd_tls_loglevel = 2
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
How can I be sure my server is using TLS for hosts that offer it?
And how can I be sure those errors in the logs are the connecting host and not mine?
Thanks for any advice.
Simon
Viktor Dukhovni
> 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.
Simon Brereton
> From: owner-pos...@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.
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.
> > 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".
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
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.
> > 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"
> > 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.
Simon
Mark Homoky
>>>
>>> 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.
Noel Jones
> On 11 Oct 2011, at 15:54, "Simon Brereton" <simon.b...@buongiorno.com> 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
Simon Brereton
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
> 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
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.
> > 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.
Simon Brereton
> On 10/13/2011 6:39 PM, Simon Brereton wrote:
>> smtp_tls_CAfile = ?
>> smtp_tls_cert_file = ?
>> smtp_tls_key_file = ?
>
Since these are self-signed certificates, would it be possible to use
a URL for the CA file?
Simon
Noel Jones
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
> >> 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.
Simon Brereton
> 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.
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
> Is "smtpd_enforce_tls=yes" a suitable replacement/substitute for
> "smtpd_tls_auth_only = yes?
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
Noel Jones
> On 13 October 2011 20:11, Noel Jones <njo...@megan.vbhcs.org> 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
>
>
> "smtpd_tls_auth_only = yes?
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.
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
- I'm waiting for the one user - and there's always one) to tell me
their client has stopped working.
Cheers
Simon
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.
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
> Is "smtpd_enforce_tls=yes" a suitable replacement/substitute for
> "smtpd_tls_auth_only = yes?
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.