Untrusted TLS connection established to (ISRG Root X1 not trusted) ?

[lttabdul]

Hi all, I have an issue receiving and sending emails. Setup: PMG ----> Exchange 2019 ----> Clients. I've taken a look at the logs and they say the have been delivered but the syslogs says Untrusted TLS connection established to (172.16.0.20) which is the Exchange server.

 

[Stoiko Ivanov]

As far as I can tell from the very partial screenshot of the log-message (next time please preferably post the actual logs as text if at all possible)

The log-message seems just to say that postfix on PMG does not trust the certificate on 172.16.0.20 - with SMTP this is (sadly) quite common, since many mail-servers (especially internal ones) do not have publicly trusted certificates.

It should not prevent mails from being sent to the smtp-server on 172.16.0.20 (in the default configuration)

I hope this helps!

 

[lttabdul]

As far as I can tell from the very partial screenshot of the log-message (next time please preferably post the actual logs as text if at all possible)

The log-message seems just to say that postfix on PMG does not trust the certificate on 172.16.0.20 - with SMTP this is (sadly) quite common, since many mail-servers (especially internal ones) do not have publicly trusted certificates.

It should not prevent mails from being sent to the smtp-server on 172.16.0.20 (in the default configuration)

I hope this helps!

Hi Stoiko,

I have a trusted certificate from Let's Encrypt installed on my internal Exchange Server... not sure why it's not working

 

[treloskilo]

Maybe you can choose to have a free (if you can find) wildcard ssl certificate.

 

[Stoiko Ivanov]

I have a trusted certificate from Let's Encrypt installed on my internal Exchange Server... not sure why it's not working

could be that I misinterpreted the concrete postfix log message (as said - it's usually quite common in my experience - so I never wondered too much)

what's the output of:

openssl s_client -connect 172.16.0.20:25 -starttls smtp

(run this on the PMG command line and paste the output as text )

 

[lttabdul]

could be that I misinterpreted the concrete postfix log message (as said - it's usually quite common in my experience - so I never wondered too much)

what's the output of:

openssl s_client -connect 172.16.0.20:25 -starttls smtp

(run this on the PMG command line and paste the output as text )

Well for some reason it's using the self-signed certificate...

 

[lttabdul]

Well I do know the problem now. It's the Y22K Bug..

Source:

https://www.onmsft.com/news/fix-for-microsoft-exchange-bug-now-available

 

[das1996]

Sorry to bump an old thread.

I've read several of these now on the topic but can't seem to find a viable solution

* https://forum.proxmox.com/threads/tls-on-pmg.62975/
* https://forum.proxmox.com/threads/ssl-for-tls.82952/

Jul 24 15:02:38 pochta2 postfix/smtp[8572]: Untrusted TLS connection established to pochta.domain.com[10.10.55.10]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)

PMG (exposed to the internet) sits ahead of a mailcow server, both on the same internal subnet (for now). Both have valid and current LE certs as per the openssl command line in post 5. Note, when testing i'm using the hostname (pochta.domain.com), not the ip.

Cert for pochta.domain.com was generated using dns challenge.

By all accounts pmg should be indicating its connection is trusted, but log indicates otherwise. The only thing I can think of is it's ip (pochta) gets resolved to a private ip and not public. Should this matter?

During testing, I configured an external transport (my cpanel based webhost which can also handle email) to forward received mail to. PMG connections to it are indeed "Trusted".

 

[das1996]

^^^ FIXED

Apparently I wasn't reading the openssl output properly.

Turns out script used to update the mailcow LE certs was only acting on the nginx container and not on postfix/dovecot. Getting that fixed involved figuring out what paths were used in the script vs where postfix/dovecot was expecting to find the necessary certs.

Also (correct or not), pointed postfix/dovecot at the fullchain.pem rather than just the cert.pem. I think it has something to do with the cacertificates.crt file used in that (postfix/dovecot) docker container and how the stock acme client handles intermediate certs. Either way, outside the scope of PMG as its not a PMG issue.

 

[kentur]

^^^ FIXED

Apparently I wasn't reading the openssl output properly.

Turns out script used to update the mailcow LE certs was only acting on the nginx container and not on postfix/dovecot. Getting that fixed involved figuring out what paths were used in the script vs where postfix/dovecot was expecting to find the necessary certs.

Also (correct or not), pointed postfix/dovecot at the fullchain.pem rather than just the cert.pem. I think it has something to do with the cacertificates.crt file used in that (postfix/dovecot) docker container and how the stock acme client handles intermediate certs. Either way, outside the scope of PMG as its not a PMG issue.

Just to add to this, for others.

Untrusted TLS, means it still connects with TLS, just that the host uses a cert, not verifiable via the cacertificates.crt file.
It's still TLS and thus encrypted though.

You will see this often when you get/send emails via electric.net for example.

Trusted TLS means that the certificate has been verified with CA/cacertificates.crt.

Both are still using TLS.