To save you time:
Basically, this post describes exactly what are we going through: http://social.technet.microsoft.com/Forums/en-US/sharepointgeneralprevious/thread/f5adb430-bf04-43a0-b3a1-8cbc5c80090c We’ve tried the suggested solutions without luck.
If you want to see the actual question we have, scroll to the bottom. Otherwise, here’s the story.
As background, our organization comes from an upgrade from MOSS 2007 to 2010 earlier this year. Everything went well in overall, however there’s one remaining issue we’re still working on, and we haven’t been able to configure properly. That is the external access to our intranet sites with SSL (https).
Back in MOSS 2007, the only way we could achieve this securely, was to extend a couple of our web applications and enable FBA. We authenticated users against Active Directory, which brought in an extra layer of “complexity” to the configurations. Also, we had to deal with the “duplicate” user accounts. In order for a user to authenticate to a site via FBA, permissions to the site should have been provided beforehand in the form of “LDAPNAME:USERACCOUNT” opposed to the standard Windows authentication credentials “DOMAIN\USERACCOUNT”; this was very confusing to users. We also had to worry about the web.config file configurations and Login page design.
Access to our web applications internally, that is within the Domain or through VPN, was throughhttp://sharepoint.contoso.com for example. For external access, our users should usehttps://sharepoint.contoso.com. We have configured server certificates on IIS with dedicated IP addresses for each SP web application.
This was not an ideal architecture.
After run this through a consulting company, we were led to believe that once we upgraded to SharePoint 2010 everything would be resolved for us. Sadly this wasn’t entirely true.
The requirement: ideally, we’d like to have internal access to all of our SP web applications through http:// (for example http://sharepoint.contoso.com) whenever the user access internally; and when the user access externally, they should be forced to use https:// (example:https://sharepoint.contoso.com). We decided we didn’t want to have FBA anymore (or Claims-based Authentication in 2010 lingo).
The contractors we brought in helped us to configure the scenario above with Windows Authentication. They also instructed our Network team on how to configure the access to SharePoint. They configured SharePoint SSL Offloading on the F5 devices. They configured AAM’s accordingly.
Everything seemed to work fine, until we start discovering issues when accessing externally through https (SSL). Errors related to javascript files started to pop out (core.js), and with the publishing features as well. The contractors only said that these issues were related to the https configuration. They blame it to the fact that we were using the same host name, and that this was not recommended, they said that we should be using a different name such ashttps://extranet-sharepoint.contoso.com or so (we don't want this). I won’t go into the specifics, but we ended up with fully functional internal sharepoint web applications, and the SharePoint externally accessible web applications with some degradation in the functionality and features. (as a note, the web applications were not ‘extended’. Everything was done through the Network device settings and AAM’s).
We decided then, again by recommendation, to forget about http vs https and just have everyone use https full time, regardless whether they’re accessing internally or externally; we changed the configurations to force everyone to use https://sharepoint.contoso.com (for example, the change was applied to all the web apps). This apparently worked, but after a while we discovered this wasn’t a silver bullet. The issue stated in the post at the beginning appeared today. It seems the delete button in the Ribbon has some issueswhen using https. The other issues that appeared initially are gone though, the core.js error and the context edit menu appears without issues on the document files at the Document libraries, and publishing looks good too.
I would like to know if this is a known issue and if it’s related to our SSL configuration at all. Also, I found the following KB article describing a hotfix, but I’m not sure if it applies to SharePoint and if it will have any effect on the Ribbon issue.
http://support.microsoft.com/kb/971493
Our environment:
Two web front end servers (load balanced), one app server and one SQL server (clustered). SharePoint version: 14.0.6134.5000
We have a custom master page for branding, but in overall we have a pretty plain-vanilla SharePoint setup (no custom code other than the solution that deploys the custom master page feature).
Thank you.