I'm making my first steps in the UCMA world. The samples Microsoft delivers as part of the SDK seem simple enough, but I've hit a snag. If I run any of them from my dev box, I get an AuthenticationException when establishing the UserEndpoint.
The message of the exception is "Unable to perform authentication of credentials". Drilling down to the inner exception, I see this
NegotiateSecurityAssociation failed, error: -2146893039
My Skype 4 Biz pool is in a different domain than my dev box (in fact the dev box is not domain joined), the Skype4B domain CA is trusted though so the error comes somewhere later than in the establishment of a TLS session (initially I got a TLS error since the CA wasn't trusted).
Reading through the SDK documentation, in the chapter about activating trusted applications it is stated that unless you intent to run the Skype4B commandlets or use UCMA auto-provisioning, the machine running the app does not need to be a domain member. So now I'm thoroughly confused.. the same code works in the domain, but doesn't work on my dev box. It can't be a firewall issue because I run some of the clients in my skype4b domain in the same subnet as my dev box.
So what could I be missing?
I'm guessing since you are talking about UserEndpoint's that you are just starting a simple user endpoint UCMA application and you are supplying the username/password to the UserEndpoint?
If that's the case then it's most likely the certificate presented by the Lync server is not trusted your non-domain joined machine. You will need to manually add the root certificate that the Lync Server is using into the trusted cert store on your non-domain joined machine. This is normally the root certificate used by the domain in general, which is why it works on domain joined machines as this certificate is added automatically.
Another test you should do is see if the Lync client runs and connects to the lync server from the non-domain joined machine. My guess is that it will not as it will have the same certificate problem.
The Lync client / UCMA application errors around certificate failures are really bad and hard to understand!
Related
So we have some software that when installed runs a web app on iis at localhost on the users machine..
In order to use ssl we provide the user with a self signed certificate.. which results in an error like this when opened on chrome on the users machine..
I'm assuming this is because we are using a self signed certificate..
Now I noticed if I set the sites certificate to IIS Express Development Certificate the error went away.. and the site loaded normally on chrome..
So what I'm wondering is if I can install the software that runs the web app on the users machine. THEN can I programmatically set the web sites certificate to IIS's "IIS Express Development Certificate"?
Is this ok to do?
It to OK to share a self-signed certificate with your customers, but that's really not the best practice. For example, if the machine is compromised and the self-signed certificate is replaced by another one generated by the hacker, the customer usually won't notice the difference but the hacker can gain more access (and perform more damage).
Instead, allow your customers to use their own certificates and that's quite common in real world, as many customers have their own AD and CA configured already. They can issue their own certificates for clients/servers.
If you insist using self-signed certificates, ask your customers to trust such manually, for Edge/Chrome,
https://docs.jexusmanager.com/tutorials/self-signed.html#to-trust-self-signed-certificate
Firefox needs another procedure.
IIS Express Development Certificate should trigger the same warning by default, but this specific customer might have already trusted it on this machine. However, you cannot assume such applies to all your customer machines.
I have the following implementation in testing environment,
Front-end Server [IBM HTTP Server + IBM Websphere plugin],
WLServer1 [IBM Worklight 6.2 + IBM DB2 10.1+ Liberty Farm 8.5.5.1] and
WLServer2 [IBM Worklight 6.2 + IBM DB2 10.1+ Liberty Farm 8.5.5.1].
plugin-cfg.xml has been generated from each Worklight server and merged.
The request[http] from multiple devices has been directed to worklight server's alternatively, once the merged plugin-cfg.xml has been deployed in Front-end server's IBM Websphere plugin.
How I can implement the same to serve HTTPS request.
And also I have implemented the "UserCertificateAuthenticationProject" from the Worklight modules which connects the device[HTTPS] to Worklight server directly.
Note Tested it on Android only.
Help me to understand, How I can achieve HTTPS in Test environment via IHS.
What should be the procedure in Production environment?
Note IBM Worklight 6.2 supports Android, IOS, Blackberry & Windows, so I have to implement in all platforms.
It sounds like the problem you are having is similar to this one: https://stackoverflow.com/a/21914147/2245921 The Unresponsive Host error occurs for one of two reasons:
Your device cannot reach your server (they are not in the same network)
The device does not trust the server's certificate
Since you can connect to your HTTP connection, it is not #1, so it should be #2. The answer to the other question I pointed to above should fix your problem. Make sure to turn on trace-level logs in the WL Logger so that you can see the exceptions regarding untrusted certificates.
Edit: To expand on this answer; to use HTTPS, your server needs an SSL certificate to identify itself, otherwise the device has no proof that it is connecting to the right server and not to some random server that could be malicious. You should already have a certificate that you are using in your server; if you don't, then read on.
You usually get an SSL certificate from one of two places: you either use a certificate issued to you by a trusted Certificate Authority (e.g., Verisign), or you create one for internal testing purposes. In your case, you probably want to create your own, so you should follow the "Client X.509 Certificate Authentication and User Enrollment" getting started here, specifically the parts that talk about generating the server certificate.
Once you have that certificate set up, you should configure your server to use it; for that, follow the instructions here. After doing this, the last step is to have your device trust your server's certificate. For this, follow the last part in the getting started above, which shows you how to make your iOS/Android device trust the server. You would have to look up how to do this on Windows and Blackberry, too.
After this, you should now be able to connect successfully via HTTPS. (Always make sure that when you get an "Unresponsive host" error, that you can still connect to the HTTP console via the browser, to make sure that you are connected to the same network as your server. I know you already did this as you specified in your question, I'm just mentioning it as a reminder since it is easy to forget this.)
I have a WCF service that I want to secure with Client Certificates but I cannot get it to work on Azure.
I removed Azure from the equation by hosting the service on a standard Windows Server on Amazon. I installed both the service and client certificates (none are self-signed) into the Local Machine 'Personal' store on this server including the chained certificates and it all worked as expected, called from my local PC, with the client cert set against the binding/behavior. It did not work without the certificate being specified so it definitely worked correctly this way.
I then deployed the service to Azure. The client and server certificates are uploaded to the portal and set in the config against "Local Machine/My" and the CA and root certificates are uploaded and I tried them in various stores including "My", "Trusted" and "CA". Every variation I try, I continue to get "The HTTP request was forbidden with client authentication scheme 'Anonymous'" called from exactly the same program locally with the only change being the client endpoint address.
As another detail, I can get it to work without certificates so there is no problem with the web service but I am unsure how to work out what is actually happening with the certificate handshake between client and service.
I have finally got it to work, and have written a guide here: Blogspot.co.uk
I'm not sure what I had got wrong before since I have not done anything too weird to make it work. I think perhaps I had a small defect somewhere in configuration that I eventually fixed by starting again. Anyway, it DOES work and provides some useful security on Azure.
See my answer to this SO post - bottom line, cert in LocalMachine/My and run with elevated privileges in csdef file add:
<Runtime executionContext="elevated" />
Background:
I am updating an internal application to a two-step authentication process. I want to add a client certificate authentication process (via a smart card) on top of a traditional username/password form. The application is written in C#, hosted on IIS7, and targeting Chrome and IE8.
Problem:
I am having issues with getting the application to prompt the user for a client certificate. I have been debugging the application with the help of Fiddler. When I have a test client certificate saved in Fiddler's user's directory (C:\Documents and Settings\USER\My Documents\Fiddler2), the application works as expected. I am prompted for a PIN number protecting the smart card, and, when entered correctly, takes me to the login form. When I close Fiddler, the application throws a 403 Forbidden error instead (since Fiddler is no longer running and pointing to its certificate). What I haven't been able to figure out is why the application won't prompt for a certificate normally.
Current Server Setup:
Self Signed Certificate was created
443 Binding is pointing at Self Signed Certificate
Anonymous Authentication is Enabled
The Self Signed Certificate was added to both the Trusted Root CA and Intermediate CA (I read that another person had it in both rather than just the Trusted Root CA and that solved their issue, though neither set up has worked for us).
I cleared out the rest of the certificates in the Trusted Root CA that I didn't need (I read elsewhere that having too many certificates would cause SSL to choke).
I am out of ideas to try other than starting from scratch on another server. Does anyone know what the issue might be? This seems like it should be fairly straight forward and that I'm missing something minor. Any ideas are welcomed.
Update:
After spending more time with this issue today, I strongly believe it has to do with IIS7 not being configured correctly (I did not set up it originally). I think this because I enabled Failed Request Tracing, looked at the subsequent .xml files being generated, and saw that a 500 error was being thrown.
Chrome is throwing a "Access to the webpage was denied" message rather than a "403 - Forbidden: Access is denied". I don't know if this helps. I do know that when I do not make certificates required, the site will work as intended. Requiring a certificate is where it fails.
The Application Pool is set to .Net 4.0 | Classic | Network Service.
Your problem is that the browser doesn't either get the request to provide client certificate or there is a security related option to block it from happening. IE offers certificate only if the web site is in correct zone (intranet or trusted sites). Please check this before everything.
If that doesn't help then see this answer for next step. The netsh documentation says:
clientcertnegotiation
Optional. Specifies whether the negotiation of certificate is enabled or disabled. Default is disabled.
Enable that and even the dumbest browser should notice that it is supposed to offer certificate for authentication. To diagnose your problem further you can use WireShark to see the negotiation in action.
In every browser I've seen, the browser will not prompt you to select a certificate if it does not have any certificates signed by a CA the server trusts. So make sure your server is configured with the correct CAs. As Boklucius suggested, you can use openssl to examine the list of trusted CAs your server is sending to clients and see whether the CA you have signed your client certificates with is among them.
Try openssl s_client -connect yourip:443 -prexit
And see if the CA (your self signed cert) is send to the client in the Acceptable client certificate CA names.
you need to install openssl first if you don't have it
I'll throw in a "try restarting the browser" suggestion, particularly if you installed the certificate while the browser was running.
To add a rather painful lesson to the mix: Make sure you quit Skype (or any other application) that eats port 443.
So the idea here is if you are running a dev environment on the same machine (both client and IIS), and your team uses Skype or some other app to communicate.
Watch the hours go by as you try and debug this problem, seemingly doing everything "right", netsh http sslcerts and such, even rebooting but to no avail. Well, turns out Skype will eat 443 so turn it off and "poof" there goes your certificate prompt.
Then feel free to throw things at the wall, shout obscenities or just "Rage, rage against the dying of the light".
Also, make sure Fiddler isn't getting in the way. If you have it decrypting the SSL, it'll corrupt the message back to IE, and it doesn't have the certificate installed, so it can't offer it. Turn off fiddler, and voila, the certificate prompt appears.
In Firefox, if you press 'Cancel' the first time you're prompted for a certificate, and you left the sneaky 'Remember this decision' box checked, then Firefox will remember that and never offer it again.
You can view and delete your previous remembered decisions in Firefox Preferences -> Privacy & Security (about:preferences#privacy), View Certificates, and check the Authentication Decisions tab.
Just connecting to my VPN and trying showed me the certificate prompt. Needs to be done only the first time.
Context
I developed an application deployed in a Glassfish 3.1. This application is accessed only by https and sometimes it must connect to third-party webservices located out the customers networks. The customer have other applications inside his network; mine is only a new one "service".
Topology approximation
Big-ip F5 is the ssl end point. The customer have in this device the valid certificate
IIS redirects by domain to the respective service
glassfish is the machine with the application (over, of course, a glassfish 3.1)
How it works
When a user try to connect to _https://somedomain the request arrives to the F5 where the SSL encryption ends; now we have a request to _http://somedomain. In the next step F5 redirects this request to the IIS and this, finally, redirects to glassfish. This petitions are successfully processed.
Points of interest
I've full control over glassfish server and S.O. of the vm where it is located. Not other applications are or will be deployed on this server; it's a dedicated server for the app and some services it needs. The Glassfish runs on a VM with a Debian distribution as S.O. This VM is provided by a VM Server but I don't know the brand, model, etc. The glassfish have the default http listeners configuration.
I don't have any more information about network and other devices and i can't access to
any configuration file of any other device. I can't modify any part of the network for my own but maybe ask, suggest or advice for a change. Network's behavior should not change.
Actually users reach the application without problem.
The used certificate is a simple domain certificate trusted by Verysign
The customer have no idea of how to solve this.
The problem
All the third party WS the application must access have an unique https access and, in some cases, the authentication required is mutual (two-way) and here we find the problem. When the application wants to connect to WS with mutual ssl authentication it sends the glassfish local keystore configuration targeted certificate. Customer wants, if possible, use the same cert for incoming and outcoming secure connections. This cert is in the F5 and i can't add to the glassfish keystore because if I do this I would be breaking Verysign contract requirements. I've been looking for a solution at google, here(stackoverflow), jita,... but only incoming traffic solutions I've found. I understand that maybe a SSL proxy is required but I haven't found any example or alternative solution for the outcoming ssl connections.
What I'm asking for
I'm not english speaker (isn't obvious?) and maybe i doesn't use the correct terms in my search terms. I can understand that this context can be a nightmare and hard to solve but I will stand... The first think I need is to know if exists a solution (or solutions) for this problem and if it (or they!) exist where or how can I find it/them. I've prepared different alternatives to negotiate with the customer but I need to known the true. I've spent tones of hours on this.
There are a couple of solutions.
1)pay verisign more money for a second "license/cert". They will be happy to take your money for the "privilege". :)
2)Create a different virtual server listening on 443 which points to a pool that has your client's server address as the pool member. Then on the virtual server, attach a serverssl profile that is configured to use the same cert you are using for the incoming connections. Then the F5 would authenticate with the same cert along with your app server would not need a client cert installed. Also, if they need to initiate a session to you, you would have to setup a virtual server with a clientssl profile that uses the same cert and requires a client cert to connect.
If your destinations may not be static addresses, then an irule(s) would have to be created to deal with that. Can be handled in 10 or later code with a DNS call in the irule and setting a node for the session to go.