I chattted with verisign and they gave me the correct intermediate and root certificates , I loaded these into key chain, the next time I opened entourage there was a message to always allow the certificate into my key chain, problem solved…….finally

Since you are getting mail, I’m assuming the error pops sometime during Entourage’s being open. This is almost certainly a directory lookup error.

You can verify this, by opening Entourage and selecting new mail message. Then in the drop down, select Global Address Book. If you get the message, than you are defientaly expierncing an LDAP look up issue.

What makes this whole process a pain, is the myriad of combinations that exist and the requirement that your settings match your companies. They will only communicate with your system if you present to them as expected. This causes some very misleading error messages.

For instance, if you uncheck SSL and your system admins have selected “SSL required” on the iis server – then you may be presented with a dialog saying “could not establish a secure connection.” In reality, the error could be:

a) “Your trying to communicate on a non-secure channel, and SSL security is required to talk to this server.”
b) “Your system does not appear to be a computer this server wants to talk to securely”
c) “The server you are connecting to cannot talk to this computer securely”
d) “The server (or computer) is not who they say they are”

In your case, I would imagine there is going to be an incompatiblity with your corporate structure and Entourage. If your system ADMINs have require communiation to the LDAP server to be SSL, and they don’t have an external certificate for communciating with the LDAP server. You will not be able to avoid this.

The LDAP server’s certificate must match what you are putting in for a name in the LDAP Server box under the Directory Services>Advanced Tab.

If you can, ask an ADMIN this.

1) Is it possible to contact the Global Address Book/LDAP server external, and if so..
2) Is it standard SSL
3) What is the exact FDQN the machine is certifcated for.

As a work around, you might try removing any server names from the LDAP server box. That way no attempt is made to contact it.

Thanks for the reply! I have both unchecked SSL settings for the LDAP and Exchange server. The Exchange Server is 2007.

I didn’t make it very clear, “onyx.local” is simply the DNS suffix at work. My connection address is a FQDN, I’ve never used the .local address in Entourage: My connection is set to smtp.XXXX.com (XXXX just for privacy). If I want to use OWA, I can connect to http://smtp.XXXX.com/owa without problems.

Also, I actually get and can send the mail without issue, it’s just the error that’s bothersome

Thanks for the help so far!

-C

Couple of questions:

1) Are you unchecking the LDAP SSL or the mail server?
2) What version is your Exchange server 2000, 2003, 2007?

Regardless, you’ll need to obtain an external connection address to use. The .local address is what most companies use for machine addresses behind a firewall (or InTRAnet).

For instance, at our office, internally we connect to “xch.domain.local.” However, when connecting externally through the inTERnet, then the address is “mail.domain.com.” This is all setup by an Admin.

If you have webmail, try that address. But it will definetaly require a FQDN (not a .local)

Does that help?

Regardless if the SSL option is checked, if I am outside my organization, I get the error “Unable to establish a secure connection to rim.onyx.local.CONNECTION because the server name…” where CONNECTION is my connection wherever I am (i.e.: rim.onyx.local.hsd1.ga.comcast.net). Note: onyx.local is my work domain. I have no clue what part RIM plays… I don’t use BlackBerry, and I don’t *think* we have a full-fledged BlackBerry server. I think we just connect to exchange.

If I am in the office, where onyx.local is my connection, there is no problem.

-C

all up-to-date
settings corret
selfsigned sbs cert

but nada. outlook works so much better.. ms you greedy farts..lol

Our error was caused by the LDAP lookup on the Exchange GAL (Global Address List) look-up. The check box for SSL LDAP was enabled. Unfortunately, the server name did not match the certificate, because the hardware firewall routed LDAP to the domain controller. So, the solution would be to use a different HOST name for internet DNS resolution to a machine with the correct certificate.

After correcting this, the above worked. Entrouage does function without the certificate error now. You can test this by unchecking secure LDAP function on the tab of your Exchange account. Passwords and email are still encrypted.

Hope that helps!