Updated: OS X BUG – Formerly Communicator Bug

UPDATED: Check out the comments for where the bug really lies.

I have checked the “Always Trust” checkbox on this window EVERY time I have launched this app. Yet, it really doesn’t think I trust it. Thanks Microsoft!

2 thoughts on “Updated: OS X BUG – Formerly Communicator Bug

  1. From the Apple forum:

    I’m sure I’ll take “fanboi” grief for pointing out that this is actually not MS at fault here 🙂

    AppleCare has told me that it is by design and according to the specifications that Mail.app refuses to honor the checkbox to trust a mismatched certificate for a selected account without express approval each time Mail is run. Apparently the checkbox is only put in for certificates which match but don’t resolve to a recognized Certificate Authority. But not only won’t it honor a mismatched certificate, but it won’t honor a wildcard certificate, such as a certificate for “*.mail.dreamhost.com” associated with an account being accessed through the server “a1.balanced.blingy.mail.dreamhost.com”.

  2. I work with slipsec so I approved his comment 😉

    I attempted to do the always trust option described in the support forum in the keychain, it still gives me the finger.

    The real solution here is going to be DNS. You see, lightedge.com and my.lightedge.com are hosted on the same server and it is using named based virtual hosting so if you look up the IP address of lightedge.com, you get:

    Name: lightedge.com

    For my.lightedge.com:

    my.lightedge.com canonical name = leweb.lightedge.com.
    Name: leweb.lightedge.com

    So when communicator goes to port 443, it gets the certificate for My.lightedge.com instead of an SSL for lightedge.com. We don’t require SSL for ligthedge.com so there is no reason to have it.

    The solution, move my.lightedge.com to its own IP.

    So, I stand corrected, this is not a M$ bug. Its a “feature” apparently of the SSL security in OS X.

    I still hate it.

Comments are closed.