Posts RSS Comments RSS 51 Posts and 48 Comments till now

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. 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 same goes for Basic Authentication on the OAB directory. The above command will only enable SSL, but will not ensure 128-bit SSL is required.

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

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

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, Microsoft :: 28 Comments »

28 Responses to “Outlook 2007 Certificate Error?”

  1. 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

  2. on 22 Feb 2008 at 5:03 pm2Elan Shudnow

    Thanks for the positive comments! I’m glad the article was of help to you.

  3. on 06 Mar 2008 at 3:58 pm3tibby812

    You are awesome. Thanx for the fix.

  4. 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

  5. on 08 Mar 2008 at 5:01 pm5Elan Shudnow

    I replied to your question on msexchange.org forums. Go there and read my reply.

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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.

  11. 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 !

  12. 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.

  13. 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.

  14. 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.

  15. 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.

  16. 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 !

  17. on 19 Mar 2008 at 9:26 am17Elan Shudnow

    You’re welcome. Glad I could be of help.

  18. 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.

  19. 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.

  20. 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?

  21. 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

  22. 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.

  23. 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.

  24. 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.

  25. 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 :)

  26. 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.

  27. on 17 Apr 2008 at 2:03 am27ketrasap

    Thanks Alot,

    I’ve been trying to fix this issue for months now.

  28. on 05 May 2008 at 4:53 pm28kingofbytes

    Sir, you are to be commended for your contributions. Thank you very much!
    -Kingofbytes

Trackback this post | Feed on Comments to this post

Leave a Reply

You must be logged in to post a comment.