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:
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 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:
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.
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.
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.
- You must be using PlainTextLogin instead of SecureLogin
- 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