MTA-STS failure for outlook.com: Certificate no... | MDaemon Technologies Community Forum
  1. Forum
  2. MDaemon
  3. MTA-STS failure for outlook.com: Certificate not trusted (CERT_E_UNTRUSTEDROOT)

MTA-STS failure for outlook.com: Certificate not trusted (CERT_E_UNTRUSTEDROOT)

  • R

    Hi 

    I have been trying to get our email working with Gmail / Outlook etc for a bit now, just struggling with the certificate now.

    Created a Lets Encrpyt cert but getting an error of "MTA-STS failure for outlook.com: Certificate not trusted (CERT_E_UNTRUSTEDROOT)

    Will MDaemon not work with the Lets Encrypt cert ?

     

    Thanks 

    0 likes
  • A

    MDaemon should work correctly with a LetsEncrypt certificate.   When is this error occurring?  Is this occurring when MDaemon is trying to send to a domain or when that domain is trying to send to your MDaemon?

    What do the MDaemon logs show is happening?  

    If this is happening when domains are trying to send to you, what do you have in your MTA policy file?  Does your certificate support using mta-sts.domain.com?

     

    --
    Arron Caruth

    0 likes
  • R

    Arron

    Thanks for the reply

    Its only occurring when sending to outlook/gmail accounts and getting a cert error, is this the lets encrypt cert or the domain one (which you have me thinking it may be) for the MTA-STS file

     

    Current MTA-STS 

    version: STSv1
mode: testing
mx: domain.co.uk
mx: mail.domain.co.uk
max_age: 604800

    Mon 2023-11-20 16:23:37.736: --> STARTTLS
    Mon 2023-11-20 16:23:39.098: <-- 220 Ready to start TLS
    Mon 2023-11-20 16:23:39.266: SSL negotiation successful (TLS 1.2, 255 bit key exchange, 256 bit AES encryption)
    Mon 2023-11-20 16:23:39.278: SSL certificate is not valid (not signed by recognized CA)

    0 likes
  • A

    The log snippet you provided is when negotiating an SSL session.  Is that an inbound or outbound SMTP session?  Please provide a larger snippet of the log so that we can see what is happening.

    Do you have a log snippet that shows the errors with MTA-STS?

    What operating system are you using?  Have all the windows updates been installed?

    Are the CAs all updated?

    Is your certificate expired?  Does it include mta-sts.yourdomain.com as a valid host name? 

    When you connect to webmail using HTTPS does the browser give you an error about the certificate?

    --
    Arron Caruth

    0 likes
  • R

    Aaron

     

    Sorry for the Delay, 

    SMTP out log shows

    Sun 2023-11-26 11:31:32.105: SSL negotiation successful (TLS 1.2, 255 bit key exchange, 256 bit AES encryption)
    Sun 2023-11-26 11:31:32.106: SSL certificate is not valid (not signed by recognized CA)
    Sun 2023-11-26 11:31:32.106: MTA-STS failure for gmail.com: Certificate not trusted (CERT_E_UNTRUSTEDROOT)
    Sun 2023-11-26 11:31:32.106: --> QUIT

    Operating system is Windows Server 2016 full updated

    All CAs are showing ok

    Certificate is a Lets Encrypt, been on there community but getting passed around as people are saying its not there product so they cant offer much help which is understandable.

    Dont get an error connecting to webmail using HTTPS.

    Never relised how many companys we deal with use Gmail for their email, its only Gmail and outlook we have noticed a problem with, just sent a test email to domain-test@mdaemon and its flgged allsorts. Maybe its time to move on as we need to be able to email people on Gmail and possibly others whom we havent noticed are not working.

     

    0 likes
  • A

    The only thing I can tell from the log snippets being provided is that the certificate being used has an untrusted root.  This is not caused by your certificate, it is the certificate being presented by gmail's servers.

    On the MDaemon server open a browser and go to https://mta-sts.gmail.com/.well-known/mta-sts.txt.  Do you get any security warnings about the certificate?  If you do the same thing for the domain you are trying to send to, replace gmail.com with the domain you are trying to send to, do you get any errors?

    You can clear data for the domains you are sending to from the MTA-STS cache by going to Security / Security Manager / SSL & TLS / SMTP Extensions.  This will help if the caches have been corrupted or have any bad data.

    You can exempt the domains you are sending to from MTA-STS by going to Security / Security Manager / SSL & TLS / SMTP Extensions / Exempt List. 

    If you are not getting errors from the browser please provide the entire session from the SMTP out log..

    --
    Arron Caruth

    0 likes
  • A

    Rich,

    Have you been able to do any further testing? 

    --
    Arron Caruth

    0 likes
  • R

    Arron,

     

    Sorry for the delay, had to take some time off 

    I have tried what you suggested above, i dont get any secuity warnings when opening https://mta-sts.nova-security.co.uk/.well-known/mta-sts.txt 

    Cleared the cache and sent a test email, and the below is whats in the SMTP out log 

     

     

    Thu 2023-12-07 08:37:13.679: REMOTE message: pd3501000005932.msg
    Thu 2023-12-07 08:37:13.679: *  Session 01683496; child 0001
    Thu 2023-12-07 08:37:13.680: *  From: office@nova-security.co.uk
    Thu 2023-12-07 08:37:13.680: *  To: ***********@gmail.com
    Thu 2023-12-07 08:37:13.680: *  Subject: Test to Gmail 
    Thu 2023-12-07 08:37:13.680: *  Message-ID: <WC20231207083710.10000A@nova-security.co.uk>
    Thu 2023-12-07 08:37:13.680: *  Size: 2548; <c:\mdaemon\queues\remote\pd3501000005932.msg>
    Thu 2023-12-07 08:37:13.725: Resolving MX record for gmail.com (DNS Server: 192.168.2.1)...
    Thu 2023-12-07 08:37:13.770: *  P=005 S=002 D=gmail.com TTL=(41) MX=[gmail-smtp-in.l.google.com]
    Thu 2023-12-07 08:37:13.770: *  P=010 S=001 D=gmail.com TTL=(41) MX=[alt1.gmail-smtp-in.l.google.com]
    Thu 2023-12-07 08:37:13.770: *  P=020 S=000 D=gmail.com TTL=(41) MX=[alt2.gmail-smtp-in.l.google.com]
    Thu 2023-12-07 08:37:13.770: *  P=030 S=004 D=gmail.com TTL=(41) MX=[alt3.gmail-smtp-in.l.google.com]
    Thu 2023-12-07 08:37:13.770: *  P=040 S=003 D=gmail.com TTL=(41) MX=[alt4.gmail-smtp-in.l.google.com]
    Thu 2023-12-07 08:37:13.770: Attempting SMTP connection to gmail-smtp-in.l.google.com
    Thu 2023-12-07 08:37:13.773: Resolving A record for gmail-smtp-in.l.google.com (DNS Server: 192.168.2.1)...
    Thu 2023-12-07 08:37:13.816: *  D=gmail-smtp-in.l.google.com TTL=(2) A=[172.253.116.26]
    Thu 2023-12-07 08:37:13.817: Attempting SMTP connection to 172.253.116.26:25
    Thu 2023-12-07 08:37:13.818: Waiting for socket connection...
    Thu 2023-12-07 08:37:13.820: *  Connection established 192.168.2.50:58475 --> 172.253.116.26:25
    Thu 2023-12-07 08:37:13.820: Waiting for protocol to start...
    Thu 2023-12-07 08:37:13.951: <-- 220 mx.google.com ESMTP Service ready
    Thu 2023-12-07 08:37:13.953: --> EHLO mail.nova-security.co.uk
    Thu 2023-12-07 08:37:14.016: <-- 250-Requested mail action okay, completed
    Thu 2023-12-07 08:37:14.016: <-- 250-SIZE 40000000
    Thu 2023-12-07 08:37:14.016: <-- 250-8BITMIME
    Thu 2023-12-07 08:37:14.016: <-- 250-STARTTLS
    Thu 2023-12-07 08:37:14.016: <-- 250 OK
    Thu 2023-12-07 08:37:14.016: --> STARTTLS
    Thu 2023-12-07 08:37:14.313: <-- 220 Ready to start TLS
    Thu 2023-12-07 08:37:14.478: SSL negotiation successful (TLS 1.2, 255 bit key exchange, 256 bit AES encryption)
    Thu 2023-12-07 08:37:14.510: SSL certificate is not valid (not signed by recognized CA)
    Thu 2023-12-07 08:37:14.511: --> EHLO mail.nova-security.co.uk
    Thu 2023-12-07 08:37:14.571: <-- 250-Requested mail action okay, completed
    Thu 2023-12-07 08:37:14.571: <-- 250-SIZE 40000000
    Thu 2023-12-07 08:37:14.571: <-- 250-8BITMIME
    Thu 2023-12-07 08:37:14.571: <-- 250 OK
    Thu 2023-12-07 08:37:14.571: --> MAIL From:<office@nova-security.co.uk> SIZE=2548
    Thu 2023-12-07 08:37:14.628: <-- 250 Requested mail action okay, completed
    Thu 2023-12-07 08:37:14.628: --> RCPT To:<**********@gmail.com>
    Thu 2023-12-07 08:37:14.746: <-- 250 Requested mail action okay, completed
    Thu 2023-12-07 08:37:14.746: --> DATA
    Thu 2023-12-07 08:37:14.802: <-- 354 Start mail input; end with <CRLF>.<CRLF>
    Thu 2023-12-07 08:37:14.802: Sending <c:\mdaemon\queues\remote\pd3501000005932.msg> to [172.253.116.26]
    Thu 2023-12-07 08:37:14.803: Transfer Complete
    Thu 2023-12-07 08:37:16.041: <-- 250 Requested mail action okay, completed
    Thu 2023-12-07 08:37:16.042: --> QUIT
    Thu 2023-12-07 08:37:16.099: <-- 221 Service closing transmission channel
    Thu 2023-12-07 08:37:16.099: SMTP session successful (Bytes in/out: 4055/3164)
    Thu 2023-12-07 08:37:16.099: ----------

    0 likes
  • A

    The error indicates that the root CA is not trusted by your server.  There are a number of different issues that could cause this.  

    The first thing I would try is going to https://www.checktls.com/TestReceiver, enter gmail.com in the email target field and select Cert Detail from the Output Format drop down.  Then click Run Test. This will show you all the certificates returned by the server when you connect. 

    When I tested it 3 certificates were returned and 1 was added from the CA Root Store.  Does it show any errors when checking the certificates?

    Does your server trust google's root CA?  If you open Certificate manager for the local computer and go to Trusted Root Certification Authorities \ Certificates, you should have a certficiate issued to GTS Root R1.

    I'm guessing that it is listed.  If it were not listed, you should get a certificate error when opening a browser and going to https://mta-sts.gmail.com/.well-known/mta-sts.txt. 

    So then the next thing I'd check is what user the MDaemon service is running as.  If its not running as localsystem, make sure the account its running as is an administrator on the machine.   If you are still having the issue, please try setting the service to run as localsystem and see if the error still occurs.

     

    --
    Arron Caruth

    0 likes
  • R

    Running https://www.checktls.com/TestReceiver works fine on my laptop connected to the same network as my sever but running it directly from the server the page hangs at the same place and fils to run completly. Fault to do with this machine?

    Going to  https://mta-sts.gmail.com/.well-known/mta-sts.txt.  works fine.

    MDaemon is running as a local service 

    0 likes
  • A

    I believe the fault specific to your environment, but since we haven't found the actual cause, I don't know for sure.  I would expect if the fault were not specific to your environment that others would be having the same issue and I would be able to reproduce it.  

    Running the tests on https://www.checktls.com/TestReceiver from your laptop vs running it from the MDaemon server shouldn't be any different.  The connection and tests are being done by the website, not the browser. 

    Just to clarify, since my instructions were not specific, going to https://mta-sts.gmail.com/.well-known/mta-sts.txt from a browser on the MDaemon server, does not return errors correct?  When this page is open in the browser, if you inspect the certificate and look at the hierarchy, what does it show as the base certificate?   

    What browser are you using?  Do you get the same results with Edge?

    If none of my questions above help to identify the issue, we are going to need to capture the network traffic using WireShark.  This will allow us to see more details during the TLS negotiations.  You'll need to download and intall WireShark on the MDaemon server.  Then start a capture, and send a test.  Once MDaemon has sent the email, stop the capture, save the file and send it to me privately.  Please leave the capture running for as short of a time as possible and make sure it is capturing the outbound traffic from MDaemon.  If you have multiple network interfaces you have to make sure you are capturing traffic from the correct one.

    You can upload the capture using this link, https://mdaemon.sharefile.com/r-r77d4332c21ab4a28afe9e84ea94e2f3c

    Please let me know the name of the file you uploaded.

     

     

    --
    Arron Caruth

    0 likes
  • R

    @Arron 

    Tried Opera, Edge and chrome broswer all the same

    Will see what wireshark shows

     

     

    0 likes
  • R

    Arron

    Something has changed, now all of a sudden i have been able to send a email to Gmail but its been marked as spam, yet yesterday their servers wouldnt accept anything

     

    Wire shark file is named "MDaemon Wireshark Gmail"

    0 likes
  • A

    Can you post the outbound SMTP session that MDaemon logged while the capture was running?

    --
    Arron Caruth

    0 likes
  • A

    The certificate being returned to MDaemon is from your Watchguard device, not from google.  If you configure the WatchGuard device to not intercept traffic on port 25, do you have the same issue with the CA not being trusted?  

    You could also add the CA being returned by WatchGuard to the Trusted Root Certificate Authorities in Windows.  

     

    --
    Arron Caruth

    0 likes
  • R

    Aaron 

    Thanks for the reply, due to Christmas and other commitments had to put this to one side 

    still having issues and it's just been mentioned that we can't receive some emails which I have just looked in to and yes the bank and hive heating can't send a email to us. I had thought the problems we were having was just outgoing but it's looking like it's both ways.

    anybody recommend somebody in the UK who knows what they are doing.

     

    getting this a lot now 

    This is an email authentication failure report for an email message received from 54.240.4.21 on Thu, 11 Jan 2024 16:36:35 +0000.

    RFC 6591 states that "A single [auth-failure] report describes a single email authentication failure.  Multiple reports MAY be used to report multiple failures for a single message".  There may be other ways in which this same message failed to authenticate. If so, you may receive additional separate reports.

    RFC 6591 is not comprehensive in its instruction on how to report the reasons for DKIM authentication failures.  Therefore, "other" may be used in the "Auth-Failure" field below for a host of possible reasons that are not covered by RFC 6591.

    The original message headers follow at the end of this report.

     

    0 likes
  • A

    Were you able to adjust your WatchGuard device so that it doesn't insert its certificate in the SMTP traffic?

    When you are unable to receive a message, what does MDaemon's SMTP in log show is happening?  What does the sending server log show is happening?

    When you are unable to send a message, what does MDaemon's SMTP log show is happening? 

    We'll need to see the whole SMTP session for inbound and outbound issues.

    Regarding the email authenticaiton failure report, my first thought was that you had your DMARC policy setup to send authentication failure reports for your domain, but it doesn't look like you have DMARC policy at all (You should consider creating one).  My second thought is that you have MDaemon configured to send failure reports and send you a copy. In MDaemon under Security / Security Settings / Sender Authentication / DMARC reporting, do you have the box checked for "Send DMARC failure reports"?  And do you have an address specified for "Email a copy of all reports to?"

    If you do, and the reports you are receiving are coming from your own server, then remove the address from "email a copy of all reports to".

    If you don't want MDaemon to send out DMARC failure reports, uncheck the box.

    If the message was not generated by MDaemon, In the original message headers, who is the message from?  Who is the message to? 54.240.4.21 is an Amazon mail server.  Are they sending mail on your behalf?

    We have a distributor in the UK that is very good and they can assist if you'd like, https://www.zensoftware.co.uk/mdaemon

    --
    Arron Caruth

    0 likes
Please login to reply to this topic!

Participants