I am trying to read and send email using Microsoft exchange webservice API. I tried to run this code for Outlook version 2010 and 2016 in my VMs its showing
The request was aborted: Could not create SSL/TLS secure channel
where as same code for office 365 its working fine. I even tried manual accessing outlook mails with URL and credentials and I am able to do it but through code.
Hi, we are receiving attached error also, it seems to be relates with your issue. We have started receiving this today by the morning. Could it be like a Windows update or something? We are still investigating this issue.
I’ll try upgrading the .net environment and replacing the web.config currently 4.5.2 with the 4.6.1
EDIT:
Yes, we have solved that issue. We used IIS Crypto 2.0 software to revert all tls settings to it's server defaults on Day-1. Then don't forget to restart the server of course. I think that Windows updates messed up with the TLS settings on Windows servers. Hope this will fix your issue.
Related
I'm using classic asp on IIS on Windows server 2012, and Server.CreateObject("Msxml2.XMLHTTP.6.0") to make soap requests against a payment processor, and "suddenly" it stopped working.
The payment processor has disabled TLS 1.0, we're supposed to do TLS 1.1 or 1.2; I think this is the cause of the problem...
How do I see and if needed change which protocol it uses?
Take a look here: https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls#systemdefaulttlsversions - specifically at sections SystemDefaultTlsVersions and SchUseStrongCrypto. You should also go ahead and disable all insecure ciphers/protocols/key exchanges in SChannel - the windows component responsible for SSL/TLS.
There is a GUI tool called IISCrypto from a company called Nartac that has some common profiles that are (somewhat) safer than editing the registry directly for disabling various obsolete components. see https://www.nartac.com/Products/IISCrypto.
Word of warning - be careful with your SChannel settings (either editing the registry or using IIS Crypto) - the settings are used throughout windows and are required for services like RDP and WinRM among other things - backup first, then test carefully.
I had similar situation - I have used Msxml2.XMLHTTP for API endpoint call in VB script and suddenly it stopped working. I got error "The system cannot locate the resource specified" and http.status returned 12029. The problem was not in the URL, it worked when I tried to call the URL from the browser. But when I started VB script, it has failed on the line http.send.
How I solved it finally?
I hade to install recommended update to my Windows Server 2012:
Microsoft .NET Framework 4.8 for Windows Server 2012 for x64 (KB4486081)
and I have installed one optional update too:
Internet Explorer 11 for Windows Server 2012 for x64
After this and server restart it started to work again. I can use both: "Msxml2.XMLHTTP.6.0" or "Msxml2.XMLHTTP", it does not matter.
I believe the problem is related to the latest release of Office 365, or of WinX. For some reason the information needed by QuickBooks to find the application's certificate related information is not being passed along from the Office code.
I wrote a console application linked to the same libraries used for my AddIn and it was able to connect to QB. Other users of my AddIn are still able to use it. I found that they were running an older release of Office365, 16.0.8229.2091 or earlier. The desktop that is failing is running Office365, 16.0.9229.2103 (previously I had this as .2013 instead of the correct version .2103). When I look at the Properties for the Integrated Application, the console version correctly shows the Developed By: and Developer identity verified by: information. When I do the same for the AddIn, it shows Unknown for the Developed By: and it shows: This application does not have a certificate. QuickBooks cannot determine the developer's identity.
Users have been running my AddIn for about two years now. I'm using the latest version of the QBXMLRP along with Visual Studio 2015 and version 4.5.2 of the .NET Framework. I used the same process to generate the test certificate and both assemblies were signed with sha256.
To the best of my knowledge, the program broke when the latest version of Office365 was installed. That being said, it could be an issue related to the latest patch of Windows and that information I do not have. However, given that other workstations can run the AddIn and have earlier versions of Office365, I'm thinking that's a pretty good indicator. And that I was able to get a console app to run, but the AddIn fails to access QuickBooks. It does load in Excel just fine, but it is not able to connect with QB.
I posted this issue on the QB forum and received the answer. It appears that Microsoft released an update of its Office365 Business software that caused the problem. They have since released a subsequent update that should provide remedy.
I've included a link for your convenience.
Good news, the problem WAS resolved by installing the latest update for Office365! Whew!! That was a real pain in the butt. A special thank you to William Lorfing at the Intuit Developer Group for keeping tabs on this problem and alerting others to the solution.
I was working on a windows store application and got this error while trying to renew my developer license. I have tried a lot of things by running updates and restarting my computer. I am working in a VMware environment. I have not been able to renew my developer license. Any one has an idea on how I can fix this problem?
This error seems to happen with incorrect date/time or failing Internet connection:
http://windows.microsoft.com/en-gb/windows-8/activation-errors
I am trying to setup a new connection to TFS with VS2012. Early on I was able to add my TFS server and, using the Microsoft Git Provider, clone a copy of the remote repository from within Visual Studio. Later, as I was fiddling with things in Team Explorer trying to find the branch I wanted to use, something broke. My local repository remains, but my connection to the remote repository was somehow corrupted, as evidenced with this error:
TF31004: Unexpected error encountered while connecting to Team Foundation Server at http: //my.server.com:8080/tfs. Wait a few minutes and try again. If the problem persists, contact the server administrator ok help
Things I have tried to resolve this:
Wait and try again (as the error message suggested).
Restart Visual Studio.
Reboot my machine.
Reboot TFS server.
Use system restore to revert back before I installed msysgit and Microsoft Git Provider, or had attempted to connect to the TFS server.
Review the MSDN help for the error (see below).
Search Stack Overflow (found one other related issue but did not seem to apply).
Tried devenv /ResetSkipPkgs
Tried devenv /setup
Re-install Team Explorer for VS2012.
Clear IE cookies (per this post).
Clear TFS caches (per this post).
The help page offers these tidbits, but none of them seem likely given that I had, as I said, the connection working at one point:
The version of Team Foundation running on the local computer does not match the version running on the Team Foundation Server server {name}.
The server returned HTML content instead of XML content.
The required Web service on the server could not be found.
Any ideas would be appreciated!
I have had an exactly the same problem.
My solution was to clear all the credentials in the Windows Vault (Credential Manager residing in the Control Panel).
I have no idea why the credentials did get messed up.
My question is this: How can I stop my .NET 1.1 application from trying to verify the digital signature in an environment where there is no access to the Internet?
Background to my question:
I have a product installed at a customer which is based on .NET 1.1 SP1. The customer site has no access to the Internet. This causes a delay in application startup which in some cases causes my Windows services to fail to start because they time out.
The delay when starting appears to be caused by the app attempting to verify the digital signature. This is well documented in other posts and the normal answer is to include generatePublisherEvidence=false in the app.config file, as documented here http://support.microsoft.com/kb/936707
It seems that using generatePublisherEvidence=false doesn't make any difference to .NET 1.1 apps, which seems to agree with MSDN (http://msdn.microsoft.com/en-us/library/0kk0kk35(VS.71).aspx does not mention the element) and with the hotfix I mentioned above, which was released for .NET 2.0 apps.
My next release to the customer will be built on .NET 3.5 SP1 and I have no problems with using generatePublisherEvidence on that version of the .NET framework, but I currently cannot simply change the customer to that release - I am stuck with .NET 1.1 SP1 - so I'm looking for an answer other than to simply use a later version of the .NET framework.
I just solved this for a vendor-supplied application today. I assume that their application was written in .net, but I did not confirm. Since the subnet did not have internet access, I removed the DNS server entry from the TCP/IP settings on the local computers that have static addresses. For addresses supplied by DHCP, I removed the DNS server option (006) from the DHCP scope.