Windows Server 2012 R2 Standart TLS errors | MDaemon Technologies, Ltd.

Windows Server 2012 R2 Standart TLS errors


  • We have encountered a problem connecting the client to the MDaemon mail server. After some checks, we found out that the problem is probably not only or not so much on the MDaemon side. When a connection problem occurs, there are no records of these problems in the Mdaemon logs, and there are errors in the Windows Server 2012 log on which MDaemon is installed, which, in our opinion, cause this problem.
    Clients who periodically receive a connection error:

    1. Mozilla Thunderbird:
    Failed to connect to the IMAP server. You may have exceeded the limit on the maximum number of connections to this server. If this is the case, open the Advanced IMAP Server Settings dialog box and reduce the number of cached connections.

    2. 1C Enterprise 8: ERP:
    Couldn't connect to help mail@*********. com for the reason:
    There was an error connecting to the server when working with IMAP. Error code: 43 Error setting up a secure SSL/TLS connection.

    At the same time, in the Window event log:
    A fatal error notification has been received from the remote endpoint. The fatal error notification code defined in the TLS protocol is 46.

    The errors have been translated into English by machine translation.
    Operating System: Windows Server 2012 R2 Standart
    All updates from the Update Center are installed.
    Mdaemon: v23.5.3

    We need any help in solving this issue.



  • Are you using the dedicated IMAP SSL Port, 993, or the standard IMAP port 143?

    Are there any issues with the certificate that MDaemon is using?  

    Is it a self signed certificate? 

    According to this page, error 46 means the certificate is unknown.

    https://learn.microsoft.com/en-us/windows/win32/secauthn/schannel-error-codes-for-tls-and-ssl-alerts

    Which MDaemon logs have you searched for the connections?  Make sure you are checking all of the MDaemon logs for the IP address the connection is coming from.  If MDaemon is blocking connections from an IP address, you won't see the connection in the IMAP log. 


  • Are you using the dedicated IMAP SSL Port, 993, or the standard IMAP port 143?

    I will clarify this information

    Are there any issues with the certificate that MDaemon is using?  

    error 46 does not always occur. No other obvious problems were found.

    Is it a self signed certificate? 

    Valid GlobalSign nv-sa certificate

    Which MDaemon logs have you searched for the connections?  Make sure you are checking all of the MDaemon logs for the IP address the connection is coming from.  If MDaemon is blocking connections from an IP address, you won't see the connection in the IMAP log.

    I'm looking at the MDaemon-2024-05-22-all.log


  • Check the DynScrn log file.   

    Also make sure that logging refused connections and bloc list hists are enabled under Security / Dynamic Screening / Options|Customize.

     


  • @Arron, Addresses that receive error data are included in the Dynamic Allow List Dynamic Screening.


  • @Arron Are you using the dedicated IMAP SSL Port, 993, or the standard IMAP port 143?

    Port 993 is used. Are there any other ideas to solve this problem?


  • If you change it to use port 143 and STARTTLS, do you have the same issue?  

    If you leave the port set to 143 and turn off the encryption, do you have the same issue?  Once the test is over, I reccomend changing the client back to using an encrypted session.


  • @Arron, When switching to port 143 and STARTTLS, connection errors no longer occur in the above application. However, they continue to be recorded in the Windows log, most likely from other clients, which is very difficult to track, since the client IDs (IP address or computer name) are not specified in the log.


  • The IMAP server's SSL/TLS code is the same, whether it's done immediately when the session starts or after the STARTTLS command.  The fact that it works when you switch to using STARTTLS is odd.  

    Are there any errors logged in the windows event log on the client machine?

    Does the error occur all the time, or only when the server is busy?

    How many active IMAP sessions are running when the error occurs?

    How many active IMAP sessions are you allowing on the server? (In MDaemon go to Setup / Server Settings / Sessions / Maximum concurrent IMAP sessions)


  • @Arron ,

    Are there any errors logged in the windows event log on the client machine?

    There are no errors in the Windows server event log with 1C Enterprise 8: ERP, and when using 993 SSL/TLS ports and 143 STARTTLS ports

    Does the error occur all the time, or only when the server is busy?

    The server does not return an error that it is busy

    How many active IMAP sessions are running when the error occurs?

    How many active IMAP sessions are you allowing on the server? (In MDaemon go to Setup / Server Settings / Sessions / Maximum concurrent IMAP sessions)

    Attached screenshots

    According to the Windows Event log, it is impossible to understand who is accessing the server that causes the error


  • If you change all the clients to use port 143 with STARTTLS, does the issue go away competely?

    Are all windows updates installed for the OS?


  • @Arron 

    If you change all the clients to use port 143 with STARTTLS, does the issue go away completely?

    There are more than 500 clients and it is long and difficult to transfer all of them to port 143, and there is also a question of the security of such a setup.

    Are all windows updates installed for the OS? 

    No new updates were found when checking for Windows Server 2012.


  • There are more than 500 clients and it is long and difficult to transfer all of them to port 143,

    That is understandable. 

    Can you capture the IMAP traffic on the server when the issue occurs using a tool such as WireShark and send it to us along with the IP address of the client having the issue and the IP address of the server?  The network capture will allow us to look at the data being sent between the client and server for the SSL/TLS handshake.  It may offer some clues as to why the certificate is reported as unknown some of the time. 

    Once you have captured the traffice that includes the issue, you can upload the capture to https://mdaemon.sharefile.com/r-rc3922c1eed334d4dbf5e34f0bd04ccd6

    all of them to port 143, and there is also a question of the security of such a setup.

    Port 143 using STARTTLS offers the same level of security as port 993. Both options encrypt the IMAP traffic.  If you do not force the use of STARTTLS on port 143, then it is not secure.

     


Please login to reply this topic!