MOSS 2007 SSL error when configuring Search Settings - sharepoint

We’re getting the following error message when we click on “Search Settings” for a Shared Services Provider: “Authentication failed because the remote party has closed the transport stream.”
This is a new server environment with two web front ends, one database server, and one index server, all running Windows 2003 x64.
Does anyone have any thoughts related to if this could be related to 64-bit, or what could be causing the error.
Here are the full details from ULS:
09/17/2008 16:30:34.13 w3wp.exe (0x0E84) 0x030C Search Server Common MS Search Administration 86x4 High Configuring the Search Application web service Url to 'https://mushni-sptwb04q:56738/Shared%20Services%20Portal/Search/SearchAdmin.asmx'.
09/17/2008 16:30:34.14 w3wp.exe (0x0E84) 0x030C Search Server Common MS Search Administration 86ze High Exception caught in Search Admin web-service proxy (client). System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Authentication failed because the remote party has closed the transport stream. at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Threading.ExecutionContext.runTryCode(Object userData) at System.Runtime.Co...
09/17/2008 16:30:34.14* w3wp.exe (0x0E84) 0x030C Search Server Common MS Search Administration 86ze High ...mpilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result) at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size) at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size) at System.Net.ConnectStream.WriteHeaders(Boolean async) --- End of inner exception stack trace --- at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request) at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request) at System.Web.Services.Protocols.SoapHt...
09/17/2008 16:30:34.14* w3wp.exe (0x0E84) 0x030C Search Server Common MS Search Administration 86ze High ...tpClientProtocol.Invoke(String methodName, Object[] parameters) at Microsoft.Office.Server.Search.Administration.SearchWebServiceProxy.RunWithSoapExceptionHandling[T](String methodName, Object[] parameters)

I guess you find this exception in the index server, right?
Are you able to browse to 'https://mushni-sptwb04q:56738/Shared%20Services%20Portal/Search/SearchAdmin.asmx' from the index server?
It seems like SSL is not properly provisioned on the front-end servers. This might solve your issue:
Remove the SSL certificate of the front-end servers
Remove the index server from the farm
Move the search and index roles to one of the front-ends
Join the index server back to the farm
Add the index/search roles to the index server
Apply the SSL certificate (you can generate them using SelfSSL) to both front-ends

Be careful with SelfSSL, its better to use Use SSLDiag. SelfSSL has a bug where if you use it to assign certificates to multiple sites on the same box, only the last site will work. You can run SslDiag from the command line like so:
ssldiag /selfssl /V:999 /N:CN=<hostname> /S:<siteId>
Use metabase explorer to find the side it.

Could be an SSL issue.
Do have a look into profiles settings, do you get any error when accessing to the User Profiles settings for that same SSP?

I'm having the same problem. The "Office Server Web Services" (henceforth OSWS) site is available through HTTP on my app server, but not via HTTPS. It doesn't matter where I try to hit the HTTPS URL from, it just flat-out fails (read: no HTTP error code).
However, I have come up with some more information. When the app server was joined to the farm, it gave OSWS a different site identifier than exists in the rest of the farm.
I tried changing the site identifier, but that didn't work. I've also tried installing the IIS diagnostics toolkit. That pointed me towards the certificate that MOSS installed when the machine was joined to the farm. The line of interest is this one:
#WARNING: AcquireCredentialsHandle failed with error -2146893043(0x8009030d)
Unfortunately, it looks like Microsoft has embedded some information in the certificate that would prevent me from using SelfSSL or similar tools. Here's the subject (suitably scrubbed):
CN={hostname},L=951338967,OU=SharePoint,O=Microsoft
The "L" parameter matches the original (and incorrect) site identifier that the site was given and not the one that matches the rest of the farm.
My next step is to see if I can generate something that looks appropriate and install it with winhttpcertcfg.exe

We are also running x64 windows and moss 2007 with .net 3.5 sp1,same issues. I suspect this is the culprit.

To resolve this issue download the IIS6 resource kit and run the following command
Selfssl /s:(IIS ID of the Office Server Web Services site) /v:9999
Cheers,
-Ivan

Related

HTTPS not working with Kestrel 3.2.187/ASPNET Core 2.1.5 running on the Service Fabric with a custom domain

We are running a Service Fabric application on our remote dev cluster. It consists of several stateful and stateless services and is fronted by several front-end APIs running on Kestrel.
Until now, since it was not used for production, Kestrel was configured to use a self-signed certificate, which was also used for the reverse proxy and the cluster itself and the service was running directly on the default domain provided by Azure, <app>.<region>.cloudapp.azure.com.
We are now getting to the point in development where the self-signed certificate errors are becoming problematic, with third party callbacks rejecting the connection, so it was seen as the time to start using a proper domain and certificate for it.
So far, I have done the following:
Added an A record for devcluster.somexampledomain.com -> our public IP for the service.
Created a Wildcard Azure Application certificate for *.someexampledomain.com.
Imported the certificate to Azure Key Vault.
Bound the certificate to the Vault Secrets of the cluster, pulling the certificate to Cert:/LocalMachine/My/
Modified the application config to use this certificate when initialising Kestrel and verified that it is found when it is initialising.
Have tried with and without UseHsts() and UseHttpsRedirection()
Kestrel is configured with Listen(IPAddress.IPv6Any, endpoint.Port, ...) and UseHttps(X509Certificate2) on the options object.
UseUrls(string) is used with the default Url, which is https://+:<port> but tried manually adding https://*:<port> and even the actual hostname itself.
No matter what I have tried, no HTTPS connection can be established to the server. Trying the endpoints of the other staging servers that still use the old certificate, it works as expected.
Using openssl s_client -connect devcluster.someexampledomain.com:<port> -prexit, I get:
---
no peer certificate available
---
No client certificate CA names sent
---
There are no errors or exceptions being logged on ETW, everything seems to be in order. I suspect that this might have something to do with the CN of the certificate but I have run out of ideas to try and find out what is going on and how to fix it.
Been trying to look into this using Fiddler and I am not getting much out of it, the session just ends with fiddler.network.https> HTTPS handshake to <myhost> (for #191) failed. System.IO.IOException Authentication failed because the remote party has closed the transport stream.
Does anybody know how to add some logging on the Kestrel side? I don't think installing Fiddler on the Azure VMs running my cluster is a viable solution.
After delving into the Kestrel source, I found that it logs under "Microsoft-AspNetCore-Server-Kestrel" and "Microsoft-Extensions-Logging", so adding transfer of those I found what was happening.
Connections were terminating with the following exception:
System.ComponentModel.Win32Exception (0x8009030D): The credentials supplied to the package were not recognized
at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface secModule, String package, CredentialUse intent, SCHANNEL_CRED scc)
at System.Net.Security.SslStreamPal.AcquireCredentialsHandle(CredentialUse credUsage, SCHANNEL_CRED secureCredential)
at System.Net.Security.SslStreamPal.AcquireCredentialsHandle(X509Certificate certificate, SslProtocols protocols, EncryptionPolicy policy, Boolean isServer)
at System.Net.Security.SecureChannel.AcquireServerCredentials(Byte[]& thumbPrint, Byte[] clientHello)
at System.Net.Security.SecureChannel.GenerateToken(Byte[] input, Int32 offset, Int32 count, Byte[]& output)
at System.Net.Security.SecureChannel.NextMessage(Byte[] incoming, Int32 offset, Int32 count)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.PartialFrameCallback(AsyncProtocolRequest asyncRequest)
--- End of stack trace from previous location where exception was thrown ---
at System.Net.Security.SslState.EndProcessAuthentication(IAsyncResult result)
at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionAdapter.InnerOnConnectionAsync(ConnectionAdapterContext context)
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.HttpConnection.ApplyConnectionAdaptersAsync()
This makes it a manifestation of Certificate problem with a new machine - credentials supplied to package not recognized.
I spent some time trying to figure out what the best way to sort this out would be, the Service Fabric documentation has a script to modify the permissions but that just did not sound right.
As it turns out, this can be done directly in the ApplicationManifest as follows:
<Principals>
<Users>
<User Name="NETWORK SERVICE" AccountType="NetworkService" />
</Users>
</Principals>
<Policies>
<SecurityAccessPolicies>
<SecurityAccessPolicy ResourceRef="HttpsCert2" PrincipalRef="NETWORK SERVICE" ResourceType="Certificate" />
</SecurityAccessPolicies>
</Policies>
<Certificates>
<SecretsCertificate X509FindValue="[HttpsCertThumbprint]" Name="HttpsCert" />
</Certificates>
For the SecurityAccessPolicy to find the ResourceRef it had to be a SecretsCertificate, not an EndpointCertificate. Since the EndpointBindingPolicy requires an EndpointCertificate, I just added both a SecretsCertificate and an EndpointCertificate, with different names. They are both referring to the same certificate, so it worked. It doesn't feel particularly clean having to double them up but that is the solution I have for now.

Umbraco: An unexpected network error on Azure Web Apps

We have an Umbraco website (version 7.5.11) hosted on Azure Web Apps.
We are experiencing the following exception intermittently (3 times within the past 3 weeks). Once the exception occurs it brings the website down until we republish the home node in Umbraco. At all other times the website is working as expected, including retrieving image files from the server.
Exception type: IOException
Exception message: An unexpected network error occurred. at Umbraco.Core.Cache.HttpRuntimeCacheProvider.GetCacheItem(String cacheKey, Func1 getCacheItem, Nullable1 timeout, Boolean isSliding, CacheItemPriority priority, CacheItemRemovedCallback removedCallback, CacheDependency dependency) at Umbraco.Core.Cache.HttpRuntimeCacheProvider.GetCacheItem(String cacheKey, Func1 getCacheItem, Nullable1 timeout, Boolean isSliding, CacheItemPriority priority, CacheItemRemovedCallback removedCallback, String[] dependentFiles) at Umbraco.Core.Cache.DeepCloneRuntimeCacheProvider.GetCacheItem(String cacheKey, Func1 getCacheItem, Nullable1 timeout, Boolean isSliding, CacheItemPriority priority, CacheItemRemovedCallback removedCallback, String[] dependentFiles) at Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedMediaCache.GetCacheValues(Int32 id, Func2 func) at Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedMediaCache.GetUmbracoMedia(Int32 id) at Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedMediaCache.GetById(UmbracoContext umbracoContext, Boolean preview, Int32 nodeId) at Umbraco.Web.PublishedCache.ContextualPublishedCache1.GetById(Boolean preview, Int32 contentId) at Umbraco.Web.PublishedContentQuery.DocumentById(Int32 id, ContextualPublishedCache cache, Object ifNotFound) at Umbraco.Web.PublishedContentQuery.Media(Int32 id) at Umbraco.Web.UmbracoHelper.Media(String id)
The media file exists, and republishing the home node brought the site back online.
At the time of the exception, no code changes were deployed and no pages were updated / published within Umbraco.
Has anyone experienced something similar, or any ideas what the root cause is?
According to the source code of PublishedMediaCache.cs, the exception is often caused by following issue.
Examine index is corrupted.
Here is a thread on umbraco forum which related to your issue.
Examine corruption issues
And here is the solution for this issue from #Shannon Deminick.
If you are using Azure web apps and are NOT auto-scaling, you should use these settings:
useTempStorage="Sync"
use this feature to store local index files: http://issues.umbraco.org/issue/U4-7614
Remove the {machinename} token from your index path
RebuildOnAppStart="true" - since this should only happen one time
If you are using Azure web apps and are load balancing w/ auto-scaling your front-end workers then:
useTempStorage="Sync"
use this feature to store local index files: http://issues.umbraco.org/issue/U4-7614
You must have the {machinename} token from your index path
RebuildOnAppStart="true" - so that when new sites come online, their indexes are built
... yes in some cases this might not be ideal, please see: https://our.umbraco.org/forum/extending-umbraco-and-using-the-api/74731-examine-corruption-issues#comment-244293

Creating Files in Sitefinity API for docs that already exist on Filesystem

I am working with Sitefinity as a solution in Visual Studio 2012. I'm on a 64bit machine. I just installed Windows Identity Manager as I was getting another error before that and it was related to not having that installed. Now I am receiving this error:
Found invalid data while decoding.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.IO.InvalidDataException: Found invalid data while decoding.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[InvalidDataException: Found invalid data while decoding.]
System.IO.Compression.Inflater.DecodeDynamicBlockHeader() +6621162
System.IO.Compression.Inflater.Decode() +408
System.IO.Compression.Inflater.Inflate(Byte[] bytes, Int32 offset, Int32 length) +150
System.IO.Compression.DeflateStream.Read(Byte[] array, Int32 offset, Int32 count) +64
Microsoft.IdentityModel.Web.DeflateCookieTransform.Decode(Byte[] encoded) +396
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms(Byte[] cookie, Boolean outbound) +217
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver) +1958
Telerik.Sitefinity.Security.Claims.SitefinitySessionTokenHandler.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver) +44
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(Byte[] token, SecurityTokenResolver tokenResolver) +149
Telerik.Sitefinity.Security.Claims.SitefinitySessionAuthenticationModule.ReadToken(Byte[] sessionCookie) +520
Telerik.Sitefinity.Security.Claims.SitefinitySessionAuthenticationModule.TryReadFromCookie(SessionSecurityToken& sessionToken) +111
Telerik.Sitefinity.Security.Claims.SitefinitySessionAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs eventArgs) +95
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +136
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +69
I also followed the advice before and after this post and it did not work for me:
http://www.sitefinity.com/developer-network/knowledge-base/getting-type-is-not-resolved-for-member-microsoft-identitymodel-claims-claimsprincipal-exception
which is what led me to installing the Microsoft identity Manager. I'm not sure how to get past this issue.
There are bugs in Microsoft's DeflateStream implementation prior to .Net 4.5.
See here:
.NET [4 and previous] users should not use the Microsoft-provided
GZipStream or DeflateStream classes under any circumstances, unless
Microsoft replaces them completely with something that works.
This bug was never fixed by Microsoft for earlier versions of the .NET framework than 4.5
As for the difference between Firefox and IE - they might be interacting differently with IIS while using gzip compression, Fiddler might be able to tell you more about the differences in your situation if you look at the raw HTTP requests and responses. Check if the request sequence looks the same between browsers. My gut feeling is that Firefox is falling back to no compression and IE isn't, but without a test bed I won't be able to help further.
You could try these three solutions in increasing order of desperation:
See if you can change the app pool in IIS for the SiteFinity application and your .NET framework target inside Visual Studio to target .NET 4.5 where their GZIP DeflateStream method was fixed.
Attempt to disable GZIP compression in IIS for this application. Follow the instructions found here in reverse. I would try this last because there will be a bandwidth penalty for your server and all users, affecting the user experience.
Install the DotNetZip Library, and override Microsoft's implementation of System.IO.Compression.DeflateStream to call a compatible method that doesn't have the same bug.

HTTP 503 error accessing Sharepoint excelservice.asmx through SOAP

I work for The Smeal College of Business at Penn State. I am doing a project for the Supply chain program and I am creating an excel workbook in Sharepoint that uses a lot of UDF's. I have no problem accessing the workbook or using other UDF's, but when I try to use OpenWorkbookForEditing() I get the following stack trace:
System.Net.WebException: The request failed with HTTP status 503: Service Unavailable.
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at ClassName.ExcelWebService.ExcelService.OpenWorkbookForEditing(String workbookPath, String uiCultureName, String dataCultureName, Status[]& status)
at ClassName.ClassNameFunctions.testWriteCell()
Additionally, I've tried to access excelservice.asmx through PHP SOAP and have not received a response. Each attempt to connect to this service provides a 503 error in the IIS logs similar to the following:
2012-08-06 15:14:58 xxxx::xxx:xxxx:xxxx:xxxxxxx POST /_vti_bin/excelservice.asmx - 80 - xxxx::xxx:xxxx:xxxx:xxxxxxx Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.5456) 503 0 0 59
I've tried changing most of the settings in Sharepoint Central Administration, as well as some of the setting in IIS. Does anyone know what could be causing this problem? Thanks.
I'm running a Sharepoint 2010 server on Windows Server 2008.
Can take a look at this article maybe it will help.
http://technet.microsoft.com/en-us/library/ee513104.aspx
The solution that is suggested here is to just restart. If this is a dev machine that shouldn't be a big deal.
Also make sure that no application pools have stopped as this could make the service unavailable.

Sharepoint SSL Web.Config access issue

I’ve got a strange scenario:
I’ve got a webpart that calls into a dll in the GAC, which is trying to read a section from web.config file.
This works fine normally, but under SSL it fails, saying it does not have access to the path (of the config file). However, it’s under the mosssvc account, which has full control over the webconfig file.
Both the 80 web.config file and the 443 web.config file have the same entries the dll is looking for, and mosssvc has full control on both configs.
I have tried elevating the trust level on 443 to full, which didn't work.
Any ideas, or anything you can think of that I can try?
EDIT: I should have been more clear: the SSL site has already been created and works fine until the one method in the GAC'd assembly tries to examine the web config.
The full error message is:
Event Type: Warning
Event Source: ASP.NET 2.0.50727.0
Event Category: Web Event
Event ID: 1310
Date: 2/9/2009
Time: 1:44:49 PM
User: N/A
Computer: XXXXX
Description:
Event code: 3008
Event message: A configuration error has occurred.
Event time: 2/9/2009 1:44:49 PM
Event time (UTC): 2/9/2009 9:44:49 PM
Event ID: 2d7180cdfbb34acfa6c61f95df12ddde
Event sequence: 26
Event occurrence: 1
Event detail code: 0
Application information:
Application domain: YYYYYYYYYYYYYYYYYYYYYYY
Trust level: Full
Application Virtual Path: /
Application Path: C:\Inetpub\wwwroot\wss\VirtualDirectories\8443\
Machine name: XXXXXXXX
Process information:
Process ID: 5168
Process name: w3wp.exe
Account name: XXXXXXXXX\mosssvc
Exception information:
Exception type: ConfigurationErrorsException
Exception message: An error occurred loading a configuration file: Access to the path 'C:\Inetpub\wwwroot\wss\VirtualDirectories\8443\web.config' is denied. (C:\Inetpub\wwwroot\wss\VirtualDirectories\8443\web.config)
Request information:
Request URL: https://XXXXXXX:443/training/Pages/smartregister.aspx?c=383
Request path: /training/Pages/smartregister.aspx
User host address: 64.34.27.186
User:
Is authenticated: False
Authentication Type:
Thread account name: XXXXXXX\mosssvc
Thread information:
Thread ID: 10
Thread account name: XXXXXXX\mosssvc
Is impersonating: True
Stack trace: at System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal)
at System.Configuration.BaseConfigurationRecord.ThrowIfParseErrors(ConfigurationSchemaErrors schemaErrors)
at System.Configuration.Configuration..ctor(String locationSubPath, Type typeConfigHost, Object[] hostInitConfigurationParams)
at System.Configuration.Internal.InternalConfigConfigurationFactory.System.Configuration.Internal.IInternalConfigConfigurationFactory.Create(Type typeConfigHost, Object[] hostInitConfigurationParams)
at System.Web.Configuration.WebConfigurationHost.OpenConfiguration(WebLevel webLevel, ConfigurationFileMap fileMap, VirtualPath path, String site, String locationSubPath, String server, String userName, String password, IntPtr tokenHandle)
at System.Web.Configuration.WebConfigurationManager.OpenWebConfigurationImpl(WebLevel webLevel, ConfigurationFileMap fileMap, String path, String site, String locationSubPath, String server, String userName, String password, IntPtr userToken)
at System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(String path)
at XXXXXXXXX.RegistrationHelper.RegisterStudents(Boolean sendEmail, String Time, String Title, String bFirstName, String bLastName, String bAddress, String bPostalCode, String bCity, String bTelephone, String bCompany, String bEmail, List`1 Registrants, Int32 courseDateID, String pType, String CCNumber_, String NameOnCard, String cExpiry, Double Discount, String DiscountCode, Double CostPerRegistrant, String PurchaseOrder)
at ASP.SmartEventRegistration.lnkSubmit_Click(Object sender, EventArgs e) in c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES\SmartEventRegistration\SmartEventRegistration.ascx:line 401
at System.Web.UI.WebControls.LinkButton.OnClick(EventArgs e)
at System.Web.UI.WebControls.LinkButton.RaisePostBackEvent(String eventArgument)
at System.Web.UI.WebControls.LinkButton.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument)
at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument)
at System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest()
at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context)
at System.Web.UI.Page.ProcessRequest(HttpContext context)
at Microsoft.SharePoint.Publishing.TemplateRedirectionPage.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
try this, form Faranz Kan SharePoint blog on how to enable SSL in MOSS:
Go to central admin --> Create or extend a new web application -->
Create a new web application.
Fill in the Web app, DB and App pool names as usual. Select yes to
enable SSL on the web application. If
you are using host headers for this
web app, then enter those too.
(Important: Make sure to set the port
to 443, not 80).
After the web application has been created, reset IIS and then open up
IIS mmc. Scroll to the IIS website
that MOSS just created for you and
select the right SSL certificate from
the available certificates (Ask your
network folks to generate an internal
or external SSL cert for you depending
on whether this is a test or prod
server). Important: Go to the Home
Directory tab and click Advanced. Make
sure you set the host header and the
right IP for port 80. For SSL entries,
select port 443 and the IP. (If you
have multiple IP's on the server, I
usually pick one here for these
entries). Click on the edit button for
SSL entries and check the 'Require
SSL' box. Also check 'Require 128 bit
encryption' to make this more secure.
Now go ahead and create your first site collection for this web app. MOSS
will automatically create a new site
collection for you and present you
with a "https://.." link upon
completion. You should now have a SSL
ready web app.
By default, if you want multiple web apps using SSL on the same server
this does not work in IIS 6. If you want multiple MOSS 2007 Web apps to be
SSL enabled, there are two ways of
going about this. One way is to get as
many IPs as you want SSL web apps for
that web server and assign one IP per
host header settings for port 80 and
443 under IIS Website properties -->
Home Directory --> Advanced. The other
option is to modify the IIS metabase
to allow multiple SSL web apps on the
same IP. Be careful with the second
option and make sure you know what you
are doing.

Resources