Exchange 2010 SP1 security - questions about internal SSL and RPC encryption
Hello: Note: I don’t have my Exchange 2010 lab set up yet, so I can’t verify all this myself. Does the internal URI of the AutoDiscover service really require SSL/HTTPS? In the Set-ClientAccessServer example below, MS has HTTPS. I understand that externally you'd want HTTPS, but is it really necessary internally? Can I run the command below and only use HTTP and set up the related IIS sites to not require HTTPS? Set-ClientAccessServer -Identity "CAS-01" -AutoDiscoverServiceInternalUri "https://cas01.contoso.com/autodiscover/autodiscover.xml" -AutoDiscoverSiteScope "Mail" I don't understand the need for HTTPS for something like AutoDiscover, internally. If someone's on my network, the person can find out a lot about my network through DNS queries, etc. What is so important about internal AutoDiscover that would require HTTPS? If I have Outlook 2007 or 2010 with all the latest updates, will those clients automatically accept the CAS server's self-signed SSL cert for internal AutoDiscover, so the user won’t get a certificate warning prompt? I recall reading something about this but didn’t save the link to the article. If a client connects to internal OWA via HTTPS, the client will get a certificate warning for the CAS server's self-signed SSL cert. Is this correct? If I use the same DNS namespace internally and externally, and use the same FQDN for internal and external AutoDiscover, OWA, etc., I could use the same certificate for internal and external use, correct? Does RPC encryption require an SSL cert? If not, what is used for the encryption? So far every post I’ve read that mentions "RPC encryption" only states that it's enabled by default in Exchange 2010 RTM and that it needs to be enabled in Outlook 2003, etc. I haven't seen anything that states how RPC encryption itself works. I'm not an IT security guru, but what type of encryption algorithm is used, etc., and how secure is RPC encryption compared to 128-bit SSL, for example? Thank you for your time.
April 17th, 2011 4:11pm

If you deploy a unified communications certificate, then your questions become mute anyway. The self signed certificate that Exchange puts in to it for installation is not supported for use with Outlook Anywhere. The self signed certificate should really be thought of as a place holder for your commercial certificate. RPC encryption is used for all connections to Exchange, internal and external. Whereas HTTPS is only used by Outlook Anywhere externally. RPC encryption over that will then be over that HTTPS secured environment. The whole product is built around web services and therefore things need to be secure. If you don't run it in HTTPS then a sniffer on your network could intercept that traffic. Primarily authentication traffic going back and forth frequently. The most common attacks on most networks are internal. You can't use different certificates for internal and external traffic, doesn't matter whether you are on the same namespace or not. That is why UC certificates are used, as they allow a mixture of the internal and external names to go in to the certificate. Bottom line - the product is designed to be used with SSL, specifically a UC certificate. While you can configure it in other ways you are really causing yourself more headache long term for very little gain. A standard certificate costs US$30/year, a UC certificate US$80/year. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.
Free Windows Admin Tool Kit Click here and download it now
April 17th, 2011 6:40pm

As an additional information, I would like to share you the following article: http://blogs.technet.com/b/exchange/archive/2007/04/30/3402138.aspx Thanks. NovakPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
April 20th, 2011 10:42pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics