Unrecognized certificate error

Our mail server name is server16C. MAIL is the alias name of server16C.

Users use mail.ourdomain.com/exchange to access OWA in and out the company.

Users don't like to use server16C.ourdomain.com/exchange for OWA access.
 
Last year, we bought SSL certificate for MAIL.OURDOMAIN.COM. It worked,
but keeping showing unrecognized certificate error.

What is the solution? Do we have to buy certificate for SERVER16C.OURDOMAIN.COM?

Networksolutions.com said we need to buy 2 certificates to solve this problem,
one is inside, the other outside. Not quite understand their idea.
LVL 1
sjacctAsked:
Who is Participating?
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.

sjacctAuthor Commented:
It is not "page contains secure and nonsecure items" warning.
0
Steve BinkCommented:
What is the exact error when you browse to http://mail.ourdomain.com?
0
INTRODUCING: WatchGuard's New MFA Solution

WatchGuard is proud to announce the launch of AuthPoint, a powerful, yet simple, Cloud-based MFA service designed to eliminate the vulnerabilities that put your data, systems, and users at risk.

sjacctAuthor Commented:
Can't remember what exact the error was. Its address bar showed pink color instead of green color.

I noticed someone mentioned aka multi-domain cert or SAN cert. Can anyone provide more info for this specific cert?

Thanks !
0
geowrianCommented:
I believe you are referring to a Unified Communicatiions Certificate (UCC). This is a bit more costly, but generally this is the simplest and supported solution for the problem you are seeing. Basically, a UCC allows you to define a primary FQDN, such as server16C.ourdomain.com, then specify alternate FQDN in the Subject Alternate Name (SAN). This makes the SSL certificate valid for those other FQDN.

We used a Comodo UCC as it is on Microsoft's official list of supported Exchange UCC CAs, but any UCC from a major CA should work. I followed the instructions here without any issue to install it:
https://support.comodo.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1143

Basically, a single standalone SSL cert is not going to work with multiple FQDNs on the same server.
0
sjacctAuthor Commented:
Thank you, geowrian!

The problem right now is no one can tell me the right name of this certificate. I have talked to all major CA sales experts. No one can tell which is the one we need and how to use it.

Is this UCC same as SAN cert? In your link, it is Exchange 2007. We are using Exchange 2003. I can't find that Exchange Management Shell on 2003.

Let me find out what is this UCC and how it works.

Thanks again.
0
geowrianCommented:
A "SAN" cert is a multi-domain cert. Actually you could use a regular multiple domain cert, a wildcard cert, or a UCC. A multi-domain cert and a UCC both work via specifying alternate FQDNs in the Subject Alternate Name (SAN) section of the SSL certificate. A wildcard cert does not use the SAN section, but allows all subdomains. I wouldn't recommend using a wildcard cert for an Exchange server, but it should be possible. A UCC or other mult-domain cert should work fine.

Generally, you want an SSL cert on an Exchange box to cover the systems with the following FQDNs (ignoring those you do not host on the server):
1) The autodiscover record (free/busy information, Out-of-Office, etc.)
2) Any POP server DNS records
3) Any IMAP server DNS records
4) Any SMTP DNS records
5) Any OWA DNS records

My mistake on the Exchange 2007 document - this is the first time I saw Exchange 2003 mentioned in the question, and it makes a huge difference. Exchange 2007 has many tools available as well as a simple PowerShell command to generate the CSR with the SANs in it. It is much more painful in Exchange 2003, unless you use a wildcard cert, which is considerably more expensive. Unfortunately, I have not done it myself in Exchange 2003, so all I can give you is what I believe will work. Basically, it uses the certreq.exe application to generate the CSR with the SANs in it, then you manually import it into IIS:

The usage of certreq is here:
http://technet.microsoft.com/en-us/library/cc736326%28WS.10%29.aspx

Once you have a CSR, send it to the CA (GeoTrust, Comodo,etc.) to get the SSL certificate. Then open mmc and add the Certificates snap-in (on the Local Computer account). Go tot he Personal certificates and import the SSL certificate. This makes the SSL certificate available to IIS.

Now open up IIS Manager -> right-click your website -> Properties -> Directory Security -> Server Certificate... -> Next -> Replace the current certificate -> Choose the newly-generated SSL cert in the list -> next -> Finish. This should start serving the SAN-enabled cert immediately. If not, stop/start IIS just to be safe. Confirm i a browser that it is using the new SSL cert and have the Subject Alternate Name field with all the secondary FQDNs in it.

I wish I could tell you more, but without having done it myself, I'm not going to be much more of a help in Exchange 2003.
0
sjacctAuthor Commented:
To be honest, I'm still confused. Verisign contacted us recently. their solution is using 2 certs, one for mail server, one for OWA. I don't know if it is the right way before we can do real testing. The issue is no one can explain the mechanism of their method.
0
sjacctAuthor Commented:
The problem is eventually solved.

We found an article, in Microsoft TechNet, "How to Simplify the Outlook Web Access URL".

Procedure:
To simplify the Outlook Web Access URL
1. Using the Internet Services Manager, open the properties for the Default Web Site.
2. Click the Home Directory tab, and then select A redirection to a URL.
3. In Redirect to, type /<directory name>, and then click A directory below URL entered. For
example, to redirect https://mail/ requests to https://mail/exchange, in Redirect to, you would
type /exchange.

We did it as the article suggested. Then, we bought a single domain certificate for
MAIL.OURDOMAIN.COM.

No more error, the result is simply what we expected.

Kind of disappointed, in Expert-Exchange, no one could give us this simple solution. It took us so long
to figure it out.
0

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
geowrianCommented:
I'm glad it worked out for you. However, that solution worked for now, but you may have some issues down the road, especially if you upgrade or grow. For one, OOA and other Autodiscover-based features may be a little funny due to the redirection. I'm not sure how regular Outlook clients in Exchange mode would react, either.

But I wish you the best and am glad it's worked out.
0
Alan HardistyCo-OwnerCommented:
This question has been classified as abandoned and is being closed as part of the Cleanup Program.  See my comment at the end of the question for more details.
0
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
SSL / HTTPS

From novice to tech pro — start learning today.