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:
LocalSite : Default-First-Site-Name
SecureAccess : False
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
IsValid : True
ObjectState : New
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.
- 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.
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.