Certification Authority and RPC/HTTPS

Make sure that the RapidSSL Certificate is installed on the Server.

In SBS 2003 all you ahve to do is assign the Certificate to the Web Site in Quesiton. i.e. Default Web Site.

Once this is done, you will need to import the RapidSSL Certificate on the Client PC's.

Then ensure the local name is in the "Server" section of the account and teh FQDN is in the RPC over HTTP Settings.

Did you run the CEICW (Configure e-mail and Internet Connection Wizard) and point to your Godaddy cert? Also port 443 must be forwarded from the router to the SBS.

BBRazz:

That seems to be setup correctly. I can see the certificate both on the server and on the client and the certificate is assigned to the default website. Local name and FQDN are both correct on the client. I was just wondering if the Certification Authority name might be causing the problem. Thanks for the input!

RobWill:

I believe I did rerun it, so just to be sure I am doing it again. I am receiving this message when I point to the RapidSSL certificate:

"No certificate has been requested for the default Web site in Internet Information Services (IIS).
To use a Web server certificate from a trusted authority, you must first create a request for a certificate by using the Web Server Certificate Wizard in IIS. You can then run this wizard again to configure the default Web site to use a trusted certificate".

I had done this previously when I submitted the CSR to RapidSSL. Do I need to redo this within CEICW?

Thanks!

If you have carried out the CSR and had a new Certificate supplied, then it is recommended to run the CEICW again.

I am attempting to rerun the CEICW, but it won't let me get past the above message.

Sorry, I said Godaddy above. My preference would be RapidSSL as well. Have you reviewed the following:
http://www.rapidssl.com/ssl-certificate-support/install-ssl-certificate/exchange-owa.html
I am surprised you are getting that error. I haven't run into that before. Generally if it is already installed you just breeze through that step, assuming there is no name conflict.

If you go to IIS and remove any existing certificate and then then configure the default web site to use the RapidSSL Certificate, can you then try the CEICW?

If that fails, I suggest removing the SSL certificate and recreating the CSR with IIS and requesting a new certificate for the IIS Application.

As a test, it may be worth trying a Self Signed SSL to rule out any other configuration issues.

http://www.msexchange.org/tutorials/SSL_Enabling_OWA_2003.html

Yes. I followed that link to install the certificate so I am not sure why the CEICW is complainiing. The certificate and the public name of the server are identical (mail.domain.com). Any thoughts?

Lets try rule out the RapidSSL Certificate.

Delete the Certificate from IIS and remove it from the Local Certificate Repository

(Start > Run > mmc.exe - Add the Certificates Snap In)
Find the certificate in question and delete.

Now install a Self Signed Certificate as a Test.

    * Download IIS 6.0 Resource Kit Tools
    * Install the resource kit (requires Windows Server 2003, Windows XP)
    * From the Windows Start Menu, go to the "\Programs\IIS Resources\SelfSSL" folder and select "SelfSSL".
    * Instructions will be listed in a command prompt. Type "selfssl" to run the program.
    * Type "y" to confirm overriding/installing the certificate on the given site.
    * Test that it worked by visiting https://localhost/.

Once this has been done, carry out the CEICW again.

Okay. I have removed the RapidSSL certificate, downloaded and installed IIS 6.0 Resource Kit Tools and run the SelfSSL program (it used the server name instead of the actual public name). I can browse to CompanyWeb using https://localhost. Now, when I rerun the CEICW which of the three options should I take for the certificate:

Create a new Web certificate
Use a Web certificate from a trusted authority
Do not change the current Web certificate

Try choosing "Use a Web certificate from a trusted authority" and point to your RapidSSL cert.

For more background, the DomainCA name is just the name of the CA - the nomenclature for it does not matter it can be named anything.  This could also be shown as ServerName.Domain.com\DomainCA.

At this point I do not think that you will need to reinstall the CA, but just for reference when you uninstall the CA it will automatically revoke all issued certificates.  So if you reinstall you would have to reissue and redistribute all certificates again (web, user, smartcards, etc.) - this is as big of a deal as you determine it to be based on what and how many certs you already have issued.

I still got the same message. What I then did was ran the CEICW with the self-generated certificate went into IIS and replaced it with the RapidSSL certificate. Then I reran CEICW and the web server name was showing the correct certicate name (mail.domain.com). I told it not to change the current certificate and CEICW completed normally. In IIS, the Default web site is showing the RapidSSL certificate. Unfortunately, I still cannot connect with RPC/HTTPS from the outside. The connection starts with HTTPS and that connection disappears and the Status remains on "connecting". The RapidSSL certificate is installed on the remote machine in the Trusted Root Certification Authorities both for the Current User and the Local Machine. I don't see any other certificates issued by the SBS server. I can browse to OWA with no problem. Outlook 2003 is setup to use the server name (server.domain.com) for the Exchange Server and the connection is set to use "https://mail.domain.com" for the URL proxy server and "msstd:mail.domain.com". Authentication is set to basic. I don't want to have to reinstall the CA unless it is absolutely neccesary. Connection works fine internally (except the connection says TCP/IP with an RPC of Async--I have neard that this is normal inside). I don't want to reinstall the CA unless it is positively the root problem, so I am stumped.

Incidentally, this is what the log is showing when I try to connect remotely:

2008-07-22 19:10:21 65.XXX.XXX.XXX RPC_IN_DATA /rpc/rpcproxy.dll SERVER1:6004 443 DOMAIN\CBT 209.183.51.42 MSRPC 200 0 0 36 387
2008-07-22 19:10:21 65.XXX.XXX.XXX RPC_OUT_DATA /rpc/rpcproxy.dll SERVER1:6004 443 DOMAIN\CBT 209.183.51.42 MSRPC 200 0 0 36 352
2008-07-22 19:10:29 65.XXX.XXX.XXX RPC_IN_DATA /rpc/rpcproxy.dll SERVER1:6001 443 DOMAIN\CBT 209.183.51.42 MSRPC 200 0 0 36 387
2008-07-22 19:10:29 65.XXX.XXX.XXX RPC_OUT_DATA /rpc/rpcproxy.dll SERVER1:6001 443 DOMAINCBT 209.183.51.42 MSRPC 200 0 0 36 352

If you run outlook.exe /rpcdiag on the clients can you tell me if any connections get established?

I get a brief glimpse of HTTPS in the Conn, but it goes away very quickly. Initially, the server name shows "Server1.domain.com" then it switches to "Server1". The other fields are always empty, nothing like viewing an internal connection which shows:

Server Name: server1.domain.com
Directory, Mail, Public Folders
Interface: Intel PRO/100
Conn: TCP/IP
Status: Established
Req/Fail: 2/1, 766/1, etc.
RPC: Async
Etc.

Remotely, I only see:

Server name: Server1
Type: Directory
Status: Disconnected

Reconnecting does nothing.

Yes. The Microsoft Exchange Server is listed as server1.domain.com which is the local name of the server. The other two options are also correct. Basic authentication is enabled. In the article that you referenced above it mentions that  the Outlook profile must be created while the client is on the internal network. Is this correct? It doesn't make sense for someone to haul their desktop into the office to configure this. Anyways, I had been connecting via VPN previously with no problems and everything would sync just fine. Also, ActiveSync push email is working fine.

Forgot to mention that there is no ISA server in the equation here. Thanks!

I have done that and it is configured per the link. That's the real drag is that everything looks right, but there is some little part missing or mis-configured. Argh!

Paranormastic:

I can connect when I am on the internal network. I am currently connected inside with the same settings that I have tried from outside.

Other SSL apps work fine (RWW, OWA).

I will take a look at the links, but the odds are I have already been over them. I have been Googling like crazy :)

I finally used a support case with Microsoft. They determined that IPv6 was installed as a protocol on one of the NIC cards and they RPC/HTTP was getting confused. After removing the IPv6 protocol and rebooting, everything worked fine. So the cert was good, the ports were good and even tho the IPv6 was not enabled, it caused an issue. Thanks for the help and I have awarded points accordingly.

Very interesting, and thank you for updating ctsuhako.
Cheers !
--Rob

I never would have thought to look there! But I'm glad this ordeal is over and hopefully someone else can benefit. Cheers and thanks!

ctsuhako, it would be good if you could post your results in the comment box for others to see. Posting in the "accepted" area only allows those awarded points and you to see. A feature I am not fond of. That way as you said, others will be able to benefit.
Thanks,
--Rob

For posterity, here's the comments on this interesting issue:
[Microsoft] determined that IPv6 was installed as a protocol on one of the NIC cards and they RPC/HTTP was getting confused. After removing the IPv6 protocol and rebooting, everything worked fine. So the cert was good, the ports were good and even tho the IPv6 was not enabled, it caused an issue.