So, you’ve just disabled the SSLv3.0 and TLSv1.0 protocols to pass your PCI Compliance scan, and now Outlook won’t connect? Well, there’s a reason for that, but I can tell you how to fix it with minimal effort and without affecting your PCI compliance…
First off, I’ve only tested this on Outlook 2013 connecting via IMAP or POP to an Apache 2.2.29 server running Dovecot 2.2.16. Though that shouldn’t make a difference, YMMV (especially if connecting to IIS/Exchange).
FYI, to see what version of Dovecot you’re running, you can run this command at a terminal prompt:
/usr/sbin/dovecot --version
The problem apparently lies with Outlook’s interaction with Windows, and not in Outlook itself. (Mozilla’s Thunderbird actually works fine connecting to IMAP/POP via TLS1.1/1.2 (using STARTTLS) out of the box (even on WinXP!), but at the time of this writing it has a bug in it that won’t allow you to import your data from Outlook, which at least for now, probably makes switching from Outlook to Thunderbird not an option.)
If you’re running Windows Server 2008 R2, or Windows 7, or newer, Outlook will connect via TLS 1.1/1.2 with a registry tweak.
On the client machine with Outlook on it, check this registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols
Under the Protocols key, add two new keys, if not already there: One called “TLS 1.1” and one called “TLS 1.2“.
Inside both of these keys, add another key called “Client“.
Now create a DWORD value in each Client key called “DisabledByDefault” whose value is 00000000.
Now restart the computer and then relaunch Outlook. You should now be able to connect to that PCI compliant IMAP/POP server that’s only running TLSv1.1 and TLSv1.2 protocols. (That is, assuming you only disabled the SSLv3.0 & TLSv1.0 protocols themselves, and not their associated ciphers too when trying to pass certification! (You don’t want or need to do this, because TLSv1.1 uses the same ciphers as SSLv3.0, so disabling SSLv3.0 ciphers renders TLSv1.1 useless, and it doesn’t help your PCI compliance. (See my recent post about how to pass PCI certification for more.)))
Alternatively, if you didn’t want to do this, or for some reason it didn’t work for you, but you want to keep your PCI compliance, you can always “dispute” it (possibly will need to also submit a mitigation document), which would buy you another year or so before you’d HAVE to shut off the TLSv1.0 protocol, with the hope that by then, Microsoft will release an official fix for this.