sjacct
asked on
Unrecognized certificate error
Our mail server name is server16C. MAIL is the alias name of server16C.
Users use mail.ourdomain.com/exchang
Users don't like to use server16C.ourdomain.com/ex
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.
Users use mail.ourdomain.com/exchang
Users don't like to use server16C.ourdomain.com/ex
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.
http://www.sslshopper.com/article-stop-the-page-contains-secure-and-nonsecure-items-warning.html
ASKER
It is not "page contains secure and nonsecure items" warning.
What is the exact error when you browse to http://mail.ourdomain.com?
ASKER
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 !
I noticed someone mentioned aka multi-domain cert or SAN cert. Can anyone provide more info for this specific cert?
Thanks !
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.
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.
ASKER
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.
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.
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.
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.
ASKER
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
But I wish you the best and am glad it's worked out.
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.