RPC over HTTPS not working on Outlook 2007 clients on XP on SBS 2008 after weekend SSL changes
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?
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?
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
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
i would first try browsing to an internal url for your web services
get-webservicesvirtualdire
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
get-webservicesvirtualdire
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
ASKER
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 ?
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 ?
ASKER
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?
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?
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.
ASKER
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.
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.
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
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.
ASKER
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.c
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?
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.c
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?
Do you have a dns entry for autodiscover.domain.com that also points to your external IP address?
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.
ASKER
@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.
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.
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
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
dmessman
Where are you with this issue.
Can we try a few commands and check your config:
get-exchangecertificate | fl
get-webservicesvirtualdire
Get-clientAccessServer ¦ fl
Please post the results here.
thanks
Where are you with this issue.
Can we try a few commands and check your config:
get-exchangecertificate | fl
get-webservicesvirtualdire
Get-clientAccessServer ¦ fl
Please post the results here.
thanks
ASKER
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?
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.
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.
ASKER
@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.
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.
on exchange shell run this
get-autodiscovervirtualdir
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)
get-autodiscovervirtualdir
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)
do all of the autodiscover features work on the XP machines (OOF, OAB, free/busy)?
you want to look at the following to get a better understanding of these settings
https://www.experts-exchange.com/Software/Server_Software/Email_Servers/Exchange/A_3585-Exchange-Autodiscover-Service-OOF-and-OAB.html
https://www.experts-exchange.com/Software/Server_Software/Email_Servers/Exchange/A_3585-Exchange-Autodiscover-Service-OOF-and-OAB.html
ASKER
here are the results of get-exchangecertificate | fl
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
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 : 0C501613E7C001A14D6BFE4420
Services : None
Status : Valid
Subject : C=US, S=DC, L=Washington, O=ORGANIZATION, OU=na, CN=remote.
domain.com
Thumbprint : 3BD6FD7135360B760A4F54F5F7
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 9EB75E3719D6F5AE51A5111C35
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 738525AA84B4C4078B33777F7A
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 09B8EAF5F9F0C1B9713B7D8C55
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 1ACD32DE960B7AC72200DEE428
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : D5803E3E8C4CE792B85AC3F06C
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 0374D3F94D84823D55264B33A6
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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.loca
Thumbprint : 7F6CE96AE2381CCD550E298C6F
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : C414912765F826D54FEABC7702
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
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 : 42F3CC1615EDE98349E9CC250C
Services : None
Status : Valid
Subject : CN=domain-SERVER2-CA
Thumbprint : 0AF04498DA1B878F222A594313
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
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 : 22EF2DF3E7A13FA94A230BA610
Services : None
Status : Valid
Subject : CN=WMSvc-WIN-BTWLPS13FYV
Thumbprint : AD0B5EB58C2014B10FD396DE9E
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
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 : 0C501613E7C001A14D6BFE4420
Services : None
Status : Valid
Subject : C=US, S=DC, L=Washington, O=ORGANIZATION, OU=na, CN=remote.
domain.com
Thumbprint : 3BD6FD7135360B760A4F54F5F7
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 9EB75E3719D6F5AE51A5111C35
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 738525AA84B4C4078B33777F7A
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 09B8EAF5F9F0C1B9713B7D8C55
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 1ACD32DE960B7AC72200DEE428
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : D5803E3E8C4CE792B85AC3F06C
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 0374D3F94D84823D55264B33A6
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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.loca
Thumbprint : 7F6CE96AE2381CCD550E298C6F
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : C414912765F826D54FEABC7702
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
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 : 42F3CC1615EDE98349E9CC250C
Services : None
Status : Valid
Subject : CN=domain-SERVER2-CA
Thumbprint : 0AF04498DA1B878F222A594313
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
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 : 22EF2DF3E7A13FA94A230BA610
Services : None
Status : Valid
Subject : CN=WMSvc-WIN-BTWLPS13FYV
Thumbprint : AD0B5EB58C2014B10FD396DE9E
ASKER
here are the results of get-webservicesvirtualdire
InternalNLBBypassUrl : https://SERVER2.domain.com.local/
ews/exchange.asmx
Name : EWS (SBS Web Applications)
InternalAuthenticationMeth
ExternalAuthenticationMeth
BasicAuthentication : True
DigestAuthentication : False
WindowsAuthentication : True
MetabasePath : IIS://SERVER2.domain.com.l
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=P
ols,CN=SERVER2,CN=Servers,
trative Group (FYDIBOHF23SPDLT),CN=Admin
ve Groups,CN=ORGANIZATION,CN=
Services,CN=Configuration,
,DC=com,DC=local
Identity : SERVER2\EWS (SBS Web Applications)
Guid : 3cf4ab9e-4169-46f7-9b98-93
ObjectCategory : domain.com.local/Configura
ma/ms-Exch-Web-Services-Vi
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
InternalNLBBypassUrl : https://SERVER2.domain.com.local/
ews/exchange.asmx
Name : EWS (SBS Web Applications)
InternalAuthenticationMeth
ExternalAuthenticationMeth
BasicAuthentication : True
DigestAuthentication : False
WindowsAuthentication : True
MetabasePath : IIS://SERVER2.domain.com.l
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=P
ols,CN=SERVER2,CN=Servers,
trative Group (FYDIBOHF23SPDLT),CN=Admin
ve Groups,CN=ORGANIZATION,CN=
Services,CN=Configuration,
,DC=com,DC=local
Identity : SERVER2\EWS (SBS Web Applications)
Guid : 3cf4ab9e-4169-46f7-9b98-93
ObjectCategory : domain.com.local/Configura
ma/ms-Exch-Web-Services-Vi
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
ASKER
here are the results of Get-clientAccessServer ¦ fl:
Name : SERVER2
OutlookAnywhereEnabled : True
AutoDiscoverServiceCN : SERVER2
AutoDiscoverServiceClassNa
AutoDiscoverServiceInterna
over/Autodiscover.xml
AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e
AutoDiscoverSiteScope : {DC}
IsValid : True
OriginatingServer : SERVER2.domain.com.local
ExchangeVersion : 0.1 (8.0.535.0)
DistinguishedName : CN=SERVER2,CN=Servers,CN=E
tive Group (FYDIBOHF23SPDLT),CN=Admin
Groups,CN=ORGANIZATION,CN=
ervices,CN=Configuration,D
,DC=com,DC=local
Identity : SERVER2
Guid : 219ac6c2-ea0f-4d5c-bedd-92
ObjectCategory : domain.com.local/Configura
ema/ms-Exch-Exchange-Serve
ObjectClass : {top, server, msExchExchangeServer}
WhenChanged : 8/16/2010 11:26:07 AM
WhenCreated : 7/10/2010 12:10:46 PM
Name : SERVER2
OutlookAnywhereEnabled : True
AutoDiscoverServiceCN : SERVER2
AutoDiscoverServiceClassNa
AutoDiscoverServiceInterna
over/Autodiscover.xml
AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e
AutoDiscoverSiteScope : {DC}
IsValid : True
OriginatingServer : SERVER2.domain.com.local
ExchangeVersion : 0.1 (8.0.535.0)
DistinguishedName : CN=SERVER2,CN=Servers,CN=E
tive Group (FYDIBOHF23SPDLT),CN=Admin
Groups,CN=ORGANIZATION,CN=
ervices,CN=Configuration,D
,DC=com,DC=local
Identity : SERVER2
Guid : 219ac6c2-ea0f-4d5c-bedd-92
ObjectCategory : domain.com.local/Configura
ema/ms-Exch-Exchange-Serve
ObjectClass : {top, server, msExchExchangeServer}
WhenChanged : 8/16/2010 11:26:07 AM
WhenCreated : 7/10/2010 12:10:46 PM
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 9EB75E3719D6F5AE51A5111C35
=======
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 738525AA84B4C4078B33777F7A
===========
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 09B8EAF5F9F0C1B9713B7D8C55
==========================
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
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 9EB75E3719D6F5AE51A5111C35
=======
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 738525AA84B4C4078B33777F7A
===========
AccessRules : {System.Security.AccessCon
.Security.AccessControl.Cr
ty.AccessControl.CryptoKey
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 : 09B8EAF5F9F0C1B9713B7D8C55
==========================
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
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
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
dmessman
about your comment here
http:#33496874
This is why you are having these issues.
get-webservicesvirtualdire
InternalUrl : https://remote.domain.com/EWS/Exchange.asmx
Get-clientAccessServer ¦ fl:
AutoDiscoverServiceInterna
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
about your comment here
http:#33496874
This is why you are having these issues.
get-webservicesvirtualdire
InternalUrl : https://remote.domain.com/EWS/Exchange.asmx
Get-clientAccessServer ¦ fl:
AutoDiscoverServiceInterna
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
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
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
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
otherwise your firewall will most likely look at these packets as spoofed when they come from the inside
ASKER
here are the results from Get-OutlookAnywhere | fl:
ServerName : SERVER2
SSLOffloading : False
ExternalHostname : remote.domain.com
ClientAuthenticationMethod
IISAuthenticationMethods : {Basic, Ntlm}
MetabasePath : IIS://SERVER2.domain.com.l
/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
SERVER2,CN=Servers,CN=Exch
oup (FYDIBOHF23SPDLT),CN=Admin
SPITFIRE,CN=Microsoft Exchange,CN=Services,CN=Co
iguration,DC=domain,DC=com
Identity : SERVER2\Rpc (Default Web Site)
Guid : f27cf1d1-bf17-4b76-8ad1-be
ObjectCategory : domain.com.local/Configura
ms-Exch-Rpc-Http-Virtual-D
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
ServerName : SERVER2
SSLOffloading : False
ExternalHostname : remote.domain.com
ClientAuthenticationMethod
IISAuthenticationMethods : {Basic, Ntlm}
MetabasePath : IIS://SERVER2.domain.com.l
/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
SERVER2,CN=Servers,CN=Exch
oup (FYDIBOHF23SPDLT),CN=Admin
SPITFIRE,CN=Microsoft Exchange,CN=Services,CN=Co
iguration,DC=domain,DC=com
Identity : SERVER2\Rpc (Default Web Site)
Guid : f27cf1d1-bf17-4b76-8ad1-be
ObjectCategory : domain.com.local/Configura
ms-Exch-Rpc-Http-Virtual-D
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
ASKER
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.internaldomai
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:
https://www.experts-exchange.com/questions/26405749/RPC-over-HTTPS-not-working-on-Outlook-2007-clients-on-XP-on-SBS-2008-after-weekend-SSL-changes.html?anchorAnswerId=33447707#a33447707
testexchangeconnectivity.c
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?
@sunnyc7, I do *not* have an internal DNS record for autodiscover.internaldomai
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:
https://www.experts-exchange.com/questions/26405749/RPC-over-HTTPS-not-working-on-Outlook-2007-clients-on-XP-on-SBS-2008-after-weekend-SSL-changes.html?anchorAnswerId=33447707#a33447707
testexchangeconnectivity.c
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?
@sunnyc7, I do *not* have an internal DNS record for autodiscover.internaldomai
>> 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
>> 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
so the result of "get-outlookprovider expr" results in mail.domain.com and not remote.domain.com
ASKER
[PS] C:\Windows\system32>get-ou
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.c
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.c
ASKER
@sunnyc7, regarding this post:
https://www.experts-exchange.com/questions/26405749/RPC-over-HTTPS-not-working-on-Outlook-2007-clients-on-XP-on-SBS-2008-after-weekend-SSL-changes.html?anchorAnswerId=33501744#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.
https://www.experts-exchange.com/questions/26405749/RPC-over-HTTPS-not-working-on-Outlook-2007-clients-on-XP-on-SBS-2008-after-weekend-SSL-changes.html?anchorAnswerId=33501744#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.
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
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
@dmessman
any comments on my post above on re-keying the certs ?
any comments on my post above on re-keying the certs ?
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
so by setting this to remote.domain.com you need to ensure that that FQDN can be resolved internally
ASKER
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.
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.
ASKER
@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.
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.
a) Is your internal and external domain name same ?
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.
do those features work on the xp machines with office 2007? trying to narrow down the issue.
ASKER
@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.
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.
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
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
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.
This is for XP with outlook 2007 configured for RPC/HTTPS
outlook /rpcdiag
Lets see what we get.
Please post screenshots.
dmessman
how's it going ?
how's it going ?
ASKER
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.
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
You can use the u-btech tool from my post above to install the cert's
http:#33501140
ASKER
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.interna
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
I ran outlook /rpcdiag and the Microsoft Exchange Connection Status window comes up:
internalservername.interna
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
will post back - I am running out the door.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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
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
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
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
ASKER
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.
dmessman - if you havent given up hope / neither have we.
Post back when you are ready.
Post back when you are ready.
ASKER
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
SAN.png
cert-info.png
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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?
---------
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?
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.
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.
ASKER
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.
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.
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.
http://help.godaddy.com/article/4976
Digicert's re-key guide is applicable if you purchased the UCC/SAN cert from digicert.
ASKER
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.
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.
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.
You can do this from your DNS manager account.
It's called re-keying the certificate.
This is for UCC/SAN cert I suppose.
ASKER
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.
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.
ASKER
As per my last comment - it seems that the common/subject name must match the value in msstd when setting up RPC over HTTPS.
Thanks for posting back and confirming the solution.
https://www.testexchangeconnectivity.com/