Solved

RPC over HTTPS not working on Outlook 2007 clients on XP on SBS 2008 after weekend SSL changes

Posted on 2010-08-16
66
2,153 Views
Last Modified: 2012-05-10
Starting this morning, my Windows XP users with Outlook 2007 are not able to connect to their mailboxes on the SBS 2008 box using RPC over HTTPS.  Regular MAPI works fine.  Outlook 2003 users are not having problems.  Users with Outlook 2007 on Vista or Win 7 are not having problems either.

I made a change over the weekend to the SSL certificate, but I don't see what would have caused it.  But it must have.

For the last month, I had a single name SSL cert for remote.domain.com.  All clients worked fine with that cert (including XP with Outlook 2007 users).

However, my autodiscover was a problem because my nameserver doesn't support SRV records.

So I created a UCC/SAN cert that included mail.domain.com, remote.domain.com, and autodiscover.domain.com.  I successfully installed that cert using this method:
http://www.xbarit.com/bradblog/2009/12/14/how-to-manually-install-an-ssl-certficate-on-sbs-2008/

The method above worked fine.  The primary name on my cert is mail.domain.com and I can go to remote.domain.com in a browser and the cert works and is trusted.  

But what's so odd is that this problem seems isolated to Windows XP users with Outlook 2007 using RPC over HTTPS.  This includes users on the LAN and users off-site.  What they get is they open Outlook, it prompts for password as normal (username is already populated or can be retyped as internaldomain\username) but when you enter the password, the prompt reappears as though it doesn't recognize the user/pass.  But the user/pass and the setup are correct.  I'm using the typical SBS setup for RPC over HTTPS where the URL to connect to is remote.domain.com and you tell it to connect to proxy servers that only have this principal name in their certificate: msstd:remote.domain.com

I typically tell it to use RPC over HTTPS on fast and slow connections so that users have a common interface when opening Outlook no matter where they are.  I also set it up for basic authentication (just reviewing the setup so you know I'm doing it right).

From my perspective, things worked fine for a month on the single name SSL cert.  Then I added the UCC/SAN cert, and that's when my XP + Outlook 07 users started having problems.

Any ideas?
0
Comment
Question by:dmessman
  • 27
  • 21
  • 12
  • +1
66 Comments
 
LVL 8

Expert Comment

by:epohl
ID: 33446269
Outlook 2007 is much more sensitive to the Certificate than Outlook 2003. Check connectivity for rpc over http using the site below. I am pretty sure you will discover a certificate error.

https://www.testexchangeconnectivity.com/
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33446370
Is your exchange fully patched with latest Service packs.

Latest SP for 2007 is SP3
check this guide on how to install SP3
http://www.sbsfaq.com/?p=2140

These are the warnings
http://www.sbsfaq.com/?p=1992
http://support.microsoft.com/kb/982423

You still need to make this registry key switch
http://support.microsoft.com/kb/973862

thanks
0
 
LVL 32

Expert Comment

by:endital1097
ID: 33446385
i would first try browsing to an internal url for your web services
get-webservicesvirtualdirectory | ft internalurl

https://servername.domain.local/ews/exchange.asmx

you should not receive any certificate warning or errors
if you do, then we know what we need to fix
0
 
LVL 9

Author Comment

by:dmessman
ID: 33446388
you're right in that it tells me:

SSL mutual authentication with the RPC proxy server is being tested.
       Verification of mutual authentication failed.
        Tell me more about this issue and how to resolve it
       
      Additional Details
       The certificate common name mail.domain.com, doesn't validate against Mutual Authentication string provided msstd:remote.domain.com



However, remote.domain.com is definitely an alternative name I listed on the cert, and it's installed, and if I go to https://remote.domain.com - the cert works normally and is trusted

Should I re-key the certificate and make the primary name to be remote.domain.com ?
0
 
LVL 9

Author Comment

by:dmessman
ID: 33446699
epohl led me to the right place.  As per my comment above, I get an error in testexchangeconnectivity of:

The certificate common name mail.domain.com, doesn't validate against Mutual Authentication string provided msstd:remote.domain.com

As per SBS's perference, I use remote.domain.com for just about everything, my RWW URL, the URL for RPC over HTTPS in Outlook, etc.

But when I create a UCC/SAN cert, I should be able to make the common name be mail.domain.com and make remote.domain.com one of the alternative names, right?  Thinking that I needed to make remote.domain.com the common name, I went to godaddy and tried to reky the cert using remote.domain.com as the common name, but when I downloaded the cert, it still listed mail.domain.com as the common name.

Any thoughts on this?
0
 
LVL 8

Expert Comment

by:epohl
ID: 33446719
Is remote.domain.com aslo what is being used for OWA,IMAP/POP3/SMTP and Exchange ActiveSync ? Is is also what your MX record points to? If yes then it should be listed as the primary name.
0
 
LVL 9

Author Comment

by:dmessman
ID: 33446752
Now that you mention it, my primary MX record points to mail.domain.com.  I will change that now.

How do I define/check what is being used for OWA,IMAP/POP3/SMTP and Exchange ActiveSync?  Presumably, SBS 2008 would set all those items to be remote.domain.com.  But we should double check.
0
 
LVL 8

Expert Comment

by:epohl
ID: 33446758
Are you using mail.domain.com for anything? If not might try removing it and regenerate from godaddy. Then add it back if needed after common name is changed to remote.domain.com
0
 
LVL 8

Expert Comment

by:epohl
ID: 33446858
On the sbs console go into network, connectivity and see what it has listed for internet name. You can also go into Exchange Management Console and look under client access and check the external links but they should have been set by sbs.
0
 
LVL 9

Author Comment

by:dmessman
ID: 33447707
All my external links point to remote.domain.com

So here is what I seem to be seeing.  All my resources are set for remote.domain.com.  On godaddy, my UCC/SAN cert is setup for a common name of mail.domain.com with alternative names of autodiscover.domain.com and remote.domain.com

As far as I can tell, this should work - and the example is even listed that way on the page I followed to install a UCC/SAN cert on SBS 2008:
http://www.xbarit.com/bradblog/2009/12/14/how-to-manually-install-an-ssl-certficate-on-sbs-2008/

However, it seems with my UCC/SAN cert set up using that link above, my Outlook 2007 clients on Windows XP will not connect to the SBS 2008 box.  testexchangeconnectivity.com gives me this error:

The certificate common name mail.domain.com, doesn't validate against Mutual Authentication string provided msstd:remote.domain.com



I have two questions on where I am:

1) could it be that the there is a problem with the cert?  Meaning - the client is not seeing the alternative names as it should be?  Does the common name have to match the URL of the exchange server or can one of the alternative names match the URL of the Exchange server.  I figured an alternative name was fine.  I know it's hard to say without seeing my cert.  Screen shots below . . .

2) Do I need to revoke and rekey my cert for remote.domain.com or change my external links to mail.domain.com?  I don't love that option, but if that's what it takes, then so be it.  

Does anyway else have experience with this type of setup where one of the alternative names is really the primary name external URL for the server?  
0
 
LVL 8

Expert Comment

by:epohl
ID: 33447854
Do you have a dns entry for autodiscover.domain.com that also points to your external IP address?
0
 
LVL 8

Expert Comment

by:epohl
ID: 33447940
Also rather than enabling the certificate using your instructions can we add it using the SBS Wizard under network connectivity add a trusted certificate. Select the option to use an existing certificate. Your new UCC certificate with the additional names should be listed. Select it and then complete the wizard. SBS will install the certificate in to the web sites correctly for you.
0
 
LVL 9

Author Comment

by:dmessman
ID: 33489226
@epohl - I tried to use the SBS wizard to install the certificate.  There are steps detailed here about that:

http://blog.sembee.co.uk/post/SBS-2008-Certificate-Installation.aspx

However, even though my UCC/SAN certificate is in the personal certificate store, it doesn't appear as one of the already existing certificates.  I followed the steps from the link above exactly.
0
 
LVL 32

Expert Comment

by:endital1097
ID: 33489481
if it isn't available then the private key must not be available

go into the certificates snap-in for the server and open the certificate to ensure the private key is available

if it is not, you will need to regenerate the cert
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33496731
dmessman
Where are you with this issue.

Can we try a few commands and check your config:

get-exchangecertificate | fl
get-webservicesvirtualdirectory | fl
Get-clientAccessServer ¦ fl

Please post the results here.

thanks
0
 
LVL 9

Author Comment

by:dmessman
ID: 33496874
thanks for following up.  At this exact moment, I have removed my UCC/SAN certificate and gone back to the a single name cert.  While I had the multi domain cert in place, my users had trouble - and I couldn't have that.  Do you still want the results of those commands even with the sing name cert in place?
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33496890
yes please
Did you have issues with outlook connecting to exchange server / because of which you had to remove UCC/SAN cert ?

If yes - we can fix that.
0
 
LVL 9

Author Comment

by:dmessman
ID: 33501094
@sunnyc7 - using the single domain SSL cert of remote.domain.com, my RPC over HTTPS was working properly for all users, but of course I lacked autodiscover functionality.

I installed a UCC/SAN cert with a common name of mail.domain.com with alternative names of autodiscover.domain.com and remote.domain.com - but with the new SSL cert, my RPC over HTTPS was no longer working for XP users  with Office 2k7.  Interestingly, Vista and Win 7 users had no problem with the new cert.

Anyway - requested data forthcoming.
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33501140
on exchange shell run this

get-autodiscovervirtualdirectory | fl

also
get-exchangecertificate | fl

Use this U-B Tech tool to point and click and manage your cert's
www.u-btech.com/products/certificate-manager-for-exchange-2007.html

Your cert has to be issued in the name of

mail.domain.com (External FQDN)
autodiscover.domain.com (external SRV record)
mail.domain.local (internal FQDN)
mailservername (internal server name)
0
 
LVL 32

Expert Comment

by:endital1097
ID: 33501168
do all of the autodiscover features work on the XP machines (OOF, OAB, free/busy)?
0
 
LVL 32

Expert Comment

by:endital1097
ID: 33501182
0
 
LVL 9

Author Comment

by:dmessman
ID: 33501221
here are the results of get-exchangecertificate | fl





AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System
                     .Security.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {remote.domain.com, autodiscover.domain
                     .com}
HasPrivateKey      : True
IsSelfSigned       : True
Issuer             : C=US, S=DC, L=Washington, O=Spitfire, OU=na, CN=remote.
                     domain.com
NotAfter           : 8/16/2011 12:23:32 PM
NotBefore          : 8/16/2010 12:03:32 PM
PublicKeySize      : 2048
RootCAType         : None
SerialNumber       : 0C501613E7C001A14D6BFE4420C30043
Services           : None
Status             : Valid
Subject            : C=US, S=DC, L=Washington, O=ORGANIZATION, OU=na, CN=remote.
                     domain.com
Thumbprint         : 3BD6FD7135360B760A4F54F5F744A623A22BCDEB

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System
                     .Security.AccessControl.CryptoKeyAccessRule, System.Securi
                     ty.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {mail.domain.com, www.mail.domain.
                     com, remote.domain.com, autodiscover.domain
                     .com, vpn.domain.com}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : SERIALNUMBER=10688435, CN=Starfield Secure Certification A
                     uthority, OU=http://certificates.starfieldtech.com/reposit
                     ory, O="Starfield Technologies, Inc.", L=Scottsdale, S=Ari
                     zona, C=US
NotAfter           : 7/10/2013 7:48:28 PM
NotBefore          : 8/16/2010 11:21:26 AM
PublicKeySize      : 2048
RootCAType         : Unknown
SerialNumber       : 07CC5DD86A1389
Services           : IMAP, POP, SMTP
Status             : Invalid
Subject            : CN=mail.domain.com, OU=Domain Control Validate
                     d, O=mail.domain.com
Thumbprint         : 9EB75E3719D6F5AE51A5111C354FF4B1B0660159

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System
                     .Security.AccessControl.CryptoKeyAccessRule, System.Securi
                     ty.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {mail.domain.com, www.mail.domain.
                     com, remote.domain.com, autodiscover.domain
                     .com, vpn.domain.com}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Au
                     thority, OU=http://certificates.godaddy.com/repository, O=
                     "GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
NotAfter           : 7/10/2013 7:48:28 PM
NotBefore          : 8/15/2010 5:48:14 PM
PublicKeySize      : 2048
RootCAType         : Unknown
SerialNumber       : 4ED5A1E6DC2454
Services           : IMAP, POP, SMTP
Status             : Invalid
Subject            : CN=mail.domain.com, OU=Domain Control Validate
                     d, O=mail.domain.com
Thumbprint         : 738525AA84B4C4078B33777F7A14E83FE55DD055

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System
                     .Security.AccessControl.CryptoKeyAccessRule, System.Securi
                     ty.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {remote.domain.com, www.remote.domain
                     .com}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Au
                     thority, OU=http://certificates.godaddy.com/repository, O=
                     "GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
NotAfter           : 7/12/2011 12:41:32 PM
NotBefore          : 7/12/2010 12:41:32 PM
PublicKeySize      : 2048
RootCAType         : ThirdParty
SerialNumber       : 040704DF22B2F2
Services           : IMAP, POP, IIS, SMTP
Status             : Valid
Subject            : CN=remote.domain.com, OU=Domain Control Valida
                     ted, O=remote.domain.com
Thumbprint         : 09B8EAF5F9F0C1B9713B7D8C5529E8BA8B3C4549

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System
                     .Security.AccessControl.CryptoKeyAccessRule, System.Securi
                     ty.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {remote.domain.com, domain.com, SERVER2
                     .domain.com.local}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : CN=domain-SERVER2-CA
NotAfter           : 7/11/2012 12:10:13 PM
NotBefore          : 7/12/2010 12:10:13 PM
PublicKeySize      : 2048
RootCAType         : Registry
SerialNumber       : 12308F7D000000000007
Services           : IMAP, POP, SMTP
Status             : Valid
Subject            : CN=remote.domain.com
Thumbprint         : 1ACD32DE960B7AC72200DEE428B44114F2C6CA0D

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System
                     .Security.AccessControl.CryptoKeyAccessRule, System.Securi
                     ty.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {mail.domain.com, domain.com,
                     SERVER2.domain.com.local}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : CN=domain-SERVER2-CA
NotAfter           : 7/9/2012 8:52:34 PM
NotBefore          : 7/10/2010 8:52:34 PM
PublicKeySize      : 2048
RootCAType         : Registry
SerialNumber       : 611DE59D000000000006
Services           : SMTP
Status             : Valid
Subject            : CN=mail.domain.com
Thumbprint         : D5803E3E8C4CE792B85AC3F06CB449324848C8C4

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System
                     .Security.AccessControl.CryptoKeyAccessRule, System.Securi
                     ty.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {remote.domain.com, domain.com,

                     SERVER2.domain.com.local}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : CN=domain-SERVER2-CA
NotAfter           : 7/9/2012 6:48:07 PM
NotBefore          : 7/10/2010 6:48:07 PM
PublicKeySize      : 2048
RootCAType         : Registry
SerialNumber       : 613D5512000000000005
Services           : IMAP, POP, SMTP
Status             : Valid
Subject            : CN=remote.domain.com
Thumbprint         : 0374D3F94D84823D55264B33A61CF5A620D24745

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System
                     .Security.AccessControl.CryptoKeyAccessRule, System.Securi
                     ty.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {SERVER2.domain.com.local}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : CN=domain-SERVER2-CA
NotAfter           : 7/10/2011 12:00:23 PM
NotBefore          : 7/10/2010 12:00:23 PM
PublicKeySize      : 2048
RootCAType         : Registry
SerialNumber       : 6118A978000000000004
Services           : SMTP
Status             : Valid
Subject            : CN=SERVER2.domain.com.local
Thumbprint         : 7F6CE96AE2381CCD550E298C6F76D311E9E09B96

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System
                     .Security.AccessControl.CryptoKeyAccessRule, System.Securi
                     ty.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {Sites, SERVER2.domain.com.local}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : CN=domain-SERVER2-CA
NotAfter           : 7/9/2012 11:53:20 AM
NotBefore          : 7/10/2010 11:53:20 AM
PublicKeySize      : 2048
RootCAType         : Registry
SerialNumber       : 61123514000000000002
Services           : SMTP
Status             : Valid
Subject            : CN=Sites
Thumbprint         : C414912765F826D54FEABC7702F2F2E96966EDD3

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System
                     .Security.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {domain-SERVER2-CA}
HasPrivateKey      : True
IsSelfSigned       : True
Issuer             : CN=domain-SERVER2-CA
NotAfter           : 7/10/2015 12:02:21 PM
NotBefore          : 7/10/2010 11:52:22 AM
PublicKeySize      : 2048
RootCAType         : Registry
SerialNumber       : 42F3CC1615EDE98349E9CC250CF66B50
Services           : None
Status             : Valid
Subject            : CN=domain-SERVER2-CA
Thumbprint         : 0AF04498DA1B878F222A5943131712F766667C81

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System
                     .Security.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {WMSvc-WIN-BTWLPS13FYV}
HasPrivateKey      : True
IsSelfSigned       : True
Issuer             : CN=WMSvc-WIN-BTWLPS13FYV
NotAfter           : 7/7/2020 3:37:40 AM
NotBefore          : 7/10/2010 3:37:40 AM
PublicKeySize      : 2048
RootCAType         : Registry
SerialNumber       : 22EF2DF3E7A13FA94A230BA610FB8307
Services           : None
Status             : Valid
Subject            : CN=WMSvc-WIN-BTWLPS13FYV
Thumbprint         : AD0B5EB58C2014B10FD396DE9E53BFED0E10EC15



0
 
LVL 9

Author Comment

by:dmessman
ID: 33501249
here are the results of get-webservicesvirtualdirectory | fl:





InternalNLBBypassUrl          : https://SERVER2.domain.com.local/
                                ews/exchange.asmx
Name                          : EWS (SBS Web Applications)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
BasicAuthentication           : True
DigestAuthentication          : False
WindowsAuthentication         : True
MetabasePath                  : IIS://SERVER2.domain.com.local/W3
                                SVC/3/ROOT/EWS
Path                          : C:\Program Files\Microsoft\Exchange Server\Clie
                                ntAccess\exchweb\EWS
Server                        : SERVER2
InternalUrl                   : https://remote.domain.com/EWS/Excha
                                nge.asmx
ExternalUrl                   : https://remote.domain.com/EWS/Excha
                                nge.asmx
AdminDisplayName              :
ExchangeVersion               : 0.1 (8.0.535.0)
DistinguishedName             : CN=EWS (SBS Web Applications),CN=HTTP,CN=Protoc
                                ols,CN=SERVER2,CN=Servers,CN=Exchange Adminis
                                trative Group (FYDIBOHF23SPDLT),CN=Administrati
                                ve Groups,CN=ORGANIZATION,CN=Microsoft Exchange,CN=
                                Services,CN=Configuration,DC=domain
                                ,DC=com,DC=local
Identity                      : SERVER2\EWS (SBS Web Applications)
Guid                          : 3cf4ab9e-4169-46f7-9b98-937e1de77f6d
ObjectCategory                : domain.com.local/Configuration/Sche
                                ma/ms-Exch-Web-Services-Virtual-Directory
ObjectClass                   : {top, msExchVirtualDirectory, msExchWebServices
                                VirtualDirectory}
WhenChanged                   : 7/10/2010 10:47:54 PM
WhenCreated                   : 7/10/2010 12:14:18 PM
OriginatingServer             : SERVER2.domain.com.local
IsValid                       : True



0
 
LVL 9

Author Comment

by:dmessman
ID: 33501280
here are the results of Get-clientAccessServer ¦ fl:





Name                           : SERVER2
OutlookAnywhereEnabled         : True
AutoDiscoverServiceCN          : SERVER2
AutoDiscoverServiceClassName   : ms-Exchange-AutoDiscover-Service
AutoDiscoverServiceInternalUri : https://remote.domain.com/Autodisc
                                 over/Autodiscover.xml
AutoDiscoverServiceGuid        : 77378f46-2c66-4aa9-a6a6-3e7a48b19596
AutoDiscoverSiteScope          : {DC}
IsValid                        : True
OriginatingServer              : SERVER2.domain.com.local
ExchangeVersion                : 0.1 (8.0.535.0)
DistinguishedName              : CN=SERVER2,CN=Servers,CN=Exchange Administra
                                 tive Group (FYDIBOHF23SPDLT),CN=Administrative
                                  Groups,CN=ORGANIZATION,CN=Microsoft Exchange,CN=S
                                 ervices,CN=Configuration,DC=domain
                                 ,DC=com,DC=local
Identity                       : SERVER2
Guid                           : 219ac6c2-ea0f-4d5c-bedd-92f0df22fda5
ObjectCategory                 : domain.com.local/Configuration/Sch
                                 ema/ms-Exch-Exchange-Server
ObjectClass                    : {top, server, msExchExchangeServer}
WhenChanged                    : 8/16/2010 11:26:07 AM
WhenCreated                    : 7/10/2010 12:10:46 PM



0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33501290
AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System
                     .Security.AccessControl.CryptoKeyAccessRule, System.Securi
                     ty.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {mail.domain.com, www.mail.domain.
                     com, remote.domain.com, autodiscover.domain
                     .com, vpn.domain.com}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : SERIALNUMBER=10688435, CN=Starfield Secure Certification A
                     uthority, OU=http://certificates.starfieldtech.com/reposit
                     ory, O="Starfield Technologies, Inc.", L=Scottsdale, S=Ari
                     zona, C=US
NotAfter           : 7/10/2013 7:48:28 PM
NotBefore          : 8/16/2010 11:21:26 AM
PublicKeySize      : 2048
RootCAType         : Unknown
SerialNumber       : 07CC5DD86A1389
Services           : IMAP, POP, SMTP
Status             : Invalid
Subject            : CN=mail.domain.com, OU=Domain Control Validate
                     d, O=mail.domain.com
Thumbprint         : 9EB75E3719D6F5AE51A5111C354FF4B1B0660159

=======

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System
                     .Security.AccessControl.CryptoKeyAccessRule, System.Securi
                     ty.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {mail.domain.com, www.mail.domain.
                     com, remote.domain.com, autodiscover.domain
                     .com, vpn.domain.com}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Au
                     thority, OU=http://certificates.godaddy.com/repository, O=
                     "GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
NotAfter           : 7/10/2013 7:48:28 PM
NotBefore          : 8/15/2010 5:48:14 PM
PublicKeySize      : 2048
RootCAType         : Unknown
SerialNumber       : 4ED5A1E6DC2454
Services           : IMAP, POP, SMTP
Status             : Invalid
Subject            : CN=mail.domain.com, OU=Domain Control Validate
                     d, O=mail.domain.com
Thumbprint         : 738525AA84B4C4078B33777F7A14E83FE55DD055

===========

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System
                     .Security.AccessControl.CryptoKeyAccessRule, System.Securi
                     ty.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {remote.domain.com, www.remote.domain
                     .com}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Au
                     thority, OU=http://certificates.godaddy.com/repository, O=
                     "GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
NotAfter           : 7/12/2011 12:41:32 PM
NotBefore          : 7/12/2010 12:41:32 PM
PublicKeySize      : 2048
RootCAType         : ThirdParty
SerialNumber       : 040704DF22B2F2
Services           : IMAP, POP, IIS, SMTP
Status             : Valid
Subject            : CN=remote.domain.com, OU=Domain Control Valida
                     ted, O=remote.domain.com
Thumbprint         : 09B8EAF5F9F0C1B9713B7D8C5529E8BA8B3C4549

==============================
a) >> First 2 Root CA Type = Unknown.

b) Certificate Domains
mail.domain.com,
www.mail.domain.com,
remote.domain.com,
autodiscover.domain.com,
vpn.domain.com

>> You just need 4

mail.domain.com (External FQDN)
autodiscover.domain.com (external SRV record)
mail.domain.local (internal FQDN)
mailservername (internal server name)

there are no cert's issued for internal FQDN. So even if you configure your internal Autodiscover to work, it will fail for UCC/SAN Cert.
You can re-key the certificate and have it issued for these 4

Here's how to do it.
http://help.godaddy.com/article/4976
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33501305
The rest of the cert's are issued by
Issuer             : CN=domain-SERVER2-CA

You can ignore / remove them. Dont do it just yet.
a) Check if the thumbprint from those are being used somewhere else.
b) re-key your godaddy cert.
b) Download the cert.
c) Use the u-btech tool to change / replace the certificate's
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33501329
dmessman

about your comment here
http:#33496874

This is why you are having these issues.

get-webservicesvirtualdirectory | fl:
InternalUrl                   : https://remote.domain.com/EWS/Exchange.asmx

Get-clientAccessServer ¦ fl:
AutoDiscoverServiceInternalUri : https://remote.domain.com/Autodiscover/Autodiscover.xml

Your autodiscover internal URL's and SCP's point to external - remote.domain.com

question:
a) Do you have a DNS entry in your internal DNS for
autodiscover.domain.local ?

thanks
0
 
LVL 32

Expert Comment

by:endital1097
ID: 33501426
The certificate used by your server for web services only has the name root.domain.com

check the configuration of your outlook anywhere, specifically the external hostname value

Get-OutlookAnywhere | fl

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System

                     .Security.AccessControl.CryptoKeyAccessRule, System.Securi

                     ty.AccessControl.CryptoKeyAccessRule}

CertificateDomains : {remote.domain.com, www.remote.domain

                     .com}

HasPrivateKey      : True

IsSelfSigned       : False

Issuer             : SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Au

                     thority, OU=http://certificates.godaddy.com/repository, O=

                     "GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US

NotAfter           : 7/12/2011 12:41:32 PM

NotBefore          : 7/12/2010 12:41:32 PM

PublicKeySize      : 2048

RootCAType         : ThirdParty

SerialNumber       : 040704DF22B2F2

Services           : IMAP, POP, IIS, SMTP

Status             : Valid

Subject            : CN=remote.domain.com, OU=Domain Control Valida

                     ted, O=remote.domain.com

Thumbprint         : 09B8EAF5F9F0C1B9713B7D8C5529E8BA8B3C4549

Open in new window

0
 
LVL 32

Expert Comment

by:endital1097
ID: 33501452
like @sunnyc7 stated, you need to have an internal dnz zone for domain.com that will resolve remote.domain.com to an internal address

otherwise your firewall will most likely look at these packets as spoofed when they come from the inside
0
 
LVL 9

Author Comment

by:dmessman
ID: 33501468
here are the results from  Get-OutlookAnywhere | fl:




ServerName                 : SERVER2
SSLOffloading              : False
ExternalHostname           : remote.domain.com
ClientAuthenticationMethod : Basic
IISAuthenticationMethods   : {Basic, Ntlm}
MetabasePath               : IIS://SERVER2.domain.com.local/W3SVC
                             /1/ROOT/Rpc
Path                       :
Server                     : SERVER2
AdminDisplayName           :
ExchangeVersion            : 0.1 (8.0.535.0)
Name                       : Rpc (Default Web Site)
DistinguishedName          : CN=Rpc (Default Web Site),CN=HTTP,CN=Protocols,CN=
                             SERVER2,CN=Servers,CN=Exchange Administrative Gr
                             oup (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=
                             SPITFIRE,CN=Microsoft Exchange,CN=Services,CN=Conf
                             iguration,DC=domain,DC=com,DC=local
Identity                   : SERVER2\Rpc (Default Web Site)
Guid                       : f27cf1d1-bf17-4b76-8ad1-be5fd813b115
ObjectCategory             : domain.com.local/Configuration/Schema/
                             ms-Exch-Rpc-Http-Virtual-Directory
ObjectClass                : {top, msExchVirtualDirectory, msExchRpcHttpVirtual
                             Directory}
WhenChanged                : 7/10/2010 6:58:24 PM
WhenCreated                : 7/10/2010 6:58:24 PM
OriginatingServer          : SERVER2.domain.com.local
IsValid                    : True
0
 
LVL 9

Author Comment

by:dmessman
ID: 33501718
sorry - I'm getting lots of information here, and not sure which step to follow next.

@sunnyc7, I do *not* have an internal DNS record for autodiscover.internaldomain.local.  So I'll create one that points to 10.0.0.2 (my SBS 2008 box).

It sounds like I also need to create an internal DNS record for remote.domain.com that points to my server's internal IP (10.0.0.2).  Easy enough.

But my users also had trouble using RPC over HTTPS from the outside with the UCC/SAN certificate.  As per my post here:
http://www.experts-exchange.com/Software/Server_Software/Email_Servers/Exchange/Q_26405749.html#a33447707

testexchangeconnectivity.com was telling me:

The certificate common name mail.domain.com, doesn't validate against Mutual Authentication string provided msstd:remote.domain.com


To me, the mismatch of mail.domain.com against remote.domain.com was the larger issue.  No?
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33501744
@sunnyc7, I do *not* have an internal DNS record for autodiscover.internaldomain.local.  So I'll create one that points to 10.0.0.2 (my SBS 2008 box).
>> YES to that.


It sounds like I also need to create an internal DNS record for remote.domain.com that points to my server's internal IP (10.0.0.2).  Easy enough.
>> No to that.
This doesnt affect autodiscover in any way.

To me, the mismatch of mail.domain.com against remote.domain.com was the larger issue.  No?
>> Hence the re-keying part posted above. http:#33501290

Copy-pasting

a) >> First 2 Root CA Type = Unknown.

b) Certificate Domains
mail.domain.com,
www.mail.domain.com,
remote.domain.com,
autodiscover.domain.com,
vpn.domain.com

>> You just need 4

mail.domain.com (External FQDN)
autodiscover.domain.com (external SRV record)
mail.domain.local (internal FQDN)
mailservername (internal server name)

there are no cert's issued for internal FQDN. So even if you configure your internal Autodiscover to work, it will fail for UCC/SAN Cert.
You can re-key the certificate and have it issued for these 4

Here's how to do it.
http://help.godaddy.com/article/4976
0
 
LVL 32

Expert Comment

by:endital1097
ID: 33501760
so the result of "get-outlookprovider expr" results in mail.domain.com and not remote.domain.com
0
Shouldn't all users have the same email signature?

You wouldn't let your users design their own business cards, would you? So, why do you let them design their own email signatures? Think of the damage they could be doing to your brand reputation! Choose the easy way to manage set up and add email signatures for all users.

 
LVL 9

Author Comment

by:dmessman
ID: 33501981
[PS] C:\Windows\system32>get-outlookprovider expr

Name                Server              CertPrincipalName   TTL
----                ------              -----------------   ---
EXPR                                    msstd:remote.spi... 1




The command shows: remote.domain.com - which it should

I think the issue is that the common name on my SAN SSL cert is mail.domain.com and remote.domain.com is one of the alternative names - though that scenario should be fine, I'd think.  I'm just going off the error that testexchangeconnectivity.com gave me
0
 
LVL 9

Author Comment

by:dmessman
ID: 33502001
@sunnyc7, regarding this post:
http://www.experts-exchange.com/Software/Server_Software/Email_Servers/Exchange/Q_26405749.html#a33501744

so you think I should abandon remote.domain.com in favor of mail.domain.com - I'm not going to do that.  I've alerted all my users to the change of mail.domain.com to remote.domain.com as per SBS 2008's preferences.  And I'd rather not make go back on waht I said.  So if my SSL cert's common name must match the mutual authentication string, I can revoke and get a new cert for remote.domain.com with SANs of mail.domain.com and then others.  
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33502022
What does your MX point to ?
Is it remote.domain.com or mail.domain.com

www.mxtoolbox.com
enter your domain name

if you have a external DNS entry for remote.domain.com and you've setup autodiscover with remote.domain.com -- as long as it's in the UCC/SAN (which it is) - it should work.

You need to re-key the cert form Godaddy anyway to get Autodiscover to work internally.
otherwise your internal Outlook will look @ external DNS on the web to get a resolution for Exchange on the LAN.

that is similar to - internal LAN users are connecting to local exchange over RPC/HTTPS.

Let me know if you've any questions.

thanks
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33502593
@dmessman
any comments on my post above on re-keying the certs ?
0
 
LVL 32

Expert Comment

by:endital1097
ID: 33502778
the EXPR setting will tell Exchange what server to use for the Outlook connection
so by setting this to remote.domain.com you need to ensure that that FQDN can be resolved internally
0
 
LVL 9

Author Comment

by:dmessman
ID: 33502798
What does your MX point to ?
Is it remote.domain.com or mail.domain.com

>> My  highest priority MX record goes to remote.domain.com


www.mxtoolbox.com
enter your domain name

if you have a external DNS entry for remote.domain.com and you've setup autodiscover with remote.domain.com -- as long as it's in the UCC/SAN (which it is) - it should work.

>> agreed


You need to re-key the cert form Godaddy anyway to get Autodiscover to work internally.
otherwise your internal Outlook will look @ external DNS on the web to get a resolution for Exchange on the LAN.

>>  My autodiscover worked normally when the SAN cert.  I'm not really worried about autodiscover.  My issue was RPC over HTTPS not working when the SAN cert was in place.  

that is similar to - internal LAN users are connecting to local exchange over RPC/HTTPS.

>> I can create a new SAN SSL cert with a common name of mail.domain.com and alternative names of remote.domain.com, autodiscover.domain.com.  But I don't see what we've changed that would eliminate the problem I had originally, RPC over HTTPS not working for XP users with Office 2007.  


0
 
LVL 9

Author Comment

by:dmessman
ID: 33502818
@endital1097

the EXPR setting will tell Exchange what server to use for the Outlook connection
so by setting this to remote.domain.com you need to ensure that that FQDN can be resolved internally

>> You mean that I should have remote.domain.com resolve to 10.0.0.2 on my internal DNS - I agree.
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33502833
a) Is your internal and external domain name same ?

0
 
LVL 32

Expert Comment

by:endital1097
ID: 33502841
what about hte functionality of outlook with regards to the web services (OOF, oab, free/busy)

do those features work on the xp machines with office 2007? trying to narrow down the issue.
0
 
LVL 9

Author Comment

by:dmessman
ID: 33502877
@sunnyc7:

a) Is your internal and external domain name same

>> no.  My external domain name is domain.com and my internal domain name is domain.com.local


@endital1097:

When my SAN cert was in place (about 3 days), autodiscover worked normally and all autodiscover services worked normally.  My only issue was RPC over HTTPS.  But what was weird was that it only affected XP users with office 2007, not Vista or 7 users with Office 2007.
0
 
LVL 32

Expert Comment

by:endital1097
ID: 33502946
view the certificate from Internet Explorer
the subject name on the cert is remote.domain.com
make sure under the SAN names that remote.domain.com is listed first
i have seen instances where XP doesn't like when the first name under SAN names is not the subject
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33503005
from XP machine, can you try this

This is for XP with outlook 2007 configured for RPC/HTTPS

outlook /rpcdiag

Lets see what we get.
Please post screenshots.
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33504024
dmessman
how's it going ?
0
 
LVL 9

Author Comment

by:dmessman
ID: 33525425
I've still got this on the brain.  I can't put the UCC cert on during the work week as it will disrupt users.  I'll put the UCC cert on over the weekend and take home an XP laptop - and then I'll be able to test.  As such, I'll have to report back on Monday.
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33525452
Sure. Let us know if you need any assistance with that.
You can use the u-btech tool from my post above to install the cert's

http:#33501140
0
 
LVL 9

Author Comment

by:dmessman
ID: 33566949
I used the u-btech tool to install the UCC/SAN cert.  After installing the cert, I open Outlook and the I get the standard login in Outlook when you're using RPC over HTTPS.  But the prompt does not accept the password presumably because of the same issue we've been discussing.  

I ran outlook /rpcdiag and the Microsoft Exchange Connection Status window comes up:

internalservername.internaldomainname.local     mail                         connecting



I went back to www.testexchangeconnectivity.com and I tested RPC over HTTPS.  It says "the RPC/HTTP test failed"

The reason for the failure is:

The certificate common name mail.domain.com, doesn't validate against Mutual Authentication string provided msstd:remote.domain.com




This really does seem like the issue (the error above about the mutual authentication string).  

I have to go back to the single name cert for now so my users can work.  


Scree shots below
rpc.JPG
testexch.JPG
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33566973
will post back - I am running out the door.
0
 
LVL 28

Accepted Solution

by:
sunnyc7 earned 250 total points
ID: 33568552
in outlook - what is the proxy address in MSSTD: field for RPC/HTTPS

Does this match the name in the certificate ?
0
 
LVL 9

Author Comment

by:dmessman
ID: 33568772
In Outlook Anywhere, I set the values as:

remote.domain.com

msstd:remote.domain.com


The cert's common name is mail.domain.com with alternate names of autodiscover.domain.com and remote.domain.com
0
 
LVL 32

Expert Comment

by:endital1097
ID: 33568996
view the certificate from Internet Explorer
the subject name on the cert is mail.domain.com
make sure under the SAN names that mail.domain.com is listed first
i have seen instances where XP doesn't like when the first name under SAN names is not the subject
0
 
LVL 9

Author Comment

by:dmessman
ID: 33678695
sorry guys - still working on this, hard to find time on weekends when I can put on the multiple name cert - since it screws up my users.  
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33678699
dmessman - if you havent given up hope / neither have we.

Post back when you are ready.
0
 
LVL 9

Author Comment

by:dmessman
ID: 33678748
actually, I just went in and used the btech tool to put in the UCC/SAN cert.  Below is the requested info in the cert that you can see in IE when viewing the cert.
SAN.png
cert-info.png
0
 
LVL 32

Assisted Solution

by:endital1097
endital1097 earned 250 total points
ID: 33681207
run the following
Set-OutlookProvider EXPR -CertPrincipalName msstd:mail.domain.com

your settings are for remote.domain.com, but the subject name of your cert is mail
0
 
LVL 9

Author Comment

by:dmessman
ID: 33718142
I left this alone for a bit to see if anyone else would comment - but this makes sense to me and jives with what www.testexchangeconnectivity.com was telling me:

---------

SSL mutual authentication with the RPC proxy server is being tested.
       Verification of mutual authentication failed.
        Tell me more about this issue and how to resolve it
       
      Additional Details
       The certificate common name mail.domain.com, doesn't validate against Mutual Authentication string provided msstd:remote.domain.com

---------

As per endital1097's comment, I either need to set my Exchange server so that it responds to msstd:mail.domain.com (see previous comment)

or

get a new cert where the subject/common name is remote.domain.com




I'm inclined to do the latter - as if I change the certPrincipalName - I'll have to reconfigure each Outlook client for msstd:mail.domain.com



sunny and endital1097 - do you agree?

0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33725315
You do not need to get a new cert.
You can re-key the old cert and add the necessary domain names in there, and then install it.

I'd focus on having the right domains on UCC/SAN rather than try engineering elsewhere and make it work.
0
 
LVL 9

Author Comment

by:dmessman
ID: 33727789
I wish I could rekey the cert so that I could get the common/subject name to be remote.domain.com - but it seems that no matter how I create the CSR (whether I do it in the Exchange shell or digicert's page at https://www.digicert.com/easy-csr/exchange2007.htm) - the subject for any cert that is created is mail.domain.com

But that's a godaddy thing.  I'll work that out with them.  I guess in the end  - what we're saying is that the value for msstd must match the subject/common name of the certificate.  I can handle that.
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33728000
here's the re-key guide for go daddy
http://help.godaddy.com/article/4976

Digicert's re-key guide is applicable if you purchased the UCC/SAN cert from digicert.

0
 
LVL 9

Author Comment

by:dmessman
ID: 33733656
Godaddy's response was this when I asked to change the subject/common name:

Once a certificate has been issued, you cannot change any of the certificate details, including the common name (website address). If you want to change any of these details, you will need to purchase and apply for a new certificate. We apologize for any inconvenience this may cause you.

So it looks like I'll have to revoke and get a new cert.
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33733753
Can you use the link above.
You can do this from your DNS manager account.

It's called re-keying the certificate.
This is for UCC/SAN cert I suppose.
0
 
LVL 9

Author Comment

by:dmessman
ID: 33785787
I have tested this and resolved my issue.  I revoked the UCC cert where the subject was mail.domain.com.  I got a new cert with the subject of remote.domain.com.  No problems.  

The result seems to have been that the value in "msstd:fqdn.domain.com" needs to be the subject not an alternative name in the cert.

Thanks all for your help.
0
 
LVL 9

Author Closing Comment

by:dmessman
ID: 33785798
As per my last comment - it seems that the common/subject name must match the value in msstd when setting up RPC over HTTPS.
0
 
LVL 28

Expert Comment

by:sunnyc7
ID: 33788259
Thanks for posting back and confirming the solution.
0

Featured Post

Why do Marketing keep bothering you?

Is your marketing department constantly asking for new email signature updates? Are they requesting a different design for every department? Do they need yet another banner added? Don’t let it get you down! There is an easy way to manage all of these requests...

Join & Write a Comment

"Migrate" an SMTP relay receive connector to a new server using info from an old server.
Not sure what the best email signature size is? Are you worried about email signature image size? Follow this best practice guide.
In this video we show how to create a Distribution Group in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Recipients >>…
To show how to create a transport rule in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Mail Flow >> Rules tab.:  To cr…

758 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now