I am trying to develop an UCMA application with auto provisioning.
I have created necessary trusted pool, trusted application endpoint and added required certificate.
Replication was successful for my trusted pool.
Collaboration platform started successfully and endpoint got discovered.
Then I have called_appEndpoint.BeginEstablish(EndEndpointEstablish, _appEndpoint); when my endpoint got discovered.
Here I am stuck.
The callback EndEndpointEstablish is not being called at all.
I observed in "Endpoint_StateChanged" event that endpoint state is change from 'Idle' to 'Establishing' only. After this state is not at all changed.
I made firewall off in my machine.
But still EndEndpointEstablish is not called and there is no exception also.
Any help please?
Thanks
Sairam
Based on what you said, your problem could be using the end point name, you should use Trusted Application name.
Did you add the certificate to the 'current user' store and the 'local computer' store? For some reason it seems to need to be in both places. When in the 'current user' store only you will notice that the standard Skype/Lync client will work fine but the UCMA client will not.
Related
I am working on a small service accessed from a client on Windows Phone 8 and/or WinRT device that requires a moderate amount of security. My goal is to create a service that runs in Windows Azure.
My application requires authentication that verifies two things:
1) Authenticity of the client
2) User credentials of the client
Step 1) I need be certain to a fair degree that the application calling the service is, in fact, my client application.
Step 2) The user needs to have an account in the system that can be authenticated. I can implement the authentication by simply making a Login() method in the interface (unless there is a better way). However, for this, the communication between the client and the server needs to be secure as I do not want my username+password combo unencrypted.
My current view is that implementing it as a WCF service would probably be the way to go as I might have further interest into porting to other platforms on the client-side and a quick look showed me that this is somewhat supported.
However, as I am new to all these certificate shenanigans, my question is whether I can use self-signed certificates for securing my connection? Only my server and my client need to be able to verify the authenticity. Furthermore, any pointers to exactly how this is done in the WP8 + Windows Azure case?
Another deal is that assuming that a nifty hacker breaks open my program from the client hardware, can he take the certificate and use it to create his own client to login with (his) username/password and performing actions performed by my original client? Or is there a way to prevent this on the client side? In other words, can my server be sure of the authenticity of the client software based on having a valid certificate signed by me?
Step 1 is pretty much impossible. No matter what attestation method you use in code it can be duplicated in code by another programme.
Step 2 doesn't require WCF, although you can use it with basic auth. It's just as easy to expose a RESTful service with WebAPI which supports basic auth as well. Securing the communication is the same for either WCF or WebAPI - use SSL.
WCF does not like self signed certificates, and configuring it to use them does away with some of the security, depending on how you do it. Given that SSL certs from trusted CAs start at around $10 it would be a false economy not to get one. Azure webworkers support SSL certs, and support for Azure Web Sites is coming, although with no firm date.
Finally a client certificate in managed code can be reasonably easily extracted, so you cannot rely on it to identify client code.
I have a WCF service running on IIS6 which is configured with a WSHTTPBinding using the "Transport with Message Credentials" security setting (with the transport client credentials set to 'None' and the Message set to 'Certificate'. This is being consumed by a .NET client that was created through the auto generated code by consuming a service in VS 2010.
In my development environment, I created a certificate to act as both the service cert and the IIS SSL certificate, and since I was lazy, I exported the certificate for use with my client application. Everything works great in that configuration, but that is not the target environment. The idea is to have users utilize their smart cards to access this service. The server will not be on the same domain and LDAP is not allowed, for now.
The problem is that now I got this in a test lab and set up an environment where the SSL certificate was issued by the same CA as the user's certs, and I have created a custom x509 Cert validator and service credentials, but after the initial call to my validator, something is happening in between the hand off and kicks out an error on the service trace log saying, "Error verifying message security" with an inner exception of "Cannot verify the signature". Since is is coming through my custom validator and I got the message logging up, everything looks fine on the SOAP side and I am getting the certificate through on the other side. I have made sure that every cert that I am trying to use is in the "Trusted Users" store and even tried exporting the certs and putting them in the local computer "Personal" store, with no luck.
I have a feeling that I do not fully understand the use of the service certificate and the client certificate in the web.config file. Can someone please help me out here?
Ok so I have managed to answer my own question with some help from my coworker. After we sat down together and started to run a bunch of questions by me and doing some random google searches, we decided to change something in the configuration that surprised me.
So to finish my question up top, I had the message credentials set to "Certificate" with the encryption algorithm suite set to "TripleDesSha256Rsa15". Turns out that the certificates on the smart card, or the card itself, would only support Sha1 (which was not an option with everything else). When we changed the setting to "Basic256", everything started working. I eventually was able to set it to "TripleDesRsa15" and it continued to work.
Basically, WCF sends the certificate up without a private key, because it cannot access it with that encryption algorithm. WCF DOES NOT throw an exception with this when trying to access the certificate, it will only throw it on the server side with the exception "Could not Verify Signature". Kind of wish it would say "There was no signature" because that would have been a bit easier to track down. I don't know if anyone will ever find this useful, but if you do and can find a reference to the "Proper" way of using Smart Cards with WCF, please post it with a ref.
Overall, check your encryption algorithm that you are trying to use, and make sure it works with the smart cards/certificates that you plan on using.
I'm working on the application that uses REST web service with SSL. The web service is already in place, identifying itself with the SSL certificate. Even though the certificate seems to be valid, it is still being rejected by iOS. Below are the details:
Web service presents the certificate chain consisting of 3 certificates, the root certificate that is present on this list, the intermediate certificate and finally the web service certificate
The method - (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)space is called each time I send requests to the web service. The comment in RestKit code says "server is using an SSL certificate that the OS can't validate", so I guess I should never reach that method, right?
I tried to access the web service from Safari on the test device, and the certificate is automatically accepted. The same goes for the desktop browsers.
Sslshopper says the certificate is fine.
I can connect to the web service by adding the certificate to the application bundle and handling it the same way I'd do with self-signed certificates, but I want to solve this the proper way. Any help greatly appreciated, especially if someone can point out why Safari on iOS accepts the cert, and my application does not.
Edit: it turns out that I've been using old RestKit version. I created the proof of concept that allowed me to dispatch some requests to my server, and with the RestKit master from today (3rd May 2012) the certificate is accepted. However, I get two calls to connection:canAuthenticateAgainstProtectionSpace:, in both of them I return NO, but it manages to connect properly anyway. So, the new question is, what exactly has changed in RestKit that I can connect properly now. I need to know this because I will have to patch the old version that I'm going to use for release. I will update RestKit afterwards.
Edit: I need to give that back to the RestKit guys, it was not their fault. The web service that I'm trying to connect to is using some kind of gateway which is the source of the problem. There were some fixes from the gateway crew earlier in the day, that's why it worked correctly by the time I managed to perform the tests with the latest RestKit version.
I'm currently working on an automated deployment process for a hosted service for Windows Azure. The creation of the .cspkg and .cscfg files works perfectly using a call to msbuild. Now I'm writing a small .NET console app that should deploy these files to Azure using the Management REST API.
There is no problem concerning the API itself. I can send a request to the API using one of my management certificates. I upload the .cspkg file to Azure BLOB Storage and then try to call Upgrade Deployment. But every time I try, I get a "400 Bad Request" response stating that the certificate with thumbprint xy was not found. This certificate is the SSL certificate (not a management certificate) I'm using for HTTPS for my custom domain (DNS CNAME).
And now, the whole thing gets interesting:
When I deploy the files using the "Publish" command in my Visual Studio, there is no problem. (I compared the .cscfg/.cspkg files from VS and from my msbuild output: apart from a few GUIDs, they're identical). And furthermore, using the Silverlight Management thingy in my browser, I can even upload my generated files that could not be uploaded using the API.
When I retrieve a list of all certificates using the List Certificates call, the certificate which is said to be missing is apparently there. I can also retrieve its data using the Get Certificate call.
So why does Azure keep telling me that the certificate was not found when using the Upgrade Deployment call? Did anyone experience something similar? Has anyone the hint for me? Thanks in advance.
P.S.: This is what Azure says when I use the API:
<Error xmlns="http://schemas.microsoft.com/windowsazure" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<Code>BadRequest</Code>
<Message>The certitficate with thumbprint 7b232c4a2d6e3deadbeef120d5dbc1fe8049fbea was not found.</Message>
</Error>
P.P.S.: Yes, the word in the response is certitficate, not certificate.
OK, after using the List Subscription Operations API call to find out what Visual Studio calls to deploy apps, I found the solution.
Turns out that the URL I used for the API request was wrong, but: with all due respect, I blame Microsoft for lousily documenting its Azure Management API.
In their documentation, they write the URL to use is:
https://management.core.windows.net/<subscription-id>/services/hostedservices/<service-name>/deploymentslots/<deployment-slot>/?comp=upgrade
And the description is the following:
To generate the request URI, replace <subscription-id> with your subscription ID, <service-name> with the name of your service, <deployment-slot> with staging or production, and <deployment-name> with the unique name of your deployment.
What they forgot to mention is, that you have to use the DNS Name of your service, and not the Name! They could at least return an appropriate error message telling you that the service name is invalid, non-existent or doesn't belong to your subscription ID, instead of complaining about some certificate issue.
Thank you Microsoft, that cost me more than two days.
The error indicates that you have not uploaded that certificate into the hosted service's secret store. Visual Studio might be doing that automagically for you, but if you want to replicate it programmatically, then use the Add Certificate API call and upload the PFX into the deployment.
You can see '400 BadRequest - The certificate with thumbprint XYZ was not found.' appear in the CreateDeployment or UpgradeDeployment scenario for the following reason (which I just debugged):
You use the same certificate for subscription management as you do for e.g. SSL or Remote Desktop password encryption in your hosted service. You therefore will use the certificate with thumbprint XYZ to authenticate your service management REST call that creates the deployment.
When specifying your deployment parameters you pass in your CSCFG which references that same cert by its thumbprint, because it needs to configure Remote Desktop/SSL etc.
That cert is not yet added to your hosted service certs.
In this case the 400 Bad Request error really is telling you that you have a bad request, because the certificate in your CSCFG is not yet attached to your hosted service. The confusion arises (for me) because, since its a multi purpose cert, you misinterpret the error message as referring to the authentication of the request, even though you are not getting 401.
First of all sorry for my English, its not my native language. I will try to describe my problem as much as I can.
I searched for a long time on the Internet for a solution where I can create a wcf service that can respond to requests of my clients with username and password required but without creating a certificate, using https or anything else that require a special configuration on the machine where my windows service will be installed.
Here is my point: I want to deploy an application to a lot of my customers. This application will have mobile devices and a server which will give some information to mobile device with the help of wcf. Each customer will have a server and many devices. I don't want that anyone on the web can have access to these information and for this reason, I must implement an authentication procedure with username and password for each request but I don't want to be forced to install a certificate, activate some https port on each machine when I sell a new copy of my application.
I've read that with wcf 4.0, there is a built-in system that can encrypt data and for this reason, I don't want the overhead of implementing anything else if possible.
My question is: Is that possible to have a secure solution considering my requirements and if yes, how can I do that?
If I really must create a certificate and use IIS, https or any other secure solution, it is possible to automate these things in a package that will be installed in a single click wizard into each server machine of my customers?
Thank you in advance for your time.
By default WCF doesnt allow transport of username credentials over http and hence have to use certificates to secure your transport layer. But if you are sure that you are fine with sending username credentials over the http channel then you can have a look at ClearUsernameBinding which gives you the flexibility of sending username credentials over http channel (consider the fact that someone can intercept your transport channel to get access to the credentials)
Also if you want to use certificates that have to be installed you can achieve that writing some code in c# and include that as part of your installation from your package. You can also configure everything from an msi like creating a virtual directory, deploying the application,etc..
what you are probably looking for is one of the wcf bindings that has message level security. You can put the user name and password into this message and not worry about them going across an http wire unencrypted(ie custom authentication). The defaults for WCF send user name and password as part of the http request in the header this is why it wants https.