i am using azure webapp with microsoft auth.
has been working fine for months.
however today it is broken.
the login.microsoftonline.com page is failing with css and js loading errors.
ie Request URL:https://secure.aadcdn.microsoftonline-p.com/ests/2.1.7415.7/content/cdnbundles/watsonsupport.min.js
is failing with a
SSL_PROTOCOL _ERROR
i tried raising with azure support but i cant login into the azure portal as it also uses login.microsoft.com page.
anyone able to help?
-lp
I have found a solution to my version of this problem. I am in Australia, my ISP is Telstra and I have a NBN connection. I do not have a proxy server.
I found changing the DNS servers from the Telstra default servers (61.9.194.49 & 61.9.195.193) to Google's DNS servers (8.8.8.8 & 8.8.4.4) fixes the problem. If the DNS servers are changed back, the problem reappears. Changing the DNS back to Telstra reintroduces the problem. Changing them back fixes the problem. (You must flush the cache each change).
Hope this helps - but can only speculate as to why. Microsoft have accepted this as the solution to my problem and closed the support case.
The problem no longer exists when using the Telstra default DNS.
I suppose the take-home message is to remember your ISP sometimes caches stuff, mostly a good thing, but on the rare occasion causes problems.
Related
I've been working on an old secure website on my local machine's IIS on occasion. It's probably been a couple weeks since the last time. However, now all of a sudden IIS seems to have a problem with it. I can't even get to the root page. Chrome reports a general failure. Edge is more informative with:
This might be because the site uses outdated or unsafe TLS security settings. If this keeps happening, try contacting the website’s owner.
Well, I'm the website owner and I have no clue what might have happened. It works fine in production, but the local development version suddenly just doesn't work. So far I haven't found anything useful on Google. Is there a common checklist for troubleshooting these issues?
Security certificate under bindings was set to "Development" originally, but that vanished. Reset it and good to go again!
I created a new Azure Web App (web site) on the path https://todoangular1-b-nschou.azurewebsites.net and I tried to access the Kudu Debug Console by inserting 'scm' between the application name and the domain name. Like this:
https://todoangular1-b-nschou.scm.azurewebsites.net/
However, the site is not available.
Some more research showed that the error was caused by a failing DNS resolution. I then added an entry to my hosts file pointing todoangular1-b-nschou.scm.azurewebsites.net to the same ip-address as todoangular1-b-nschou.azurewebsites.net and suddenly it worked.
My own conclusion is that the Azure platform did not properly add the new DNS-name under the scm.azurewebsites.net zone. Did anyone else experience this odd behavior?
What probably happened is that there was a small delay in DNS propagation. But if you try hitting the site before that, you would then be affected by DNS negative caching on your machine, which can last a little while. My guess is that during that time, if you had tried to access it from a different machine that didn't have the negative caching, it would have worked (and it works fine now).
I'm currently developing a web application running locally on IIS 10 with coldfusion 9.
I have a problem right now, caused by SSL I think. Since it's a backoffice, it has to be https, so I used our company certificate to install it locally on my computer and I linked it to the website I'm developing. The problem is whenever I use the https connection, all the pages are loaded twice (it isn't visible, but for instance when I submit a form, the data are inserted twice in the database).
I manage, with luck, to solve this issue by changing the SSL parameters "client certificates" from ignore to accept but when I do that, from time to time (like 1 out of 3) the page that I want to load takes forever (like 30s) and as I can see, uses 100% of the CPU.
It doesn't come from my code (I think) because when I navigate with http, I have none of the problem listed above.
Does anyone have an idea with this is happening and how to solve it ?
Thanks in advance ! If you need any further information, ask and I'll try to give it to you !
I've now installed Coldfusion 11 and with that the issue is not happening anymore. So I'm pretty sure it's a compatibility answer.
Just recently I am having trouble accessing the nuget.org website and using the Package manager inside of Visual Studio 2012. In fact just yesterday evening when I attempted to install some packages I encountered the above error. In addition I can not access www.nuget.org from any of my web browsers or my iPad on the same network.
As far as I am aware no changes have taken place on my network. I attempted to navigate to www.nuget.org through a proxy and it did load. So I can only assume there is a problem with my network/IP.
Has anyone ever encountered this problem?
The problem here is probably the DNS provider, to test try to extract the ip address of www.nuget.org (I did that for you, it is http://65.52.233.252/), try to connect from your browser with the ip address without proxy, if it works the your dns provider has an issue,
you can have a quick solution and use OpenDNS by entring there ip address in you dns configuration,
I've been struggling with a problem now for a few hour and I cannot find any answers or anyone with the same problem -
Some menu items are missing on my site www.namhost.com (Drupal 6.22) and when viewing the blog it shows "No blog entries have been created". When I log in as admin everything works fine, so this problem only occurs for anonymous/guest users.
I've changed nothing on the site which may have caused this problem and here comes the really strange part - When viewing a copy of the site locally everything works 100% even for anonymous/guest users.
I've tried:
flushing caches
rebuilding permissions
checked if the "anonymous" user is present in the database
viewing on different browsers
None of these yielded any results.
Because the problem doesn't occur locally I'm starting to believe this could be a problem on the server the site is hosted on (Linux with PHP5.2), but the admins had a look and couldn't find anything.
Any help/insight would be highly appreciated.
================FIXED<<<<<<<-----------------------------
I am not allowed to answer my own question and it was suggested that I edit the question to include my answer so here goes:
Firstly, thanks for all the responses.
I disabled the "ACL" module (http://drupal.org/project/acl) and the problem was solved. It was previously used for our forum which was also disabled a few months back, so it's not needed any more.
I still have no idea why this module caused the site to work locally but not on the server. I will be in contact with the server admins to find out if they changed/updated anything on the server which may have caused this module to cause a malfunction.
Any insight could still be helpful top prevent this from happening again.
Check your Drupal config:
Are you using node_access, content_access, or any other permissions-related addon mods? Disable them and see if the problem persists. If that doesn't work, disable all non-core mods and re-enable them one-at-a-time until you find the offender.
Compare your hosting configs:
If it's not related to Drupal, compare the local and remote server configurations. Do both use the same versions of php, apache, apc, cgi, etc.? A phpinfo(); on both servers should give you the most important details for comparison. Do a similar comparison of the MySQL setup and content. Finally, check for differences in your .htaccess files (if any) between the two locations.
Test another hosting enviornment:
Download a virtual appliance like QuickStart which is already configured to host Drupal sites for development and non-production purposes, and see if the site works correctly in that. If it does, you could do an additional validation by porting to a new host who offers a trial/money-back-guarantee and see if it works correctly there.
If your site works fine elsewhere, give your current host a good thrashing for making you go through all of this to figure out the problem lies on their end.