Now that options/connect/options/ssl has a box for editing the ciphers list, I thought I'd take a stab at seeing if an obsolete cipher is the cause of the efnet certificates being seen as invalid.

I changed the setting to show me invalid cert for approval, so when I first connected to I see an error message saying "Name is not valid or does not match server name", which I assume is because the roundrobin hostname is not also on the certificate. So I connect directly to the servername from the editbox, and it's still telling me the cert is invalid. But it no longer has the same error message about the name. This time it's just the cryptic warning "Your connection to the server is encrypted, however there is a problem with the server's security certificate."

And this same behavior is happening at all their servers that I tested, so whatever is the cause, it's probably from something they're doing that's being setup the same way at all their servers. They no longer have expired certificates, so that's not the problem.

To test whether the problem is caused by an obsolete cipher, I edited the cipher list down to only "ALL:!aNULL" and was planning to add back ciphers to the exclusion list until it was invalid again, but that didn't work, because I was never able to get the certificate seen as valid even from this simplistic setting.

So, either the cause of invalid efnet certificates is not due solely to an obsolete cipher, or the new options box is not actually updating the ciphersuite used for the SSL connection.

Another possibility is that OpenSSL eventually removes ciphers from their approved list, so even if you remove RC4 from the exclusion list, if mIRC is using an OpenSSL that was compiled with the obsolete ciphers disabled, the SSL handshake would still fail because mIRC's side of the handshake can no longer speak the old cipher's lingo.