Re: Outlook 2007 Certificate Error



I bought the cheapest one I could find. I think it's RapidSSL or GoDaddy. I did not get the UC/SAN cert since I didn't know what that meant, although I do now. But is there a way, with the cert I have, to avoid that annoying dialog box? I've trained the users to blow by it, but.. well you know.

Bobby



"Ace Fekay [MCT]" <aceman@xxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:%23MA6JzFJKHA.1492@xxxxxxxxxxxxxxxxxxxxxxx
"Bobby Janow" <bjanow@xxxxxxx> wrote in message news:023587E5-C2DD-4C87-829C-A69B6B5C048B@xxxxxxxxxxxxxxxx
We bought a cert from GoDaddy and every time a user opens Outlook 2007 we get a certificate mismatch error. We can click through it but it's quite annoying. I guess one of the problems is that the cert is for mail. and the server is server1. But there needs to be a way in SBS 2008 to fix that. Microsoft has some docs on it but it doesn't work on SBS 2008. Any links to resolution out there?

TIA

Bj

BJ,

What type of cert did you purchase? Exchange 2007 needs a UC/SAN cert. It supports multiple names. I know you can probably get away with a standard cert, such as what was used in Exchange 2003, and a few folks may respond that it works. However, I myself, prefer the other to accomdate internal and external names for Outlook 2003 and 2007, as well as ActiveSync clients and alleviate what you're seeing. I have a little article on it, pasted below. It is also available at:
http://msmvps.com/blogs/acefekay/archive/2009/08/23/exchange-2007-uc-san-certificate.aspx.

==================================================================
Exchange 2007 UC/SAN Certificate

---
Ace Fekay, MCT, MCTS Exchange 2007, MCSE & MCSA 2000/2003, MCSA Messaging
May, 2009
---

This topic goes into understanding the differences between certificate requirements in Exchange 2007.

Getting a certificate for Exchange 2007 is a little different than Exchange 2003 or a simple website. Exchange 2007 requires a UC/SAN (Unified Communications - Subject Alternative Name). This type of cert supports multiple names, which Exchange 2007 requires, especially to include support for Outlook 2007 Autodiscover record.

However it is possible to use a single named certificate, as was used in Exchange 2003 and basic web sites. It is possible, however I've found with the UC/SAN cert that it accommodates Outlook 2007's Outlook Anywhere and auto-connect features.

Before going further, if you are not sure if your Exchange 2007 installation is setup properly for outside clients, whether they would be Outlook 2003, Outlook 2007, or Mobile handhelds using ActiveSync, please visit the following Microsoft Exchange Connectivity Test site. It will provide a report on where things fail if there are any issuess:

Microsoft Exchange Server Remote Connectivity AnalyzerSelect the test you want to run.
https://www.testexchangeconnectivity.com


======
UCC/SAN Certificate

The advantage and features of a UC/SAn cert is it allows you to create multiple names in the certificate. Note, this is not a wildcard certificate that will allow you to use any or an infinite number of names. Exchange 2007 does not work with such a certificate. It will, as mentioned, work with a single name certificate, if so desired to save money on the certificate prices, but I've found it beneficial to use a UC/SAN certificate for the multiple names that an Exchange server will use for clients.

The four main names I recommend adding to the cert when creating the request file are:

mail.company.com (the external FQDN name used to access OWA)
autodiscover.company.com (used for Outlook 2007 Outlook Anywhere's autoconnect feature)
internalname.internaldomain.com (what Outlook Anywhere and DSProxy uses over RPC/HTTPS used to connect to Exchange)
internalname (the NetBIOS name of the Exchange 2007 server)

The internalname.internaldomain.com is what Outlook Anywhere and DSProxy uses over RPC/HTTPS that's used to connect to Exchange 2007.

The autodiscover.company.com is used by Outlook 2007's Outlook Anywhere autoconfiguration feature.

If you go to the following site, they offer complete instructions on how the request works along with a web-based tool to configure and create a certificate request command to be used in the Exchange Management Shell in Exchange 2007. I've found this feature very convenient.
DigiCert's Exchange 2007 CSR Tool
https://www.digicert.com/easy-csr/exchange2007.htm

Once it creates the command for you, you can use it to create the request in your Exchange 2007 server, then submit the request file to the certificate authority.

I've been using this company (DigiCert) to purchase this type of certificate for my customers.

Note - I am not trying to push this company's certificate on anyone. I've just found it easier to use and less expensive than other certificate authorities out there, which may have other stipulations and requirements when requesting a UC/SAN certificate. There are others out there, but I found this one is cheaper than a couple of others, and works with Windows Mobile 5 and 6 without problems. But that is up to you. Please check the other companies, such as Verisign, Thwate, InstanSSL, etc, to compare.

Please keep in mind, your name, company name, etc, whatever name you put on the cert (based on the domain name), a WHOIS on your domain name must have this exact
information, or they will not issue the certificate. This is a strict requirement by the certificate authorities. You can call them if more specific info about this.

More things to consider concerning the internal AD DNS domain name and if using Exchange 2007:

If you choose an internal AD DNS name, be careful of the TLD you choose. You do not want to choose one that is already in use by another entity. Reason is it will cause due confusion, and will create problems if you were to get an Exchange 2007 UC/SAN certificate and adding a name for the internal namespace on the certificate. Here are some existing TLDs that you do not want to choose if the name does not belong to your entity. So it would be a bad choice for the complications that will arise, if you name the internal domain is registered by others.

In one word, please make sure never to use a internal domain with a suffix same as existing Top-level domain names. You can use such as ABC.earth, ABC.mars and ABC.<whatever> but prevent from using those exiting top-level domains suffix that exist. So If I were to chose domain.net for my internal name, but it is owned by someone else, the certificate authorities will not approve the certificate request.

Technically speaking, you can also use the same name for the internal domain and the external domain. However, this method is not recommended. You may encounter following possible issues that you may have to perform a domain rename in the future. Not something that one desires to do.

Some guidelines for internal AD DNS domain naming:

1. If you name the internal domain the same as your Internet public domain name, in some time domain internal client will get the domain external IP (resolved from external domain name). In the scenarios that you also have published Exchange Server to receive external mails, the issue will be much more complicated. A sample issue:

Same Internal and External Domain Name
http://techrepublic.com.com/5208-11190-0.html?forumID=40&threadID=181117

2. Worse, if you name the internal domain is registered by others. Then it will never get approved.

---

Guidelines for the Autodiscover record:

Externally DNS:
In your public zone, create an 'autodiscover' record under the public domain name.

Internal DNS:

To alleviate errors with Outlook Anywhere, you can create a DNS Service
Location (SRV) records to locate the Exchange Autodiscover service. If not,
errors will generally happen when the SRV record for the domain for
autodiscover is missing. In this issue that internal Outlook users receive
the error, you may check whether the _autodiscover SRV record exists in the
domain zone.

The record looks like:

_autodiscover._tcp.domain.local

Related information and how-to articles:

A new feature is available that enables Outlook 2007 to use DNS Service
Location (SRV) records to locate the Exchange Autodiscover service
http://support.microsoft.com/kb/940881/en-us

Introducing the Internet Address Management Wizard: Part 3 of 3
http://blogs.technet.com/sbs/archive/2008/10/17/introducing-the-internet-address-management-wizard-part-3-of-3.aspx
==================================================================

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.

Please reply back to the newsgroup or forum for collaboration benefit among responding engineers, and to help others benefit from your resolution.

Ace Fekay, MCT, MCTS Exchange, MCSE, MCSA 2003 & 2000, MCSA Messaging
Microsoft Certified Trainer

For urgent issues, please contact Microsoft PSS directly. Please check http://support.microsoft.com for regional support phone numbers.


.



Relevant Pages

  • Re: SSL certificates
    ... Default - which points to the internal FQDN ... My SSL Cert has mail.mydomain.com which is why I am now getting the errors ... Microsoft Exchange couldn't find a certificate that contains the domain name ... self-signed certificate to advertise StartTLS to internet Server to Server ...
    (microsoft.public.exchange.admin)
  • Re: HELP RPC over HTTP
    ... >completing all these steps I am still unable to get into outlook from the ... Make sure you have access to the network and the exchange server it ... people have been using a Windows certificate on the box ... connect to htps://servername.domain.com/exchange from the Internet. ...
    (microsoft.public.exchange.misc)
  • Re: Setting up RPC over HTTP
    ... Microsoft Exchange Server Remote Connectivity Analyzer ... The SSL certificate failed on validating ... created by what's its name Internet Connection wizard? ...
    (microsoft.public.windows.server.sbs)
  • Re: Certificate Help
    ... You need to remove the private CA cert purchase a new SAN cert from a public CA and then install the public CA cert, then enable the cert for IIS,SMTP and imap. ... The issue is related to the name referenced and the certificate attached to the exchange services in IIS. ... The public sees the server as mydomain.com and all of the email addresses are in the .com address space. ... our FQDN for elho helo reponses should be mail.mydomain.com to ensure proper DNS for internet email delivery. ...
    (microsoft.public.exchange.admin)
  • Re: Confusion RE: Transport Security Layer
    ... If you choose not to use Cert ... there are plenty of public certificate authorities out there. ... > server that requires TSL. ... >>>does this apply to Exchange 2K3. ...
    (microsoft.public.exchange.admin)

Quantcast