When using Pusher over mobile internet we're getting these error messages while it tries to connect through the ws:// protocol. After failing it connects successfully through wss://.
What can I do?
Purchase the encrypted plan, and tell the client to connect "Encrypted: true" and all your troubles will disappear!
Related
We are creating an application where ThreadX based client would be communicating with IOT Hub. Made appropriate adapter changes to make client work with IOT Azure C SDK. We observe "Bad Certificate" error thrown by client on wire shark error. From wireshark we are certain that client sends "Hello" on which Server (IOT Hub) responds "Server Hello, Certificate, Certificate Request, Server Hello Done". It is here when client tries authenticate server certificate we see "Bad Certificate" being thrown. We are attaching in mail the root certificate we are adding to client and the wireshark we see stating bad certificate.
This is not about the Azure C SDK support for ThreadX.
If you are certain from Wireshark that the steps till Server Hello Done are successfully completed, most probably this is an issue with certificate formatting, may be missing escape character at the end of each line in certificate etc.
You can try using the Certificate fingerprint instead to see if it works.
I have an WAF application gateway in Azure with a backend pool that points to my application. If I visit the gateway address it works and I get the application homepage.
However, if I go to that application and enable PaaS AAD Authentication, which should prompt me with an org login page before getting to my application home page, the gateway stops working and returns message:
502 - Web server received an invalid response while acting as a gateway or proxy server.
There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server.
When checking backend health I can now see that it is unhealthy, and gives me message:
Probe status code mismatch. Received status code is different from
expected 100-999.
Note that I even changed the range to 100-999, just for testing this out. No idea what could be causing this or how to fix it.
I guess you can try disabling WAF as specified in the comments. Also, I would suggest you to go through this article. https://serverfault.com/questions/882931/azure-ssl-application-gateway-with-web-apps?rq=1
We have an ASP.NET MVC web application where we use digital signatures for both authorization and signing purposes. So in the SSL Settings of the website I've chosen to Require client certificates. I've also chosen to require SSL. But with some clients I have a problem with 403 Forbidden: Access denied error. If I choose to Ignore the Client Certificates the error goes away. Again, this error occurs only with couple of clients, the rest can connect OK.
The IIS version is 7.5
You might wonder the set up of those problematic and the rest clients in the network: There are two routers, A and B. Some clients connect to A and some to B. The above problem occurs on both cases. So nothing like the problematic clients are connected to router A or B.
Had this error for awhile not to long ago, unfortunately it could be anything in the setup. I'll take a shot in the dark and the client is using the machine name? and not the pre made user used for the service.
We are having issues with Connect notifications from our DocuSign demo account.We are not able to receive any updates from our Connect configuration. Though, when I republished the XML from Connect logs, I did receive a Connect update to a specified URL.
When I created new envelopes using API as well as from DocuSign account itself, I never got any notifications to the same URL.I do not even see a Connect log.
We do not have any issues with Connect notifications for our DocuSign live account.
We have never experienced this issue before with Connect updates from our DocuSign demo account.
Please advise.
Just a hunch - do you use http or https? connect can only work over port 443 with a valid SSL certificate. If you're on localhost - you may need to get a temp certificate or something like that but also using azure websites is good way to avoid this issue since they're pretty much just as good as working on your localhost
I already spent so much time trying to figure out what the problem is. I am getting this error when consuming WCF service from a desktop console application. The service works fine when access from a browser with silverlight client.
Error Message:
System.ServiceModel.Security.MessageSecurityException: The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM'.
I don't understand why it doesn't work even if both client and server have same authentication scheme 'Negotiate'. I am getting HTTP 401.
I verified client and server configuration is correct, because it works in silverlight client using the same client configuration.
IIS7 website is configured with Windows Authentication using providers 'Negotiate,NTLM'.
So, what does this error message mean? :(
I have fixed my WCF issue by setting client security.
client.ClientCredentials.Windows.ClientCredential = System.Net.CredentialCache.DefaultNetworkCredentials;
client.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;