Second Life of a Hungarian SharePoint Geek

March 25, 2017

Microsoft.Workflow.Client.InvalidRequestException: Failed to query the OAuth S2S metadata endpoint – The remote server returned an error: (400) Bad Request

Filed under: Certificates, SP 2013, Workflow — Tags: , , — Peter Holpar @ 21:11

Recently we installed a new Workflow Manager farm (a single-server one) on the front-end server of one of our SharePoint farms.

I wanted to register the Workflow Manager for a web application in the SharePoint farm via the PowerShell cmdlet:

Register-SPWorkflowService -SPSite https://YourSharePointSite -WorkflowHostUri https://YourWorkflowManagerServer:12290 -ScopeName YourScope –Force

But I received an error like this one:

Register-SPWorkflowService : Failed to query the OAuth S2S metadata endpoint
at URI ‘https://YourSharePointSite/_layouts/15/metadata/json/1’.
Error details: ‘An error occurred while sending the request’. HTTP headers received from the server – ActivityId:
d10c4cbb-bde4-4040-b09f-1ace1491dc87. NodeId: YourWFNode. Scope: /YourScope.
Client ActivityId : b89c2ff9-8560-458e-9ea2-31ec6c8fde36.
At line:1 char:1
+ Register-SPWorkflowService -SPSite https://YourSharePointSite/  -W …

In the Event Viewer (Application and Services Logs / Microsoft-Workflow / Operational) we had this error:

image

Failed to query the remote endpoint for the S2S metadata document. Details: System.Net.Http.HttpRequestException: An error occurred while sending the request. —> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
   at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
   at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
   — End of inner exception stack trace —
   at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
   at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)
   — End of inner exception stack trace —

In the ULS logs we had this error message:

Microsoft.Workflow.Client.InvalidRequestException: Failed to query the OAuth S2S metadata endpoint at URI ‘https://YourSharePointSite/_layouts/15/metadata/json/1’. Error details: ‘An error occurred while sending the request.’. HTTP headers received from the server – ActivityId: d10c4cbb-bde4-4040-b09f-1ace1491dc87. NodeId: YourWFNode. Scope: /YourScope. Client ActivityId : b89c2ff9-8560-458e-9ea2-31ec6c8fde36. —> System.Net.WebException: The remote server returned an error: (400) Bad Request.     at Microsoft.Workflow.Common.AsyncResult.End[TAsyncResult](IAsyncResult result)     at Microsoft.Workflow.Client.HttpGetResponseAsyncResult`1.End(IAsyncResult result)     at Microsoft.Workflow.Client.ClientHelpers.SendRequest[T](HttpWebRequest request, T content)     — End of inner exceptio…

The SharePoint site https://YourSharePointSite and the Workflow Manager endpoint URL https://YourWorkflowManagerServer:12290 were both available without any issue (e.g. no problem with the certificate too), on both nodes (front-end and application servers) of the SharePoint farm, as well as from client computers.

The articles I found about the issue (like this one or this one) explained the problem with the reason, that the SharePoint endpoint URL (in our case ‘https://YourSharePointSite/_layouts/15/metadata/json/1‘) is not accessible, probably because of a name resolution issue. In our case that was definitely not the issue, because if I switched the SharePoint URL from HTTPS to HTTP (via changing the Alternate Access Settings for the site + bindings in IIS manager), I was able to run the registration script successfully:

Register-SPWorkflowService -SPSite http://YourSharePointSite -WorkflowHostUri https://YourWorkflowManagerServer:12290 -ScopeName YourScope –Force -AllowOAuthHttp

After switching back the URL to HTTPS we had the problem again.

My next assumption was, that the service account for the Workflow Manager does not have the root certificate of the SSL certificate under the Trusted Root Certification Authorities.

So I’ve started the Microsoft Management Console (mmc.exe) and added the Certificates snap-in for the service account of the Workflow Manager Backend service:

image

image

image

I found that the list of Trusted Root Certification Authorities contains the root certificate of the SSL, so it could not be a problem either.

As next step, I’ve logged in on the Workflow Manager server (that is the front-end server of the SharePoint farm) the using the Workflow Manager service account to test the connection to the SharePoint site interactively via Internet Explorer. In this case I was faced with the problem, that the SharePoint site https://YourSharePointSite has a certificate warning. As I opened the certificate for the site in Internet Explorer, I saw only the very last entry in the certificate chain (for example, the entry for YourSharePointSite), but none of the certificates above. I’ve found it either, that the account has configured not to use a proxy server. I enabled the proxy connection, then restarted Internet Explorer, and voila no more issues with the certificate. I was able to register the Workflow Manager as well. I don’t exactly know, what was the problem, but I assume, the certificate revocation list was not available without the proxy, and that prohibited the certificate validation necessary for the registration of the Workflow Manager.

Advertisements

February 11, 2014

Certificate-related Errors with Claims-based Authentication

Filed under: Certificates, Claims, SP 2010 — Tags: , , — Peter Holpar @ 22:49

Today I wanted to fix a sporadic error we experienced with an IIS-based Security Token Service (STS) we use in one of our test SharePoint 2010 farms.

The original error was:

System.Security.Cryptography.CryptographicException: The system cannot find the file specified.

with a stack trace:

at System.Security.Cryptography.Utils.CreateProvHandle(CspParameters parameters, Boolean randomKeyContainer)
at System.Security.Cryptography.Utils.GetKeyPairHelper(CspAlgorithmType keyType, CspParameters parameters, Boolean randomKeyContainer, Int32 dwKeySize, SafeProvHandle& safeProvHandle, SafeKeyHandle& safeKeyHandle)
at System.Security.Cryptography.RSACryptoServiceProvider.GetKeyPair()
at System.Security.Cryptography.RSACryptoServiceProvider..ctor(Int32 dwKeySize, CspParameters parameters, Boolean useDefaultKeySize)
at System.Security.Cryptography.X509Certificates.X509Certificate2.get_PrivateKey()
at System.IdentityModel.Tokens.X509AsymmetricSecurityKey.get_PrivateKey()
at System.IdentityModel.Tokens.X509AsymmetricSecurityKey.GetAsymmetricAlgorithm(String algorithm, Boolean privateKey)
at Microsoft.IdentityModel.CryptoUtil.GetSignatureFormatterForSha256(AsymmetricSecurityKey key)
at Microsoft.IdentityModel.Protocols.XmlSignature.SignedXml.ComputeSignature(SecurityKey signingKey)
at Microsoft.IdentityModel.Protocols.XmlSignature.EnvelopedSignatureWriter.ComputeSignature()
at Microsoft.IdentityModel.Protocols.XmlSignature.EnvelopedSignatureWriter.OnEndRootElement()
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.WriteAssertion(XmlWriter writer, SamlAssertion assertion)
at Microsoft.IdentityModel.Tokens.SecurityTokenSerializerAdapter.WriteTokenCore(XmlWriter writer, SecurityToken token)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustSerializationHelper.WriteRSTRXml(XmlWriter writer, String elementName, Object elementValue, WSTrustSerializationContext context, WSTrustConstantsAdapter trustConstants)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustSerializationHelper.WriteKnownResponseElement(RequestSecurityTokenResponse rstr, XmlWriter writer, WSTrustSerializationContext context, WSTrustResponseSerializer responseSerializer, WSTrustConstantsAdapter trustConstants)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrust13ResponseSerializer.WriteKnownResponseElement(RequestSecurityTokenResponse rstr, XmlWriter writer, WSTrustSerializationContext context)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustSerializationHelper.WriteResponse(RequestSecurityTokenResponse response, XmlWriter writer, WSTrustSerializationContext context, WSTrustResponseSerializer responseSerializer, WSTrustConstantsAdapter trustConstants)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrust13ResponseSerializer.WriteXml(RequestSecurityTokenResponse response, XmlWriter writer, WSTrustSerializationContext context)
at Microsoft.IdentityModel.Protocols.WSFederation.WSFederationSerializer.GetResponseAsString(RequestSecurityTokenResponse response, WSTrustSerializationContext context)
at Microsoft.IdentityModel.Protocols.WSFederation.SignInResponseMessage..ctor(Uri baseUrl, RequestSecurityTokenResponse response, WSFederationSerializer federationSerializer, WSTrustSerializationContext context)
at Microsoft.IdentityModel.Web.FederatedPassiveSecurityTokenServiceOperations.ProcessSignInRequest(SignInRequestMessage requestMessage, IPrincipal principal, SecurityTokenService sts, WSFederationSerializer federationSerializer)

We typically did not experience this error at the office, most often it happened when we visited the site for example from home.

I found a few useful resources related to this issue, like this, this or this. However, in our case the RSACryptoServiceProvider constructor was called by internal IdentityModel classes and not by our custom code, so the proposed solution was not applicable, I had to investigate further.

During my study I found, that the application pool of the STS is running with the identity of one of the developer accounts. I created a dedicated service account and gave all the required permissions (at least, I thought I did…).

After the change the previous error disappeared, but a new one arose, and in this case, not only sporadic, but constantly:

System.Security.Cryptography.CryptographicException: Keyset does not exist

with a stack trace:

at System.Security.Cryptography.Utils.CreateProvHandle(CspParameters parameters, Boolean randomKeyContainer)
at System.Security.Cryptography.Utils.GetKeyPairHelper(CspAlgorithmType keyType, CspParameters parameters, Boolean randomKeyContainer, Int32 dwKeySize, SafeProvHandle& safeProvHandle, SafeKeyHandle& safeKeyHandle)
at System.Security.Cryptography.RSACryptoServiceProvider.GetKeyPair()
at System.Security.Cryptography.RSACryptoServiceProvider..ctor(Int32 dwKeySize, CspParameters parameters, Boolean useDefaultKeySize)
at System.Security.Cryptography.X509Certificates.X509Certificate2.get_PrivateKey()
at System.IdentityModel.Tokens.X509AsymmetricSecurityKey.get_PrivateKey()
at System.IdentityModel.Tokens.X509AsymmetricSecurityKey.GetAsymmetricAlgorithm(String algorithm, Boolean privateKey)
at Microsoft.IdentityModel.CryptoUtil.GetSignatureFormatterForSha256(AsymmetricSecurityKey key)
at Microsoft.IdentityModel.Protocols.XmlSignature.SignedXml.ComputeSignature(SecurityKey signingKey)
at Microsoft.IdentityModel.Protocols.XmlSignature.EnvelopedSignatureWriter.ComputeSignature()
at Microsoft.IdentityModel.Protocols.XmlSignature.EnvelopedSignatureWriter.OnEndRootElement()
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.WriteAssertion(XmlWriter writer, SamlAssertion assertion)
at Microsoft.IdentityModel.Tokens.SecurityTokenSerializerAdapter.WriteTokenCore(XmlWriter writer, SecurityToken token)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustSerializationHelper.WriteRSTRXml(XmlWriter writer, String elementName, Object elementValue, WSTrustSerializationContext context, WSTrustConstantsAdapter trustConstants)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustSerializationHelper.WriteKnownResponseElement(RequestSecurityTokenResponse rstr, XmlWriter writer, WSTrustSerializationContext context, WSTrustResponseSerializer responseSerializer, WSTrustConstantsAdapter trustConstants)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrust13ResponseSerializer.WriteKnownResponseElement(RequestSecurityTokenResponse rstr, XmlWriter writer, WSTrustSerializationContext context)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustSerializationHelper.WriteResponse(RequestSecurityTokenResponse response, XmlWriter writer, WSTrustSerializationContext context, WSTrustResponseSerializer responseSerializer, WSTrustConstantsAdapter trustConstants)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrust13ResponseSerializer.WriteXml(RequestSecurityTokenResponse response, XmlWriter writer, WSTrustSerializationContext context)
at Microsoft.IdentityModel.Protocols.WSFederation.WSFederationSerializer.GetResponseAsString(RequestSecurityTokenResponse response, WSTrustSerializationContext context)
at Microsoft.IdentityModel.Protocols.WSFederation.SignInResponseMessage..ctor(Uri baseUrl, RequestSecurityTokenResponse response, WSFederationSerializer federationSerializer, WSTrustSerializationContext context)
at Microsoft.IdentityModel.Web.FederatedPassiveSecurityTokenServiceOperations.ProcessSignInRequest(SignInRequestMessage requestMessage, IPrincipal principal, SecurityTokenService sts, WSFederationSerializer federationSerializer)
at ITSV.MOAAuth.Login.LogInLogOutUser(IPrincipal user) in E:\data\pholpar\projects\MOAAuth\MOAAuth\Login.aspx.cs:line 394

When I logged in using the service account and tried to set permissions on the certificate using the Manage Private Keys… menu option, instead of the usual dialog box I received an “Object was not found” error (or something very similar).

clip_image002

The answer of Željko Tanović (answered Dec 7 ’09 at 10:52) helped me to solve the issue. The problem was that the certificate was originally imported into the user store of the developer, then it was moved into the local machine store. That means the private key was stored in the original folder, where the new (service) account could not access it.

Solution: import the certificate directly into the local machine store.

After fixing the former issue, the original error appeared again, but it was no more sporadic, but rather constant.

Based on the links above I assumed, that it was related to the user profile, that was somehow not loaded. Using this trick it was easy to confirm, that the profile of the service account was indeed not loaded.

image

Though the Load User Profile setting of the STS application pool I was able to fix the problem, I had to set the value as True, instead of the former False value.

image

The reason of why we experienced this error originally only sporadic, and not when working in the office: the developer was typically logged on into the system interactively, so his profile was loaded. But after work-hours, he was logged out, and his profile was unloaded, so the error appeared when the STS was accessed.

June 25, 2011

An error occurred while signing: Key not valid for use in specified state

The other day I had to create an Excel 2010 add-in. I wouldn’t have liked to start from scratch, so I took one of my similar projects from the beginning of last year, and started to alter it.

However, when I was to build the project in Visual Studio 2010, I got this error:

An error occurred while signing: Key not valid for use in specified state

I’ve checked the original version of the project, but I found the same error there.

First I thought the issue is with the signing of the assembly, but it turned out to be false. The real reason was related to the pfx certificate  used to sign the manifest for ClickOnce.

The original version of the project was created using a CTP version of Visual Studio 2010 on another machine, so even the certificate was expired.

The following  section contains the related settings in (csproj) file:

<SignManifests>true</SignManifests>
<ManifestKeyFile>Former Add-in_TemporaryKey.pfx</ManifestKeyFile>
<ManifestCertificateThumbprint>E4CE6BCC9A8EAE662AD55F9E69F1E9E50221711E</ManifestCertificateThumbprint>

You can find the same settings on the VS 2010 UI as well, see the Signing /Sign the ClickOnce manifests setting at project properties.

image

First I tried to simply remove the section from the csproj (after Unload Project, then Edit MyAddInProject.csproj, and Reload Project after editing the file). This helped to remove the build error, but caused error on deployment:

Reference in the deployment does not match the identity defined in the application manifest

So I created a new pfx, and used that certificate for ClickOnce signing.

Later I tried to reproduce the issue that turned out to be not easy, but I think it would have been enough to simply uncheck the Sign the ClickOnce checkbox. At least, VS seems to check it back on project build for me and it solved the issue as well. I’m still not sure what the real reason for this error was, but probably something related to VS was not able to import the certificate to my certificate store, so it could not use it to sign the manifests.

Create a free website or blog at WordPress.com.