Outlook 2007 Certificate Error?

When importing a new certificate into Exchange 2007, you might encounter a certificate error in Outlook 2007. I have included a screenshot of the error I encountered today:

When you choose the View Certificate button, it brings up another window that shows you what certificate is in error. In this case, the certificate name is “mail.shudnow.net.”

So the million dollar question? Why the error?

Well, when we install a new certificate, there are a few tasks we want to do. Obviously, we install the certificate for a purpose. This purpose is till allow us to use Exchange services securely. So how do we enable Exchange to use these services? If you are planning to do a very simple configuration and do not care about external Autodiscover access, you do not need to use a Unified Communication Certificate. You can read more about these certificates in one of my other articles here.

So let’s say we have a simple regular common certificate. A certificate with a Common Name (CN) of mail.shudnow.net We install this certificate onto our Exchange box with its’ private key. In our case we were migrating so we did not have to request a certificate via IIS. We just exported it with its’ private key and imported onto the new box. We then assigned this certificate to IIS. Now I went to the Exchange Management Shell and enabled Exchange services to use this certificate. In order to do this, you must run the following commands:

Get-ExchangeCertificate

Thumbprint Services Subject
———- ——– ——-
BCF9F2C3D245E2588AB5895C37D8D914503D162E9 SIP.W CN=mail.shudnow.net.com

What I did was go ahead and enable all new services to use every available service by using the following command:

Enable-exchangecertificate -services IMAP, POP, UM, IIS, SMTP -Thumbprint BCF9F2C3D245E2588AB5895C37D8D914503D162E9

The next step would be to ensure the AutodiscoverInternalURI is pointed to the CAS that will be your primary CAS for Autodiscover servicing.

Get-ClientAccessServer -Identity CASServer | FL

AutoDiscoverServiceInternalUri : https://casnetbiosname/Autodiscover/Autodiscover.xml

See the issue here? We are not using a UC certificate that contains the names, “casnetbiosname, casnetbiosname.shudnow.net, mail.shudnow.net, and autodiscover.shudnow.net” Since the Autodiscover directory in IIS will be requring SSL encryption, the url specified in the AutoDiscoverServiceInternalURI must match what is specified in your certificate. You must also ensure there is a DNS record that allows mail.shudnow.net to resolve to your CAS. We should re-configure the AutoDiscoverServiceInternalURI by using the following command:

Set-ClientAccessServer -Identity CASServer -AutoDiscoverServiceInternalUri https://mail.shudnow.net/Autodiscover/Autodiscover.xml

We now need to go configure all the InternalURLs for each web distributed service. If you are going to be utilizing the Autodiscover service from the outside or for non-domain joined clients, you may want to configure an -ExternalURL in addition to your -InternalURL.

Here is the reason why we were receiving the certificate errors. Your InternalURLs most likely are not using mail.shudnow.net. Your InternalURLs are most likely pointed to something such as https://casnetbiosname/ServiceURL which will fail since this is not the CN of your simple certificate.

You can run the following commands to fix your internalURLs so your Outlook 2007 client can successfully take advantage of your web distribution services.

Set-WebServicesVirtualDirectory -Identity “CASServer\EWS (Default Web Site)” -InternalURL https://mail.shudnow.net/EWS/Exchange.asmx -BasicAuthentication:$true

Set-OABVirtualDirectory -Identity “CASServer\OAB (Default Web Site)” -InternalURL https://mail.shudnow.net/OAB

Note: You must ensure that you enable SSL on the OAB directory in IIS which is not on by default. The above command will only enable SSL, but will not ensure 128-bit SSL is required.

Enable-OutlookAnywhere -Server CASServer -ExternalHostname “mail.shudnow.net” -ClientAuthenticationMethod “Basic”-SSLOffloading:$False

Note: The above Enable-OutlookAnywhere command works on SP1. For RTM, substitute -ClientAuthenticationMethod with -ExternalAuthenticationMethod.

Set-ActiveSyncVirtualDirectory -Identity “CASServer\Microsoft-Server-ActiveSync (Default Web Site)” -ExternalURL https://mail.shudnow.net/Microsoft-Server-Activesync

Set-UMVirtualDirectory -Identity “CASServer\UnifiedMessaging (Default Web Site)” -InternalURL https://mail.shudnow.net/UnifiedMessaging/Service.asmx -BasicAuthentication:$true

Elan Shudnow :: Aug.10.2007 :: Exchange :: 42 Comments »

42 Responses to “Outlook 2007 Certificate Error?”

on 22 Feb 2008 at 10:24 am1red-erik

U saved my job…tnx a lot

Red.

P.S. There is a lot of confusing documentation over the net regarding Exchange 2007 certificates (ad ISA Publishing..)
You document is really clear and usefull
on 22 Feb 2008 at 5:03 pm2Elan Shudnow

Thanks for the positive comments! I’m glad the article was of help to you.
on 06 Mar 2008 at 3:58 pm3tibby812

You are awesome. Thanx for the fix.
on 08 Mar 2008 at 2:41 pm4farisnt

HI
I have this problem and I had all the Certificate CN are correct and match for the FQDN
what can I do
THanks alootttt
on 08 Mar 2008 at 5:01 pm5Elan Shudnow

I replied to your question on msexchange.org forums. Go there and read my reply.
on 11 Mar 2008 at 9:01 pm6motsis666

I had the same problem with Farist, and i find your reply at msexchange.org forum, but i can not find your post, pls send me link ok post your reply again,
Thank u very much
on 11 Mar 2008 at 9:07 pm7motsis666

Sorry
I found your reply at:
http://forums.msexchange.org/m_1800468295/mpage_1/key_/tm.htm#1800468447

You are awesome
on 12 Mar 2008 at 11:29 am8petoulachi

Hi,

I had the same problem but solved it in a different way. Unstead of modify the Exchange InternalUrl, I have request a certificate with multiple host names, as Microsoft shown here : http://technet.microsoft.com/en-us/library/aa995942.aspx

I don’t know which solution is the best, but I think these is a little more simple.

Hope this help
on 12 Mar 2008 at 1:15 pm9Elan Shudnow

petoulachi, I stated that this solution is for single-name certificates and is specifically for people who are not using UC/SAN certificates. Even if you do have a UC/SAN certificate, you still need to ensure that the Internal and External URLs are specified correctly.

I posted a more informative reply in regards to your comment at your post on msexchange.org forums. Check it out at the following URL:
http://forums.msexchange.org/m_1800468544/mpage_1/key_/tm.htm#1800468544
on 18 Mar 2008 at 11:28 pm10vividdm

All Hail Elan, All Hail Elan :)

I wish i came across this months ago.. thank you sooo much!!!

only difference i had was with SP1
-ExternalAuthenticationMethod becomes> -ClientAuthenticationMethod

can i be the like the fifth person to say ‘you are awesome!!’ :)

dm.
on 19 Mar 2008 at 3:13 am11petoulachi

Hi Elan Shudnow,

I think that in fact I have a problem with my InternalUrl. Actually, they are default value (CASServer.domain.local). As I have a certificate with multiple host name, my local users don’t have any problem.

But my roaming users, using Outlook Anywhere, have a sync issue :
not downloading offline address book files. A server (URL) could not be located
0×8004010f

Searching on the net I have found that it’s often related to the autodiscover InternalUrl. I was thinking that it was more related to OAB InternalUrl.
As I’m not really sure, maybe you could confirm me what should I do ?

Thanks in advance !
on 19 Mar 2008 at 8:49 am12Elan Shudnow

Vividdm -
Thank you for the comments. I will update my article later today to include the new syntax for SP1.

petoulachi -
Roaming users will not use the InternalURL. They will use the ExternalURL. The way this works, is that when a domain-joined client is on the corporate network, and they have connectivity with Active Directory, the client will be able to contact a Service Connection Point stored in Active Directory which contains all the InternalURL’s for the services on the internal network.

When a client is not domain-joined or is outside of the corporate network and does not have direct connectivity to Active Directory, the Outlook client will contact the Autodiscover Service via autodiscover.smtpdomain.com. Note that I say smtpdomain.com. This does not necessarily mean your Active Directory domain. This is mostly your Accepted Domains. You would only really need autodiscover.acceptedsmtpdomain.com for the primary smtp addresses in your e-mail address policy.

So when a client contacts the Autodiscover Service, the Autodiscover Service will reply with -ExternalURL since the client is either not domain joined or outside of the corporate network. It essentially just means, “Not Connectivity to AD? No -InternalURL for you!”

So because of this, -InternalURL could be https://CASServer/Service and work just fine since you know this client is Internal and should be able to contact the CASServer via NetBIOS. But when a client is not domain joined or outside of the corporate network, you want to make sure that you specify the -ExternalURL as a FQDN, mail.domain.com/service. You wouldn’t want it to be a NetBIOS name since you’ll be doing this connection through the Internet.

You also want to make sure you configure the AutodiscoverInternalURI correctly. This can be FQDN or NetBIOS name. Get-ClientAccessServer to see what it’s set at. Make sure it’s set to something compatible in your certificate.

After you set all this up, do an update on the OAB and do an update-filedistributionservice which takes the OAB from the OAB generation server and pushes it to the CAS for Outlook 2007 Web Distribution.
on 19 Mar 2008 at 9:16 am13petoulachi

It just sound pretty clear to me.

My InternalUrl for autodiscover is correctly set. However, I have a question about the autodiscover.acceptedsmtp.com. Does this url needs to be resolved by my external users ? It’s not the case at the moment.
on 19 Mar 2008 at 9:18 am14petoulachi

Sorry I have Tab/Enter unfortunatelly :p

So as this dns is not resolved it’s maybe why my roaming users can’t find the OAB ?

Anyway, the OAB (Default Web Site) didn’t have an externalUrl set, to I’ve just set it one. Regenerating the OAB seems not to resolve the problem.
on 19 Mar 2008 at 9:21 am15Elan Shudnow

Yes, you will need to have an internet resolvable forward lookup zone for every smtpdomain. You will then have to have the autodiscover host (A) record in every forward lookup zone. You will then have to make sure your certificate contains an autodiscover.domain.com FQDN for every smtp domain you have.
on 19 Mar 2008 at 9:23 am16petoulachi

Okay so the problem should come from that, as this host does not exist for my public DNS.

I keep you informed, but it seems to be on good way :)

Thanks a lot !
on 19 Mar 2008 at 9:26 am17Elan Shudnow

You’re welcome. Glad I could be of help.
on 19 Mar 2008 at 9:34 am18petoulachi

Well for testing purpose I have had the autodiscover.domain.com in my HOST file.

Now I have a certificated warning, OK, my certificate currently doesn’t have this FQDN. So I have to change my certificate with a new one that contains this FQDN ? so bad, I just send to activesync users the other certificate…

Anyway, after that warning there’s still the sync error. Now I really don’t know what to do.
on 19 Mar 2008 at 9:37 am19Elan Shudnow

Set the URL appropraitely for the ActiveSync service and make sure the FQDN of the URL is contained in the certificate. You really need to get your DNS set up and get all the FQDN’s you need in your certificate. None of your services will work properly until you do so.

If you need more assistance, I’ll check back later today. I need to get back to work. Hope you get this sorted.
on 20 Mar 2008 at 3:59 pm20njaggers

Thanks for the great article. However, I am having a problem with one of the powershell scripts. When I execute the enable-outlookanywhere command, this is the error I receive:

enable-outlookanywhere : the virtual directory ‘rpc’ already exists under ‘CAServer.domain.local/default web site’. Parameter name: virtualdirectoryname

Any thoughts on what this means and how to properly execute the script in powershell?
on 20 Mar 2008 at 4:08 pm21Elan Shudnow

You can try going into the Exchange Management Console and specifying the proper URL there.

Or you can try doing Set instead of Enable.

RTM:
Set-OulookAnywhere -Server CASServer -ExternalHostname “mail.shudnow.net” -ExternalAuthenticationMethod “Basic”-SSLOffloading:$False

SP1:
Set-OulookAnywhere -Server CASServer -ExternalHostname “mail.shudnow.net” -ClientAuthenticationMethod “Basic”-SSLOffloading:$False
on 21 Mar 2008 at 9:27 pm22njaggers

Thanks for the reply. I inputed this command into PS:

set-outlookanywhere -identity CAServer -externalhostname “mail.domain.com” -externalauthenticationmethod “basic”-ssloffloading:$false

This is the response from PS: set-outlookanywhere : the operation could not be performed because object ‘CAServer’ could not be found on the domain controller ’server.local’

What am I missing here? All my mail flow is working correctly so I don’t know why PS reported cannot locate my dc. Also, when I attempted to input the command into PS using the -server command instead of the -identity command, this is what returned: set-outlookanywhere :

a parameter cannot be found that matches parameter name ’server’

I think I have been messing with this so long I am missing something obvious. Any insight would be appreciated.
on 22 Mar 2008 at 10:06 am23Elan Shudnow

It’s not saying it cannot find your DC, it’s saying it cannot find CASServer, which is your client access server, but might also be a DC if you configured it that way (not recommended). Make sure you replace the word CASServer with the server that has the RPC over HTTP Proxy component installed on it which should be a Client Access Server.

So if your Client Access Server’s name is CHIEXCCAS01 and your certificate has a name of mail.shudnow.net, you would do:

set-outlookanywhere -identity CHIEXCCAS01 -externalhostname “mail.shudnow.net” -externalauthenticationmethod “basic”-ssloffloading:$false

Make sure you replace externalauthenticationmethod with clientauthenticationmethod if you’re using SP1.

If that doesn’t work, as I said, go into the Exchange Management Console and just manually set it.
on 23 Mar 2008 at 4:40 pm24njaggers

Thanks! I went into EMC and changed the setting that way. The PS script kept giving me problems.
on 01 Apr 2008 at 3:57 am25petoulachi

Hi,

I can’t make autodiscover work from outside, maybe you could take a look at http://forums.msexchange.org/Another_Autodiscover_problem/m_1800470564/tm.htm if you have a solution :)
on 01 Apr 2008 at 5:13 am26Elan Shudnow

I have an article that details publishing the autodiscover service in ISA:
http://www.shudnow.net/2007/07/15/publishing-exchange-2007-autodisover-in-isa-2006/

One of the things is that ISA 2006 will only read the CN or the 1st SAN name, so you have to trick ISA to make autodiscover publishing to work. I explain how to do that.
on 17 Apr 2008 at 2:03 am27ketrasap

Thanks Alot,

I’ve been trying to fix this issue for months now.
on 05 May 2008 at 4:53 pm28kingofbytes

Sir, you are to be commended for your contributions. Thank you very much!
-Kingofbytes
on 07 Jun 2008 at 3:13 pm29Out of Office Error Message in Outlook 2007 | Server Talk

[...] Wenn der Out of Office Assistant von Outlook 2007 die OOF Konfiguration vornehmen möchte, wird eine Verbindung zum “Exchange Web Services” (EWS) Virtual Directory hergestellt. Da Outlook den Pfad zum EWS Virtual Directory nicht kennt, muss dazu der Autodiscover Service kontaktiert werden. Dies geschieht für Domain Member mithilfe des Active Directory, oder für alle anderen mittels DNS. Probleme können also bereits entstehen, wenn der benötigte Autodiscover Service nicht gefunden, oder nicht kontaktiert werden kann. Mit dem bei Outlook 2007 integrierten Funktion “E-Mail AutoKonfiguration testen… / Test E-Mail AutoConfiguration” kann sehr einfach die Verbindung mit dem Exchange Server kontrolliert werden (Beim Outlook-Symbol im System Tray [CTRL] und “rechte Maustaste” drücken). Falsch konfigurierte URL’s können mit dem PowerShell Command “Set-WebServicesVirtualDirectory” angepasst werden. Eine gute Anleitung zur Konfiguration der Web Services gibt es bei Elan Shudnow’s Blog. [...]
on 30 Jun 2008 at 6:34 am30brentvw

Hi Elan,

This worked great! Thank you very much. One concern I am having is the following error. This seems to come up every 20 or so minutes.

An internal transport certificate will expire soon. Thumbprint:9B32B314CB5ABC963F9F0F6A03F22FCD7E832896, hours remaining: 536

The only difference from your post is when I run Get-ExchangeCertificate, I see two thumbprints… One for the NETBIOS name and then one for the certificate name. I used the thumbprint for the certificate name.

Thumbprint Services Subject
———- ——– ——-
752714FF7F34CBCCC49A3A72 ….S CN=SM5500SRV
9B32B314CB522FCD7E832896 IP.WS CN=mail.somecompany.com,…
on 30 Jun 2008 at 6:36 am31brentvw

Hi, someone just brought to my attention our certificate IS expiring in 536 hours, it is only valid until July 22nd, so this is perfectly normal I guess. One question would be then do I have to do anything with the new certificate.
on 30 Jun 2008 at 3:47 pm32Elan Shudnow

Brent, one is your self-signed certificate and one is the mail.somecompany.com certificate. You really don’t have to delete your self-signed certificate because Exchange will always use a certificate signed by a trusted CA before it uses a self-signed certificate. If you are talking about an Edge Server, I would leave the self-signed certificate on there as the Edge Server will copy the self-signed certificate to Active Directory which the Hub Transport Server will use as a trusted mechanism without needing to import the self-signed certificate into the Trusted Root Certificate store on the Hub Transport Server.

Here is a guide on how to renew the self-signed certificate:
http://exchangepedia.com/blog/2008/01/exchange-server-2007-renewing-self.html

For the regular certificate, you can just request a certificate the same way you originally did. If you have exported this certificate and imported it onto other servers such as ISA, make sure you update ISA with the new certificate (importing, attaching to ISA web listener, etc..)
on 24 Jul 2008 at 8:36 am33vedholm

Hi

Great post! BUT after changing this my “Out of office” wont workm anymore

This was related to:
Set-ClientAccessServer -Identity CASServer -AutoDiscoverServiceInternalUri https://mail.shudnow.net/Autodiscover/Autodiscover.xml

when i change i back to “https://servername/Autodiscover/Autodiscover.xml” it works again

I have created a record in the internal DNS so this “external name” works internal as well, but i still get the same error.

Se article:
http://www.proexchange.be/modules.php?name=News&file=article&sid=686

How to fix this :-) ?

Best regards
Jesper
on 25 Jul 2008 at 6:01 pm34Elan Shudnow

That means DNS doesn’t point to your CAS or the FQDN you specify doesn’t match a name on your certificate, or maybe you require SSL on the autodiscover but you didn’t specify https://.
on 26 Jul 2008 at 2:14 am35vedholm

Hi Elan

Internal the record owa.domainname.dk points to my CAS internal - i can see that i resolves just fine. But stille when i change the autodiscover to this DNS name which matches internal and external the “out of office” gets broken again.

The name on the Exchange webservice is mtaching the certificate called owa.domainname.dk - and external it works as well with the same name

Best regards
Jesper
on 29 Jul 2008 at 3:30 pm36Elan Shudnow

Make sure you configured the EWS for the correct InternalURL and ExternalURL:
Set-WebServicesVirtualDirectory -Identity “CASServer\EWS (Default Web Site)” -InternalURL https://owa.domainname.dk/EWS/Exchange.asmx -ExternalURL https://owa.domainname.dk/EWS/Exchange.asmx -BasicAuthentication:$true
on 27 Aug 2008 at 10:54 pm37lotusbob

Thanks for this post. I followed the instructions and the error went away…..for all the users inside the LAN.

Now I am being told that Outlook Anywhere users outside are getting an error because they are looking for autodiscover.mydomain.com

I thought I had the problem solved
on 29 Aug 2008 at 7:28 am38Elan Shudnow

Here’s the Autodiscover whitepaper:
http://technet.microsoft.com/en-us/library/bb332063.aspx

There’s a couple things you can do. You can use an SRV record for Autodiscover, or you can get a UC/SAN certificate from a provider such as Entrust/Digicert/Etc. that contains a Subject Alternative Name of autodiscover.domain.com. As far as I remember, the SRV record option will prompt your users for acceptance while the SAN name method will not and is the recommended method. I would read the whitepaper for more information.
on 14 Oct 2008 at 6:53 pm39dtstanton

I’ll preface this with the fact that I am a newbie with powershell, but I have been beating my head against the wall with this one, none of the commands you have listed are recognized. even Get-ExchangeCertificate came back saying unrecognized command or script. Hopefully I am just doing something simple wrong. any thoughts?
on 14 Oct 2008 at 7:09 pm40Elan Shudnow

You need to use the Exchange Management Shell. I assume you’re opening PowerShell itself which doesn’t execute the Exchange Snap-Ins.
on 15 Oct 2008 at 8:18 am41dtstanton

I must have been asleep, I retried everything this morning, and it worked. thanks.
on 22 Oct 2008 at 11:22 am42megatherion

Really useful post! I had spent a lot of time trying to solve this problem, then I find this entry and solve the problem in just a couple of minutes. *bows*

Trackback this post | Feed on Comments to this post

You must be logged in to post a comment.

Elan Shudnow’s Blog

Just another IT guy!