exchange 2007 certificates conflict causingf errors to clients

We created a self signed certificate with PO, Smtp, and Imap to allow internal users to send and receive trusted e-mail. After installing, the OWA users started getting an error "Server not reachable". We created another certificate with IIS option and the OWA started working but the internal outlook clients kept getting a connection error and the request to install certificate. Doing so does not correct the issue and warnings plague the users every few minutes or when they send and email.
wlasnerDirector, ITAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Mahmoud SabrySenior IT Systems EngineerCommented:
You can use the same certificate for all exchange services iis, imap, pop3 and smtp

U should use public certificate trusted publicly or use local CA that is trusted by all ur clients
Will SzymkowskiSenior Solution ArchitectCommented:
I would agree that a 3rd party SSL cert would be best, however it is not required. the things you need to consider are the following...
- did you enable the new certificate (Enable-ExchangeCertificate)
- does the names in the certificate correspond with the server name it is running on
- have you made sure that your are using the same FQDN for for your virtual directories

Those are the 3 main things you have to consider to ensure that the certificate will work properly.

Jamie McKillopIT ManagerCommented:

Are you using Outlook Anywhere? If so, you must have a valid commercial SSL cert. You cannot use a self-signed cert with Outlook Anywhere.

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

wlasnerDirector, ITAuthor Commented:
We are doing all that but we keep getting the following popup
Image00006.bmp Image00007.bmp
MASEE Solution Guide - Technical Dept HeadCommented:
As suggested above please buy a 3rd party certificate and install it.
Then follow this article to fix the errors
wlasnerDirector, ITAuthor Commented:
OK, ordered new certificate and looking into changing the server to use FQDN. will get back with update soon.
thank you
Just for clarification.
You can use any certificate, but there are some advantages and disadvantages.

The exchange default is a self signed certificate. The problem is, that the clients are no aware about this cert so the clients need the cert in their local store, You have to distribute it.
If the certificate is expired, you have to create a new one ad distribute it again.

Next step would be to create your own PKI (Windows certificate services). There you can create a webserver template and create your own exchange certificates. With policies you can advice your servers to renew them automatically, If autoenrollment is enabled via policy i.e. to distribute computer certificates for every computer, the root certificate is distributed as well.
As long as you have only company users, you can completely automatizes the process and enrollment. Just the PKI needs a little bit maintenance from time to time. and a correct setup.
But it gives you also all freedom for changes or mistakes. If something is wrong or you forgot a name, you just create a new cert.

A public certificate releases you from any maintenance of your own PKI infrastructure as the clients can resolve the cert via the internet. But you have to pay some money for the cert. And changing a public cert is mostly not so easy (means you may have to pay again).
Nevertheless it is a good idea to put the root cert chain of a public certificate into the cert store of all computers. This avoids, that the client has to resolve the cert all the time via internet.

In general public certificates are only mandatory, if you are not able to distribute your internal certificates in a way, either by autoenrollment or just via group polies. This is usually the case, if a lot of anonymous or external users want to connect to your services.
Jamie McKillopIT ManagerCommented:
You cannot use any certificate if you are using Outlook Anywhere. Outlook Anywhere will not work with a self-signed cert. Save yourself a lot of headaches and buy a commercial cert. They aren't very expensive. The time and effort you will have to go through to setup an internal certificate authority and deploy to clients isn't worth it when compared to the cost of a commercial cert. Also, you are going to run into certificate errors on systems that aren't domain joined.

wlasnerDirector, ITAuthor Commented:
We are not using outlook anywhere, just OWA via IIS. We have purchased a certificate and the issue still happens. We have a call in with MS. They too are having trouble figuring out why this is happening. OWA works fine with no errors. adding IIS to the certificate (needed for OWA) is what is causing the issue to happen. Installing the certificate without checking the IIS option (just smtp and pop, imap)  all if fine.
wlasnerDirector, ITAuthor Commented:
More info:
We stop the default website on the exchange server that allows OWA and the issue is resolved. Start default web and it is back. I don't see how the certificate itself has anything to do with the issue. Perhaps how it is used in IIS? In this case the self signed or the CA purchased produce the same results.
wlasnerDirector, ITAuthor Commented:
So now we have an error message on the lower right corner of the outlook client "Need Password" and a dialogue pop up indicating "Connecting to". When I hit cancel for that message, my outlook shows the "Need Password" again. Thankfully, mail is flowing properly with all this going on. Any ideas?
@Jamie: you can, but you are right with the headache... :-) But not the topic here...

OK, if MS has problems too....

Just to explain what happens....

The certificate
The certificate has to be a web server certificate (correct type / usage) and contains all names, which are used by the client. If you run the "Request Certificate" Wizzard from Exchange, you see what Exchange want to see inside, depended from the selected services. And this is a SAN certificate
The usual rule is to set the common alias names inside. For example....
mail.pubdomain.tld (external)
mail.locdomain.tld (if internal domain is different)
autodiscover.pubdomain.tld (external)
autodiscover.locdomain.tld (if internal domain is different)
pubdomain.tld (external)
locdomain.tld (if internal domain is different)

If you also want to use NetBIOS names, they have to added too.
If you have (and want to use) internal domain.local, you can not get a public cert for *.local
If you setup DNS as split DNS (external / internal) then you can just use the public names.

If the certificate is fine, you can import it or just put it into the local cert store for the computer.
Exchange shows this new cert and you can assign services.

Decide if you want to use https for OWA and all other web services (ECP / OAB) etc.
If you use it for one service, you should use it for all services....
Internal and external can be different, but it confuses the users sometimes to use https and other times http. With a cert you can set everything to https.

If you assign the cert to IIS service via Exchange, the wizards assigns the cert to the web server, which hosts OWA and all other services. Also some settings may be changed, i.e. enforce SSL.

Other certs, which are not used anymore should better be removed.

In this constellation, OWA should work fine. OWA needs only the URL and the cert and it should work.
Outlook may be a bit more complex as several services are included. Using the autodiscovery (what then should be in the cert as well) makes life easier. If OWA uses SLL, Outlook has do it as well.
An if you work here with a public certificates, the certificate chain should be distributed to any client.

Remove older certs, which should not be used anymore.

If this still makes trouble for any case. I would check the certificate binding with
get-exchangecertificate | fl
This shows you all cert with their associated bindings. At least the choice with any certificate problems. The thrumprints you can compare with the thrumprints inside the certs to identify them.

For the connection error above (I assume it is solved if the certs are fine), you may CTRL right click on the Outlook tray icons. In the menu you find then the Connection Status and Test Autodiscovery. This gives you a hint how outlook connects to the server and what maybe the problem.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
wlasnerDirector, ITAuthor Commented:
Bembi, thanks for the info. I recreated a self signed certificate adding auto discover and other domains as suggested. I then added the cert to trusted domains on the local machine. So far it appears the cert message is gone. But I am still getting the pop up that says "Microsoft Outlook Connecting to" and my outlook client has message at bottom left "need password". after a while this clears back to connected:MSE. If I hit cancel (only option) on the pop up, the client gets the "need password" again.
ironically, aside from the annoyance, email is working.
You may have to check the configuration of outlook (the outlook profile). As you have autodiscover in he cert now, outlook should find the correct configuration, but make sure on exchange, that all URLs point to https. Check even Outlook Anywhere configuration in exchange.

For autodiscover you need also an DNS alias name, which points to your Exchange.

It the "need password" message disappears and changes to connected, or was connected and changes to "need password", it looks like a connection problem. If outlook do not want to connect, then it is more an authentication issue. (look in to CTRL - Right Click Outlook tray icon).

The "need password" may also be connected to a secondary service. So possible the basic connection works and you get email, but the OAB is misconfigured and can not be downloaded.

On exchange (OWA; EPC and all other tabs there) make sure that you changed it to https and also take note of the authentication methods. All services should provide the same method. So if you selected integrated authentication, select it on all tabs. If you added another authentication method (i.e. basic), then make it available on all other tabs (where it is possible).

If you work with more than one cert which a service bound to it, you have to put all root certificates on the client. Otherwise one service will work, the other not.

If you are unsure about the settings in the profile, you can delete the profile and create a new one. If autodiscover is setup in the right way, outlook finds the correct configuration.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.