Mailing List Archive

On Sat, Oct 07, 2023 at 04:10:24PM -0700, AC via Exim-users wrote:

> The internal hosts are running self-signed certificates. So is there
> a way to either make the self-signed certificates acceptable to the
> main Exim server or otherwise disable the use of TLS by either the
> internal servers or configuring the main server to not advertise TLS
> to the internal hosts?

tls_advertise_hosts main config option should answer the second half
of your question. I don't quite understand the first half, though.
Why does your main server care about the client's certificates? Do
you set tls_verify_hosts or tls_try_verify_hosts? By default these
options are unset, so client certificate signatures don't matter.

Is it possible that the messages are caused by something else than
missing signature verification? Can you show the exact error messages?

--
Ian

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-10-07 18:55, Ian Z via Exim-users wrote:
> On Sat, Oct 07, 2023 at 04:10:24PM -0700, AC via Exim-users wrote:
>
>> The internal hosts are running self-signed certificates. So is there
>> a way to either make the self-signed certificates acceptable to the
>> main Exim server or otherwise disable the use of TLS by either the
>> internal servers or configuring the main server to not advertise TLS
>> to the internal hosts?
>
> tls_advertise_hosts main config option should answer the second half
> of your question. I don't quite understand the first half, though.
> Why does your main server care about the client's certificates? Do
> you set tls_verify_hosts or tls_try_verify_hosts? By default these
> options are unset, so client certificate signatures don't matter.
>
> Is it possible that the messages are caused by something else than
> missing signature verification? Can you show the exact error messages?
>

The error message on the main server is:
TLS error on connection from [host] (recv): A TLS fatal alert has been
received.: Certificate is bad

These are the related settings according to -bP

tls_advertise_hosts = *
tls_try_verify_hosts =
tls_verify_certificates = ${if
exists{/etc/ssl/certs/ca-certificates.crt}{/etc/ssl/certs/ca-certificates.crt}{/dev/null}}
tls_verify_hosts =

I have the advertise set to * for incoming mail from the public side but
the rest are empty. How would I alter this to not advertise TLS to the
internal hosts and still advertise to all other hosts?

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Sat, Oct 07, 2023 at 08:52:24PM -0700, AC via Exim-users wrote:

> The error message on the main server is:
> TLS error on connection from [host] (recv): A TLS fatal alert has been
> received.: Certificate is bad

You've misunderstood the message. TLS "alerts" are errors reported to
the local TLS endpoint by the remote peer endpoint (in this case the
SMTP client). So the real problem is not with the clients' self-signed
certificates, but rather that the clients are unable to verify the
server certificate.

Perhaps the clients don't have the right set of trusted CAs configured
with which to verify the server certificate. Or they know the server
under a different name than the one in the certificate.

> I have the advertise set to * for incoming mail from the public side but the
> rest are empty. How would I alter this to not advertise TLS to the internal
> hosts and still advertise to all other hosts?
>

This is not really the right question. There's no reason to disable
TLS. The better options are:

- Enable the clients to verify the server certificate validity and
matching hostname.

- Configure the client TLS settings to do TLS *without*
authentication, just ignore the server certificate and
protect the traffic against passive monitoring only.

--
Viktor.

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-10-07 21:44, Viktor Dukhovni via Exim-users wrote:
> On Sat, Oct 07, 2023 at 08:52:24PM -0700, AC via Exim-users wrote:
>
>> The error message on the main server is:
>> TLS error on connection from [host] (recv): A TLS fatal alert has been
>> received.: Certificate is bad
>
> You've misunderstood the message. TLS "alerts" are errors reported to
> the local TLS endpoint by the remote peer endpoint (in this case the
> SMTP client). So the real problem is not with the clients' self-signed
> certificates, but rather that the clients are unable to verify the
> server certificate.
>
> Perhaps the clients don't have the right set of trusted CAs configured
> with which to verify the server certificate. Or they know the server
> under a different name than the one in the certificate.
>
>> I have the advertise set to * for incoming mail from the public side but the
>> rest are empty. How would I alter this to not advertise TLS to the internal
>> hosts and still advertise to all other hosts?
>>
>
> This is not really the right question. There's no reason to disable
> TLS. The better options are:
>
> - Enable the clients to verify the server certificate validity and
> matching hostname.
>
> - Configure the client TLS settings to do TLS *without*
> authentication, just ignore the server certificate and
> protect the traffic against passive monitoring only.
>

Technically I don't need the clients to use TLS at all, I'm not worried
about internal traffic so I'm fine with disabling that on the clients.
Which option on the client disables asking for a TLS connection?

The server is also self-signed so that would be why the clients can't
verify the certificate.

As for misunderstanding the error, perhaps it could be modified to
better explain which side is causing the message since I obviously
assumed that a message in the server logs indicated the server had a
problem absent any other identifying information.

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Sat, Oct 07, 2023 at 09:53:25PM -0700, AC via Exim-users wrote:

> As for misunderstanding the error, perhaps it could be modified to better
> explain which side is causing the message since I obviously assumed that a
> message in the server logs indicated the server had a problem absent any
> other identifying information.

Sadly, the error in question is reported from deep inside the TLS
library, and Exim would have to work hard to figure out it is reporting
a "peer" alert, and not some other TLS handshake problem.

So this is just one of those cases where the error only reveals its full
meaning to those who have some insight into the inner workings of TLS. :-(

https://www.flickr.com/photos/sluggerotoole/153603564

--
Viktor.

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 2023-10-07 22:10, Viktor Dukhovni via Exim-users wrote:
> On Sat, Oct 07, 2023 at 09:53:25PM -0700, AC via Exim-users wrote:
>
>> As for misunderstanding the error, perhaps it could be modified to better
>> explain which side is causing the message since I obviously assumed that a
>> message in the server logs indicated the server had a problem absent any
>> other identifying information.
>
> Sadly, the error in question is reported from deep inside the TLS
> library, and Exim would have to work hard to figure out it is reporting
> a "peer" alert, and not some other TLS handshake problem.
>
> So this is just one of those cases where the error only reveals its full
> meaning to those who have some insight into the inner workings of TLS. :-(
>
> https://www.flickr.com/photos/sluggerotoole/153603564
>

Ok, unfortunate but it is what it is.

As for disabling the TLS or at least disabling the server certificate
check, which parameter is handling that?

I was guessing tls_verify_certificates does that but doesn't seem to
solve the problem. I am not performing authentication this is just Exim
to Exim where the client Exim is sending mail normally to the server Exim.

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Sat, Oct 07, 2023 at 10:22:28PM -0700, AC via Exim-users wrote:
> As for disabling the TLS or at least disabling the server certificate check,
> which parameter is handling that?
>
> I was guessing tls_verify_certificates does that but doesn't seem to solve
> the problem.

Your configuration enforces check of exim's self-signed certificate against
repository from standart distribution, so this check predictable fails.
Unset tls_verify_certificates to disable certificate verification.
--
Eugene Berdnikov

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 08/10/2023 06:22, AC via Exim-users wrote:
> As for disabling the TLS or at least disabling the server certificate check, which parameter is handling that?

Have a read of the docs on the smtp transport, particularly the tls_ options,
and look at your client systems Exim configurations.
--
Cheers,
Jeremy


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

AC via Exim-users <exim-users@lists.exim.org> wrote:

> I have one primary Exim installation that is my main mail server visible
> to both the internal hosts and as a public host so TLS is enabled on it.
>
> My internal hosts are using Exim in smarthost mode to handle sending
> daemon mail to the main server. All of this is working fine, I just get
> messages in the logs about TLS fatal alerts because the certificate is bad.
>
> The internal hosts are running self-signed certificates. So is there a
> way to either make the self-signed certificates acceptable to the main
> Exim server or otherwise disable the use of TLS by either the internal
> servers or configuring the main server to not advertise TLS to the
> internal hosts?
>
> The only real reason to do this is cosmetic so that I don't get the
> error alerts triggering log monitoring.
>


Consider looking into the certificate comments at READING.Debian.gz. In
case you are not running a Debian derivative, you might search for it on
the web.

openssl-s_client and openssl-s_server, as well as swaks, are useful for
debugging.

Making the whole system treats self signed certificates in the same manner
as it treats other certificate authorities is distribution dependent.

--
u34


> --
> ## subscription configuration (requires account):
> ## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
> ## unsubscribe (doesn't require an account):
> ## exim-users-unsubscribe@lists.exim.org
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

u34--- via Exim-users <exim-users@lists.exim.org> wrote:

> AC via Exim-users <exim-users@lists.exim.org> wrote:
>
> > I have one primary Exim installation that is my main mail server visible
> > to both the internal hosts and as a public host so TLS is enabled on it.
> >
> > My internal hosts are using Exim in smarthost mode to handle sending
> > daemon mail to the main server. All of this is working fine, I just get
> > messages in the logs about TLS fatal alerts because the certificate is bad.
> >
> > The internal hosts are running self-signed certificates. So is there a
> > way to either make the self-signed certificates acceptable to the main
> > Exim server or otherwise disable the use of TLS by either the internal
> > servers or configuring the main server to not advertise TLS to the
> > internal hosts?
> >
> > The only real reason to do this is cosmetic so that I don't get the
> > error alerts triggering log monitoring.
> >
>
>
> Consider looking into the certificate comments at READING.Debian.gz. In

Fix
README.Debian.org
not READING.
An old version is at
https://sources.debian.org/src/exim4/4.50-8sarge2/debian/README.Debian/
A newer one, which is an xml file, is at
https://sources.debian.org/src/exim4/4.97~RC1-2/debian/README.Debian.xml/

A biger fix is that all of that refers to the Debian configuration file,
which seems hard to find when not at a Debian derived system.

--
u34

> case you are not running a Debian derivative, you might search for it on
> the web.
>
> openssl-s_client and openssl-s_server, as well as swaks, are useful for
> debugging.
>
> Making the whole system treats self signed certificates in the same manner
> as it treats other certificate authorities is distribution dependent.
>
> --
> u34
>
>
> > --
> > ## subscription configuration (requires account):
> > ## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
> > ## unsubscribe (doesn't require an account):
> > ## exim-users-unsubscribe@lists.exim.org
> > ## Exim details at http://www.exim.org/
> > ## Please use the Wiki with this list - http://wiki.exim.org/
>
> --
> ## subscription configuration (requires account):
> ## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
> ## unsubscribe (doesn't require an account):
> ## exim-users-unsubscribe@lists.exim.org
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

D?a 8. októbra 2023 13:53:31 UTC používate? u34--- via Exim-users <exim-users@lists.exim.org> napísal:

>Making the whole system treats self signed certificates in the same manner
>as it treats other certificate authorities is distribution dependent.

Self signed certificate is basically CA root certificate directly used
by server. To other systems (clients) can trust it, one just need to
add it into system's or client's trusted CAs storage. That is not hard,
but yes OS/distro depended (and eg. hard to impossible on
Android). The pain part is to mantain that certificate across
multiple clients/hosts after renew.

Using self-signed certificate is good mostly for testing, or for
(very) small amount of hosts. I use own CA for local infrastructure,
that is the same work to deploy, except that CA cert has longer
expiration time, thus happens less often (and i have automated
that).

On debian, recent versions enabled verifying peer certificate by
default for smarthost transport (i am not sure if for dnslookup too).
There is macro defined for that, which defaults to * (all hosts).
Just define that macro with exclusion of your smarthost, eg.

THAT_MACRO = ! your.smarthost

You can use IP, of course. I cannot copy/paste now, thus find
proper macro name by self.

regards


--
Slavko
https://www.slavino.sk/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/