We have SAML signature validation issue in production. Everything was working fine until this morning. We are getting the following error:
"Failed to validate the SAML assertion signature"
With some digging, we found out that some of the SSO requests were failing on
SAMLAssertionSignature.Verify()
The X509 certificate is sent as part of the message. They are exactly the same between the success and failure scenarios.
The exception we are getting is
ComponentSpace.SAML2.Exceptions.SAMLSignatureException: Failed to verify the XML signature.
---> System.Security.Cryptography.CryptographicException: Object was not found
The only thing happened between yesterday and today is installation of windows update.
Could this be related to that? Anyone had this issue before?
We got this issue resolved. Thanks to ComponentSpace for their quick response. bartonjs, your guess is right on all 3.
Windows update for .Net 4.6.2 started the issue. We had to rollback the update. Even though ComponentSpace was quick with response and their suggestion, we could not try that out right away, as we had to wait for maintenance window.
We tried the following last night and it worked
Created user profile for the Application Pool account. We had it
setup with a domain user that never logged into that box. So, had to generate that profile.
Updated IIS setting "Load User Profile" to True.
Installed windows updates for .Net 4.6.2, that we rolled back earlier.
Everything is working fine now.
FYI: The updates that caused this issue are
Update for Microsoft .NET Framework 4.6.2 (KB3205379)
Security Update for Microsoft .NET Framework 4.6.2 (KB3204805)
Thank you for your assistance.
Related
I've published an app to Azure for the first time. When I go to the site I get an HTTP 500 error saying
The page isn't working. *****.azurewebsites.net is currently unable to handle this request.
Looking at the Live Metrics Stream on the Azure Portal it says
Not available: your app is offline or using an older SDK
This is a .Net Core app.
When I published it there were no errors. It said the build and publishing were successful. I'm not sure what other information I can give to help someone help me resolve this. I'm including some screenshots that may have some helpful information. I've been stuck for a whole day now.
Below is an error from the Azure Portal:
Here is my web.config file:
Here are the general settings from Azure:
Here are some errors from Azure:
Here is the Publish page from Visual Studio (disregard the arrow):
I figured it out.
Earlier I had briefly experimented with using the .net Google Oauth library in my project. I eventually incorporated Oauth by hand and never removed the code for Google Oauth in Startup.cs. This didn't cause a problem locally but, the streaming logs showed an error saying the "ClientID option must be provided". ClientID is related to the Oauth library.
Viewing the Streaming Logs in Visual Studio is what helped me solve this. Maybe this will help someone in the future.
I'm having an issue where my asp.net web service is loading a certificate from the certstore but the private key is not available. Hovering over the property, is showing a WindowsCryptographicException.
The code is working fine under a console app. In looking at the X509Certificate2, it is only the PrivateKey that seem to not being loaded.
I found this link about a very similar problem using IIS. The accepted answer here was to ensure the the full user profile is loaded. Does anyone know how to do this in kestrel?
I've been digging thru WebHostBuilder docs but haven't seen anything yet.
Both the console and kestrel are running under VS 15.5/my user, which is admin, and setup for .net 2.0 runtimes.
We have a support website that we use to create custom orders for our customers. This website runs ASP.NET 1.1 and connects to PayPal using the PayFlow Pro API.
We also have a customer-facing website that runs ASP.NET 4.0 and also uses PayFlow Pro for connectivity to PayPal.
The customer-facing website is communicating fine with PayPal, but we're getting a "Failed to Connect to Host Uri" error from the support site.
Furthermore, we have a test server set up to run the support site, and it is communicating with PayPal with no issues. The only difference that I can tell between the test site and the production support sites is that test is running IIS 7.0 while production is running IIS 7.5. All DLLs and configuration files appear to be identical.
All of this started happening about a week ago, just after PayPal discontinued use of SSL. I would think it has something to do with the SSL switchover, but we have disabled SSL in IIS so I'm not sure where else to look. And why would the customer-facing site continue to work while the support site can't connect? They use the same infrastructure.
This isn't really the answer you're looking for but We've been facing the same issues since Jan 12th. We've taken the same steps you have and are seeing the same result. Interestingly, if we do an IIS reset it will start working again, at least for a while.
We did a Wireshark trace the last time the issue occurred and all we really found out is that the connection is being reset on the PayPal side. We suspect that the issue lies within the PayPal network, likely due to their recent SSL changes. I suggest you do a Wireshark trace when you're seeing the error and submit that to PayPal. That's basically what we're doing to try and resolve this issue.
Update:
After some testing, this does appear to be an issue with the recent SSL changes. We were ultimately able to reproduce this issue. What we believe we've discovered that if your .Net app calls any other web services which still allow SSL 3 (such as Youtube's API) then IIS will always try to use SSL3, at least until you do an IIS reset. Since PayPal no longer allows SSL3, the connection to PayPal fails. If you do an IIS reset, then try PayPal it will work, unless your app hits another SSL3 endpoint at which time your PayPal will start to fail once again.
Like you we have a admin application which does not live on the outside at all. Also like you, our eCom site is still working fine. We think this is because our eCom's do not make any SSL3 calls to any services, therefore the server that our eCom's are on never gets "stuck" on SSL3. Our internal app however, does interact with the YouTube API. It appears if we hit the YouTube API, which allows SSL3 then our PayFlow transactions start to error out. If we do an IIS reset, PayFlow will work, until we hit the YouTube API then PayFlow breaks again.
I know this is a bit circumstantial, but it may give you a somthing to go on.
Good luck!
btw, we also had SSL "disabled" in IIS but that did not appear to fix the issue.
This is also not the answer you have been looking for, but we too have been experiencing the same problem and despite several days working at it and numerous communications with PayPal we have not been able to resolve it.
This is the only post we have been able to find that matches our issue so I am going to point PayPal at it, perhaps if anyone else has a PayPal ticket raised, they can post their ticket number so we can prove to them that there is a wider issue than they are acknowledging. Ours is 150113-000138.
We are not in a position to reset IIS right this minute, but we will do so overnight to see if it allows a successful payment. I'll post an update later.
Update:
After a lot of research, trial and error we came to the conclusion that this is indeed a Microsoft issue and that an IIS Reset does indeed fix the issue until another connection is made from the server, knocking the connection back to SSL.
Our approach was to move the 1.1 site into a .Net 4.0 CLR. This was not plain sailing as there were several knock-on issues but with patience and careful debugging we ironed those out and now have a working website.
I had the same issue under Framework 4.6.1, my problem was caused by the web.config setting <httpRuntime targetFramework="4.5" />. When I changed the targetFramework to 4.6 it fixed the error for me. Hope this helps anyone with the same issue.
I am receiving the following error message:
Server Error in '/' Application.
Security Exception
Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.
Exception Details: System.Security.SecurityException: System.Security.Permissions.SecurityPermission
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:
[SecurityException: System.Security.Permissions.SecurityPermission]
MySql.Data.MySqlClient.MySqlClientFactory..cctor() +23
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.272
MySQL: mysql-connector-net-6.7.4
The problem only occurs if run from the shared web hosting environment. The site works great locally. I know the version of the .Net connector that my shared hosting environment uses, as that was another issue that I resolved and I was in communication with the hosting provider.
The error is interesting. I can go to the default page, no issues, the very first time. I then go to bring up a popup dialog, which throws another error message box.
Exception has been thrown by the target of an invocation.
The above is everything, except for the okay button.
I can bring up the first popup, a sign in dialog, which comes up. That dialog does not invoke MySQL. I bring up the second dialog, a registration dialog, which then throws the "Exception has been thrown..." message box. After that, I cannot go back into the sign-in dialog, as I get the "Exception has..." message box. If I press F5 to refresh the browser (IE or Chrome), I get the error from above. The above error indicates MySQL and some permissions.
I am suspecting that the "Exception has been thrown..." error is the result of the same MySQL, just the page has memory. Closing the browser window and launching the browser window again does not help, although on Chrome that works, just the browser window there really has to close down all the way.
I am in a shared hosting environment, so I have access to basically nothing, so I do not have access to any logs, at least that I can think of.
One final thought that may or may not be relevant. Yesterday and previous days my development work was done on a system with Windows 7 Professional and Visual Studio 2012 Professional (all latest service packs and updates), whereas today I am working at a different computer of mine, which is a system with Windows 8 Professional and Visual Studio 2012 Ultimate (all latest service packs and updates on the OS and VS). I was reading some other posts on unrelated issues that people with VS2012 Ultimate had issues, so I am not sure that has anything to do with it, but that is something that changed from yesterday to today.
Yes, I deleted everything off of the server and uploaded everything anew. I did a clean solution first, built the release, and then published. I still received the same error.
Any thoughts?
By default most hosts use "Medium" trust level. You can change your web.config as below to get full trust:
<configuration>
<system.web>
<trust level="Full" />
</system.web>
</configuration>
I'm having some problems running a webservice on my local machine. it's an asp.net webservice, which is using a .Net 4.0 Classic application pool. It works fine on everybody else's machine, and the live servers.
The problem: most request rely on basic authentication, which fails every time, with the correct credentials. Debugging, I can see that the basic authentication part of the header has been removed by something along the chain.
also, Application_BeginRequest in global.asax gets hit twice. Once with the original header (which then appears not hit any of the webservice endpoints) and then with the basicauth-less version.
The issue seems to go away if I switch the app pool to integrated, but unfortunately this isn't an issue as it fails for different reasons then.
I'd welcome any ideas of what is removing the basic auth from the header. I thought perhaps something in my IIS config, but I've reinstalled IIS without any luck.
Well it's fixed now. The noly thing I believe I changed was installing SP1 for visual studio 2010. I'm very doubtful that that was really the source of the problem though