Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I have a secured webapplication means that it uses "https" protocal, in which I have created two calendars Cal_1 and Cal_2. While trying to use the Calendar overlay option, it does not accept the "https" URL (Web URL:) however it recognize the "http" URL (Web URL:).

Is that a known issue with SharePoint 2010? If not, how it can be resolved?

Update:

  1. From Client browser to Load Balancer it uses "https" protocal to communicate
  2. From Load Balancer to WFE it uses "http" protocal to communicate

AAM Settings:
https://testapplication.test.com Default https://testapplication.test.com
http://testapplication.test.com Default https://testapplication.test.com

the microsoft KB - http://support.microsoft.com/kb/2025977 says that it should resolve the URL is in the default zone however in this case it does not.

so it seems that we should have a SSL binding for that webapplication in IIS level, is that true? or how it works?

share|improve this question
add comment

1 Answer

The issue is that SharePoint isn't going to the calendar via the same path as the end user, meaning it doesn't go out to the load balancer on HTTPS and then back to the SharePoint server as HTTP.

Since you have HTTPS terminating at the load balancer, when SharePoint goes to access the HTTPS URL for the calendar, it is simply looping back to itself (no load balancer). The issue you are probably facing is that SharePoint is returning itself an SSL cert error since it's not where the HTTPS termination occurs.

So, in a nutshell, you would either need to terminate the SSL request on the IIS level or simply use the non-HTTPS version for your overlay. Since the server is talking to itself, using http for the overlay should be an issue.

share|improve this answer
    
BTW, I have had to deal with similar situations. For example, my company uses SharePoint for our public-facing websites. Our HTTPS requests terminate at our F5 load balancer. Whenever SharePoint references itself, it is on the HTTP (non SSL link) since SharePoint loops back to itself instead of going out and back through the F5 load balancer. –  John Chapman Sep 12 '11 at 16:54
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.