I am attempting to validate a certificate using X509Certificate2.Verify() (and/or it's C++/CAPI equivalent).
The issue is that when Internet Explorer's connection settings specify a proxy which requires authentication, the OCSP check will always fail (the OS can't check that the certificate hasn't been revoked, since it doesn't have credentials to pass through the proxy.)
Microsoft has a KB similar to this, but doesn't really offer any sort of a fix.
http://support.microsoft.com/kb/915787
Even if I have the credentials (username and password), I am unable to pass them to the cryptography API (in either .NET or native).
Is there a solution which allows certificates to be validated even when there is an system default proxy which enforces authentication?
Thanks!
Edit:
Some indications from Microsoft that this is simply impossible:
"CryptoAPI also may not be able to authenticate to a proxy or to caching servers that require basic authentication to reach the HTTP URL that refers to the CRL distribution point."
http://technet.microsoft.com/en-us/library/bb457027.aspx#EFAA
"Authentication to proxy servers that do not use Windows Integrated Authentication in certain programs may be unsuccessful. This issue occurs because the Winhttp.dll process is designed for use by non-interactive services and does not prompt the user for network credentials."
http://support.microsoft.com/kb/887196
Related
There is an example in gRPC:
Channel channel = new Channel("127.0.0.1:30051", ChannelCredentials.Insecure);
it works. Now I would like to authenticate the user on server either using the login / password pair or using Windows trusted authentication.
The authentication documentation https://grpc.io/docs/guides/auth/ shows some examples:
either with some PEM certificate that has nothing to do with windows account
or with a "trusted" authentication, but not in the meaning that one Windows computer trusts to the other Windows. The meaning is that credentials are trusted with Google.
Is it possible to do Windows-trusted authentication between two Windows PCs using gRPC?
I believe client-side SSL is what you are looking for: https://grpc.io/docs/guides/auth/#using-client-side-ssltls
You want to authenticate both ends of the connection. This won't be a simple task, since you have to manage and update certificates in clusters.
If what you are looking for is Windows account specific integration, I don't think gRPC is providing one today. You may post a feature request to https://github.com/grpc/grpc/issues.
I'm working on securing some Azure Functions endpoints. I tried with Certificate, but I hit a few walls
In the FunctionsStartup (from which derives my startup) I could not find a way to connect my AddAuth and Auth methods/classes. (I tried to search, read more on this topic, but all the answers were either for web API other type of Authentications)
I tried to check for the existence of a certificate at least, but that didn't worked either. I tried to get the certificate from request-context-connection-ClientCertificate or to read it from headers. Didn't worked locally or on deployed version. The certificates are always null.
I saw that there are some options to secure it with AD(also with facebook, google and so on), but first I'm curious if someone successfully implemented another Auth method, more like in a classic web api approach (JWT tokens, certificate, other similar stuff)
Access restrictions enable you to define a priority ordered allow/deny list that controls network access to your app. The list can include IP addresses or Azure Virtual Network subnets. When there are one or more entries, there is then an implicit "deny all" that exists at the end of the list.
Also you can request a client certificate when the client request is over TLS/SSL and validate the certificate. This mechanism is called TLS mutual authentication or client certificate authentication.
First, your App Service plan must be in the Basic, Standard, Premium, or Isolated tier.
Secondly, enable client certificates:
az webapp update --set clientCertEnabled=true --name <app_name> --resource-group <group_name>
Finally, Access client certificate. App Service injects an X-ARR-ClientCert request header with the client certificate. Your app code is responsible for validating the client certificate.
For more details about how to configure TLS mutual authentication for Azure App Service, please refer to this article.
I have an application that can be downloaded from my website and run on user PC. This application doesn't do anything special and just allows the web page to access the scanner. It uses SignalR for communication.
Basically, I run SignalR server under WinForms application and have javascript client that tries to access it through http://localhost:8084/signalR.
Everything works fine when I use HTTP version of the web application, but fails, when I use HTTPS for my web application: Most of the browsers don't allow unsecured connections from a secure page.
So, I've created a self-signed certificate that is installed on user system during installation and it works fine for Chrome, IE and Opera, but fails for Firefox and Edge.
So I was thinking, is there a better way to access SignalR applications that are running on localhost from webpage under https?
There isn't a better way. You are correct in your understanding that "[m]ost of the browsers don't allow unsecured connections from a secure page". I believe there isn't a browser that will allow this. Therefore if you want to call out from a secured website, you must use a secured connection as well.
I don't know the issue you're experiencing with Edge, as I can confirm that it does work. Firefox will NOT trust a certificate in the cert store, even if it is a trusted root or has a trusted root certificate. You have to manually add an exception for this certificate. Details, or at least information that will let you find the correct method to do this, can be found here.
There are some things you have to do in order to make sure your certificate and configuration is correct. First, you have to have a well formed certificate with a public and private key and a well formed certificate authority cert with only its public key. By "well formed" I mean it must contain all information required by browsers for full trust, such as a Subject Alternative Name entry.
You can use OpenSSL to generate the CA, then use that to sign a certificate you will use for the SSL port. Export the CA's public key and the SSL certificate's public and private keys. Exporting the CA's private key is a MAJOR no no. That would allow third parties to create new certs from it and install them on your client's machine. The CA gets installed in the machine's Trusted Root Certification Authorities store. The SSL cert can go into the Personal/Certificates store.
Once you have these, you have to configure the URL/Port you will use for access and SSL using the netsh command line tool. Add a URLACL to allow the application to access the url and port (netsh.exe http add urlacl), and then assign the certificate to the port (netsh.exe http add sslcert ).
Having done all this, you should be good to go. The only real problems you should have are Chrome being very demanding about the configuration of your certificates and Firefox refusing to trust your CA certificate even though it is in your trusted certificate store. Bastard.
And for Edge, I can definitely guarantee if you do all the above it will work. If it doesn't, you need to consult the js console to see what errors it is throwing.
We are about to implement SSL for a .NET Framework product that uses a service layer which in turn uses NancyFX and REST/JSON.
The clients communicating with the service need to access it through HTTPS, hence the need for a certificate. We are running on both Windows and Linux (through Mono) and the user is prompted for a username/password or sending it through auth header.
To get the clients to trust the certificate, it must be assigned by a trusted CA but how do we solve this when we do not know anything about the address on which the service is configured?
So - how to get a trusted certificate assigned to the installed service with a minimum effort for the user. Best thing would be to handle this through a normal Install procedure (on Windows). Is this possible?
We have a large number of users (> 5000) that will go through the upgrade process and will be needing the certificate, so to manually create and assign certificates does not seem like an option.
There's a load of stuff to cover, so I'll try to keep it structured, as all good programmers should.. bear with me.
My Environment
.NET 3.5 SP1 Smart Client
Uses WCF+SOAP over HTTP to communicate to server for business logic / data access
Typically uses a custom (username+password) or Windows authentication scheme
Current work aims to extend to include a new Claims-based authentication scheme to facilitate SSO with ADFS
So far...
Main service endpoints using ws2007FederationHttpBinding bindings, configuration set up with Message security via trust/13/issuedtokenmixedsymmetricbasic256 ADFS 2.0 endpoint
Issuer endpoint configured with IssuedTokenOverTransport to HTTPS trust/13/usernamemixed ADFS 2.0 endpoint
Service has federateServiceHostConfiguration service behaviour specified
Created temporary certificate authority (CA) cert
Created temporary certificate signed by CA
Installed certificate (including private key) and made available to IIS app pool process account
Updated service WCF config to use X509 certificate
Client modified with new app’s own Client scheme/mode, programmatically sets up channel factory to ignore errors caused by temporary certificate and disables certificate revocation checks
Username/password credentials are successfully added (via standard WCF ClientCredentials object) to SOAP envelope of token requests
Token is successfully generated by usernamemixed endpoint and is returned to the client
My problem
Immediately following the token being issued, the subsequent call to issuedtokenmixedsymmetricbasic256 endpoint fails with generic error message that the security of the message could not be validated. Inspection of the SOAP envelope result gives no information at all beyond a simple ‘failed’ result enumeration value
Full tracing has been enabled on ADFS 2.0 server, but no events are logged at all in Event Log or event traces to further diagnose
Unable to configure to work in a federated manner thus far; token is successfully issues over usernamemixed endpoint in the ‘test’ environment (the internal ADFS server rather than a remote one). Use of the ‘live’ environment gives a simple unexplained 401 HTTP status code whether using usernamemixed with confirmed and valid credentials, or windowsmixed, when trying to obtain a token
Generally: Resources from Microsoft or other sources are either very scarce, very specific to one situation, and in a couple of cases, completely wrong or misleading
So ask a question already, doofus
Why does the call the issuedtokenmixedsymmetricbasic256 that WCF makes after getting the token fail? How can I diagnose the result? Other than what I've already done - enabling all trace flags in the service host config, checking the event log and event tracing data, what can I do?
Note, if you're about to suggest a link to a screencast/guide/blog/seemingly all-encompassing MSDN article, please stop. I believe I have found them all, tried them all, and what I need at this point - if you can help me please - is an answer to the above question. Not a general resource.