Link to home
Start Free TrialLog in
Avatar of dtooth71
dtooth71

asked on

rpc-http certificate

I am in the configuration stages of setting up rpc-http on my exchange 2003 server and am a bit confused about the SSL certificate.  In the Proceedure to configure RPC virtual Directory in IIS, step 8 it suggests to ensure that a valid SSL certificate is installed on the virtual server. I used the following site;
http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3RPCHTTPDep/ee9b228f-db48-4860-8bfd-3195881b8980.mspx?mfr=true

So I notice that the server has a wizard that I can create a SSL certificate and I also know that I can purchase from a vendor such as verisign.  However, I am unclear on a few things...

1) what is the differnce between a server made certificate and a purchased certificate? pros/cons of each
2) I want to use this certificate for rpc-http, after applying the certificate how will this affect the other users that hit the exchange box that are not rpc-http clients? ie: regular exchange mail users, OWA users, ect.


Avatar of Sembee
Sembee
Flag of United Kingdom of Great Britain and Northern Ireland image

A home grown certificate will not be trusted by the clients. You would have to install the certificate on to each client individually. When the certificate expires, you would then have to replace it on each client.

Therefore I always recommend a purchased certificate - although you don't have to go to Verisign, a StarterSSL certificate from RapidSSL for $69 will be fine.
I have more on home grown certificates on my blog: http://www.sembee.co.uk/archive/2006/03/05/5.aspx

For regular use of the Exchange server, it will have no effect. You can use the same certificate to secure OWA/OMA etc. Outlook will be unaffected, other than those that you configure to use RPC over HTTPS.

Simon.
Avatar of dtooth71
dtooth71

ASKER

Will I have to specifically assign the certificae to OWA or by putting the certificate on the server will do it?
Putting the certificate on to the default web site is usually sufficient if you haven't changed any of the configuration of the web server from default.

Simon.
what will the users of the OWA see as far as a change, if anything?  Or will the visual logon process be the same?
Unless you enable forms based authentication then OWA users will not see any changes. SSL does allow you to use the web page login screen, which many of my clients prefer.

Simon.
I am going to give the starter SSL cert a try. I will post back Simon, thanks.
Simon, I am re-re3ading your post on 7/3/2006> The web page login screen is the default logon correct?  And if SL does not allow this Then I will have to change to form based authentication?? is this correct?
The web page type login is not enabled by default unless you are using SBS.
Furthermore it is not seen unless you are using SSL.

So if you hit the server with the address http://servername.domain.com/exchange then you will get a regular username/password prompt - whether or not you have FBA enabled*
If you hit the server with https://servername.domain.com/exchange then you will get the regular username and password prompt UNLESS you have FBA enabled, then you will get the web page.

* It is possible with some hacks to get the FBA page to come up without SSL, but I doubt whether you have made those changes.

Simon.
this certificate I get should I get it for the domain name .....www.domain.com or does it need to have the mail server in the name as well? mail.domain.com??
That is up to you.

As a rule I don't use www for anything other than a public web site. I do not use it for private things like OWA.
I also don't use the server's real name. So if the server is called server1.domain.com then I do not use that as the SSL certificate.

mail.domain.com is the most common format used.

Simon.
I ask because I got the certificate for www.domain.com and it is not working.  should I change the certificate to another name?
Where does www.domain.com point to? The name on the certificate doesn't matter - as long as it resolves to the correct place.

Simon.
oh, it points to another IP, We outsource our web. so I guess it is resolving outside our domain.  so I will need to change the certificate then?
If it points outside, then you will need to use another name. External users will not be able to connect in because the address on the certificate goes elsewhere.

If you already have a host setup for your MX record to allow email to be delivered by SMTP, then use that.

Simon.
so bear with me Simon, I need to get it right this time.  I should change the certificate to the name of what my MX record is? and I used this link to verify my MX http://www.mxtoolbox.com/index.aspx.
 is this correct?
You don't have to use what the MX record is. It was just a suggestion. If your email is being delivered to you directly then you will already have that host setup - so there are no DNS changes to be made.

You can confirm the MX record address using any of the internet tools. DNSSTUFF.com is another one.

Simon.
I was just thinking that if my certificate is pointing to an outside IP then maybe that is why it is not working.  Our domain www.domain.com is outsourced ( the actual web site, which has an outside IP). My mail server is on site?????
You must have a host or something pointing to your internal email server?

Even if the web site is outsourced, getting traffic to your own server isn't an issue. At most you would ask the people who look after your DNS (could be the domain name registrar or the web host) to put a new entry in to the DNS for a host - so that mail.domain.com (for example) resolved to your external IP address.

If you don't have a host pointing at your own server, then what may be happening is that there is a wildcard in the domain and the name is resolving to something else - probably the web server.

Simon.
I didnt realize that this was going to be so difficult.  I got a test certificate that points at mail.domain.com.  now I get the dialog box to log onto the exchange server while opening Outlook but the status still goes to disconnected.  I am at a loss now I have verified the settings on the exchange server, IIS and the client from http://www.petri.co.il/ and still nothing. I also noticed my firewall logs and made adjustments there to allow TCP 443.   I am sure I am missing something small but.......any ideas?????
I might add that when I do get prompt while logging on to Outlook the dialog box says "connect to servername.domain.com"  after I enter my credentials status is trying to connect for a minute or so and then it says dissconnected.............rrrrrr
RPC over HTTPS either works, or it doesn't. No half measures.
Is the machine that you are testing with a member of the domain? If so, you shouldn't be getting a username and password prompt.

Make sure that in IIS Manager, on the /rpc virtual directory, that both integrated and basic authentication are enabled and anonymous is NOT enabled.

Simon.
yes I am using a laptop that is a part of the domain.  But when I was testing I was off-site.  While inside the domain I do not get the credential box.

IIS mngr/rpc virtual directory; integrated and basic are checked ONLY and default domain I have selected my domain. all other options are not selected.


does it matter that my cerificate says "mail.domain.com", and the logon dialog box says "connecting to servername.domain.com"?

I am using a single server senerio and in all the reading I read is says this is possible.  BUT when I select RPC-HTTP backend sever in the Exchange system manager on the properties of the server I get an error that reads "there is no front end server.  there must at least be one in your organization before the back end can be accessed."  In my reading it said just to clock OK....just wnated to mention that.  
It shouldn't matter whether the laptop is on or off site. If it is a member of the domain you should not get a username and password prompt.

Are you sure that the feature is working inside?

Close Outlook, making sure that outlook.exe is not listed in task manager.
Then click Start, Run and type

outlook.exe /rpcdiag

That will start Outlook with an extra box. In that box it will show the connection type. All components should say https. If they say TCP/IP then it is not working.

The difference between the certificate and the servername shouldn't matter. The servername is the real name of the server. As long as it is the correct servername (ie the name of the Exchange server) then you are fine.

The backend option error in ESM is also normal when you don't have a frontend and can be ignored.

Simon.
yes, that is what I just did, outlook.exe /rpcdiag> results are TCP/IP...
Does the name on your certificate resolve internally to the correct IP address?
It should be an internal IP address, not the external IP.

Simon.
how can I verify this?
Ping the certificate name from a machine inside. See what it says is the IP address.

Simon.
The IP address that shows is the address of the exchange box.  I also did nslookup set type=MX and then typed in the certificate name and the results were the same////
which all are mail.domain.com
The MX records would have nothing to do with this feature. It is a pure web/exchange setting.

If you browse to http://mail.domain.com/rpc what happens?
You should get an authentication prompt. It will fail three times and then give an error.

Simon.
"http://mail.domain.com/rpc", this is what I get


The page must be viewed over a secure channel
The page you are trying to access is secured with Secure Sockets Layer (SSL).
--------------------------------------------------------------------------------

Please try the following:

Type https:// at the beginning of the address you are attempting to reach and press ENTER.
HTTP Error 403.4 - Forbidden: SSL is required to view this resource.
Internet Information Services (IIS)

--------------------------------------------------------------------------------

Technical Information (for support personnel)

Go to Microsoft Product Support Services and perform a title search for the words HTTP and 403.
Open IIS Help, which is accessible in IIS Manager (inetmgr), and search for topics titled About Security, Secure Sockets Layer (SSL), and About Custom Error Messages.



If I type in the "https://mail.domain.com/rpc" I get this


The page cannot be displayed
There is a problem with the page you are looking for and it cannot be displayed. This error can occur if you are trying to display an HTML page that resides in a directory that is configured to allow Execute or Script permissions only.
--------------------------------------------------------------------------------

Please try the following:

Contact the Web site administrator if you believe this directory should allow read access.
HTTP Error 403.2 - Forbidden: Read access is denied.
Internet Information Services (IIS)

--------------------------------------------------------------------------------

Technical Information (for support personnel)

Go to Microsoft Product Support Services and perform a title search for the words HTTP and 403.
Open IIS Help, which is accessible in IIS Manager (inetmgr), and search for topics titled Using Virtual Directories, Changing Default Web Site Settings, and About Custom Error Messages


That was my mistake on the URL, I meant the HTTPS version.

What is the host OS of the box? Windows 2003 - with or without a service pack?

The error you should have got was

HTTP Error 401.3 - Unauthorized: Access is denied due to an ACL set on the requested resource.
Internet Information Services (IIS)

Simon.
OS is 2003 no SP. Exchange SP1, IIS version 6

Any reason you are so far out of date?
Exchange 2003 SP2 is almost 12 months old and the behaviour of RPC over HTTPS was changed slightly in Windows 2003 SP1.

Simon.
no reason I am aware of.
I still need to get the rpc-http working I have a deadline of the end of the week......any other ideas why I am not getting a HTTP connection and only TCP/IP?
As I stated a long way back, this feature either works, or it doesn't.
Getting TCP/IP means that it isn't working for some reason or another.

The usual causes are...

1. Name resolution is wrong. The name on the SSL certificate resolves to an external address rather than an internal address.
2. SSL Certificate problems - not trusted, wrong name etc.
3. Registry settings. While you shouldn't have to set the registry with an FE/BE, I have had to resort to that in the past.
4. Authentication settings wrong - anonymous being enabled on the /rpc virtual directory being the major one.

That is of course presuming that the requirements for RPC over HTTPS have been met - Exchange 2003 on Windows 2003 for both frontend and backend, and member of at least a mixed Windows 2003 domain with at least one Windows 2003 GC/DC.

Simon.
If from the outside mail.doamin.com resolves to an external address but then resolves through NAT to an internal address is this OK?  I have been questioning the certificate name from the start.....

registry settings I made were to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy. I changed valid ports from ServerNETBIOSName:100-5000
to
ServerNETBIOSName:6001-6002;ServerFQDN:6001-6002;ServerNetBIOSName:6004;ServerFQDN:6004
other than that I made no manual registry changes.  I also verified that the three registry settings that are installed b default.
 http://www.petri.co.il/configure_rpc_over_https_on_a_single_server.htm

I also verified the rpc virtual settings which aanonymous is unchecked.

I have checked the system requirements.  I have 2003 OS/Exchange on my single server it is the DC/GC server also.
ASKER CERTIFIED SOLUTION
Avatar of Sembee
Sembee
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
The Domain controller registry changes-all senerios> That was in my registry all ready/

I had but removed the server:100-5000 and replaced that with the above. also, there are not as many entries on mine.  I am going to match my registry with your websit(nice by the way). I will post back.
good news simon.  I configured the registry settings on my server to match your outline and I recieve the HTTPS on the inside client now........
Interesting how all the sites listed above that I tried did not include the registry settings of your site.....

so now for the outside...
thanks for your patience and help over the past three days. I am good to go on the outside. Your web site was the one that had the registry settings that made the difference.  I have pasted your link on already.