We have a ASP.NET web service which needs to receive a client cert from another service. We have configured our cloud service in IIS to "Accept Client certificates" in IIS Manager (we do not have "Require SSL" check marked in the SSL settings of our website). Occasionally when we attempt to get the client certificate in with the following code (Asp.Net):
httpAuthenticationContext.Request.GetClientCertificate();
we get null. This issue is intermittent. Sometimes, GetClientCertificate() returns the expected cert.
While not this exact issue, we periodically have issues in our Azure implementation of requesting data from a file, database, etc. that we know exists, but fails to return data.
We learned to just wrap these calls with some retry logic, with a brief delay in between. If the calls fail a few times in a row, we throw an error, but for these "transient" issues, sometimes a simple retry will do the trick...
Hope this helps
Related
It might be a dummy question on security.
I'm working on a file access service, trying to do authentication for it.
For example, I should be able to know who's the request issuer, and whether he/she has the permission to access the file he/she requests.
I'm using grpc to do communication, and grpc seems to natively support a bunch of authentication methods. I tried one of them (https://grpc.io/docs/guides/auth/#using-google-token-based-authentication). The client side code is exactly the same as in the doc. I'm using C++.
But I get the error
E0812 19:03:32.173663955 3576491 ssl_transport_security.cc:1509] Handshake failed with fatal error SSL_ERROR_SSL: error:100000f7:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER.
I'm wondering what else should I do?
We will be connecting to a web service over https. This will be triggered in the background if a user performs a certain action.
The link will be between the server and the web-service though - the user will not be aware of it.
As there is no user there to see the certificate come up with an error - because this is server to server - how can we mitigate a man in the middle attack between the two servers? What would happen in the code if one were tried and the certificate failed?
We are using ASP.NET.
Its up to you - you can specify your own validation behavior via
ServicePointManager.ServerCertificateValidationCallback
Reference: https://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.servercertificatevalidationcallback(v=vs.110).aspx
Default implementation is very reasonable - throw an exception when validation fails.
If you are using a well-written HTTP client library to consume your web service, the calls will fail if the certificate validation fails. Correct http client library will do full validation including making sure that hostname it connects to matches the subject name of the certificate, that CA is correct etc. I would hope that .NET's implementation is correct in that regard, but you should definitely test and validate that default behavior is correct.
When I open the details window on any of my API Proxies using the APIGee Developer Dashboard, I get two error messages
Error while fetching object: No server entry found with ID long token goes here
and
Server Error: No server entry found with ID same long token goes here
The page still seems to function partially, but this prevents me from seeing my API proxy deployments and proxy information, or from tracing calls to the API.
I can't figure out what triggered this error - I don't see any recent config changes and the API proxy and the endpoint services are up and running. There's no reference to 'Server Entry' anywhere on the config page or in the help, which makes it hard to know where to start when fixing this.
Please see here: http://status.apigee.com/
This could be related to the platform release in flight.
You can subscribe to this for future updates too.
If the issue still persists, do raise a support ticket http://apigee.com/about/support/request-support
I have created a webservice in a ASP.net. All the access to the respective website is done through HTTPS. The service which I have added is only one among many others.
I am trying to access just for test purposes this service through Javascript (Ajax, json). The final target is actually Android.
I am getting the following message:
401 - Unauthorized: Access is denied due to invalid credentials.
You do not have permission to view this directory or page using the credentials that you supplied.
The main problem here is inconsistency: while my webservice in inaccessible, another previously written webservice is accessible. Another apparent inconsistency is that even if I tried a compromise solution by adding the needed methods to the accessible webservice, these methods themselves incur a 401 error.
So, my question is related to both "Why doesn't my webservice work" and "How is this supposed to work", with more emphasis on the latter.
Thank you.
Never mind !
Since I was oblivious to the depths of the code I was changing on our server, I did not know that the 401 error message is sent due to the way the code is organised. To access other services, I had to authenticate first through the authentication webservice.
When accessing an application I've written FireBug shows that each call to a web service or HTTP handler is attempted three times, and the first two times show as '401 Unauthorized' even though they return the correct result. This consistent. Every call does this same thing.
Any ideas why this happens?
It is performing a negotiation for NTLM authorization. Check on the MSDN on Microsoft NTLM: http://msdn.microsoft.com/en-us/library/aa378749.aspx
This occurs (in certain setups) when accessing an IIS server marked as Integrated Windows Authentication.
This occurs only when using NTLM (and not Kerberos), it's part of the NTLM authentication process.
Are you sure that the calls that return 401 are also returning the correct result? They should not be.
This sounds like a negotiation for authorization.