Monday, March 26, 2018

Binding a Certificate breaks IMAP or POP on Exchange - NO LOGIN failed error

A customer of mine running Exchange 2013 CU17 went to renew the Exchange Certificate after it expired.  The customer even though they were not using secure IMAP bound the new certificate to IMAP, POP and IIS.

The customer has a line of business application which uses unsecured PlainTextLogin on the internal network to a single mailbox to receive invoices and email traffic.  When using PlainTextLogin without encryption you want to ensure this is not exposed to the Internet.  In my case, my customer did not have IMAP directly exposed to the Internet and was kept secure.

The following screenshot shows the new certificate installed on the Exchange server bound to IMAP and POP services.


As soon as the customer bound the certificate to POP and IMAP services, it broke IMAP.  From my reading the same symptom is also experienced for POP.

There are many forum threads on the Internet about this issue none with a resolution.  For example:
  • https://social.technet.microsoft.com/Forums/exchange/en-US/b14005e4-6416-463b-91db-a4f14620c9f2/imap-connection-failure-no-login-failed-proxynotauthenticated?forum=exchangesvrclients
  • https://www.experts-exchange.com/questions/28162501/Exchange-2013-IMAP-authentication-fails.html
  • https://confluence.atlassian.com/jirakb/unable-to-authenticate-against-microsoft-exchange-imap-server-after-upgrade-jira-376839181.html
  • https://serverfault.com/questions/760417/imap-issue-proxynotauthenticated
  • https://community.spiceworks.com/topic/1980834-exchange-2016-can-t-authenticate-with-pop-or-imap

Symptoms of the Issue

The Test-ImapConnectivity command returned the following error:

RunspaceId                  : ecef0b6b-183e-4211-929d-e046af7c062f
LocalSite                   : Default-First-Site-Name
SecureAccess                : False
VirtualDirectoryName        :
Url                         :
UrlType                     : Unknown
Port                        : 993
ConnectionType              : Ssl
ClientAccessServerShortName : Server
LocalSiteShortName          : Default-First-Site-Name
ClientAccessServer          : Server.domain.local
Scenario                    : Test IMAP4 Connectivity
ScenarioDescription         : Connect to server using IMAP4 protocol, search for the test message, and delete it along
                              with any messages that are older than 24 hours.
PerformanceCounterName      : ImapConnectivity-Latency
Result                      : Failure
Error                       : IMAP Error: aYKG NO LOGIN failed.
UserName                    : administrator
Latency                     : 00:00:00.0368441
EventType                   : Error
LatencyInMillisecondsString :
Identity                    :
IsValid                     : True
ObjectState                 : New

The IMAP4 Protocol Logs on the Exchange Server showed the following HealthMailbox error over and over again:

22T07:30:46.994Z,0000000000000003,2,127.0.0.1:993,127.0.0.1:32258,HealthMailbox1f3addd86ba64b7c84868136b32a82f9,1196,78,97,login,HealthMailbox1f3addd86ba64b7c84868136b32a82f9@DOMAIN.COM *****,"R=""z NO [Error=ProxyNotAuthenticated Proxy=EXCHANGESERVER.DOMAIN.COM:1993:SSL] LOGIN failed."";Msg=Proxy:EXCHANGESERVER.DOMAIN.COM:1993:SSL;ErrMsg=ProxyNotAuthenticated"

Microsoft Outlook clients configured using IMAP would prompt for authentication in an infinite loop despite entering the correct details.

Get-ServerHealth would return all IMAP services on the Exchange server in an unhealthy state.

When performing a Telnet to the IMAP Service using Plain Text Login I would get "NO LOGIN failed" also visible in the IMAP protocol log.



Issue Explanation

For this issue to take effect you must have two things consistent in your Exchange environment.
  1. You must be using PlainTextLogin instead of SecureLogin
  2. You must have bound a custom certificate to IMAP.

Also unfortunately if you bind a custom certificate to IMAP, you cannot unbind it according to Microsoft - great feature.


https://technet.microsoft.com/en-us/library/aa997231.aspx

So how do we fix this, what happened?


The X509CertificateName should be the common name of the certificate that's enabled for IMAP.

By default the X509CertificateName is the FQDN of the server, server.domain.com (whatever it is called in your environment.

As soon as we bound the certificate to IMAP, Exchange Automatically updates the X509CertificateName to the common name of the new certificate.  Now if you have SecureLogin enabled, this does not cause an issue.  However if your using PlainTextLogin, as soon as you bind the certificate IMAP breaks even if we are connecting to unsecured IMAP on 143 (secure IMAP is on 993).

If your using PlainTextLogin IMAP or POP must be set to reference the default "self signed certificate" generated by the Exchange installation process which matches the FQDN on the service.

To reset the IMAP service to reference the default self signed certificate, we simply need to change the X509CertificateName back to the FQDN of the server.

Set-ImapSettings -X509CertificateName ServerFQDN

After making this change restart the IMAP4 backend and frontend services.

Test again using an IMAP client or Telnet.  We can see that it now works as it is referencing the self signed issue.


Final Thoughts

In theory because the X509CertificateName matched the common name on the new certificate, and because we weren't even using secure IMAP at all, it should have worked.  It appears to be a bug in the source code around how these services were coded.

I hope this post has been helpful to other people experiencing this same issue.

No comments:

Post a Comment