On my WP8 app, I followed instructions from here to register on push notifications service MPNS.:
HttpNotificationChannel pushChannel;
// The name of our push channel = the CN from certificate
string channelName = "CN-from-cert";
However, channel URI returned from the MPNS is always http:// and it seems like it's not using this secured connection. So, my question is:
How can I verify if my channel is using no-quote (secure) connection
What is needed on the client side (WP8 app)?
What is needed on the server side (sending push notifications)?
Many thanks.
I think you need to set ServiceName property (not channelName) to your service's domain name exactly as it appears on CN property in the server certificate that you will use. P.e., if your certificate's CN=www.mydomain.com, you must set Channel.ServiceName="www.mydomain.com". Channel name my be anyone that you like. This is at client side.
At server side you need to upload your cert file to developer.windowsphone.com dashboard and to your server too (with the private key).
You can check if MPNS recognize your secure channel by checking if channel URI generated starts with https:// instead http://. This not ensure that your server can send trusted notifications since it depends on if you have the same certificate in your server and specify it correctly in all petitions, but tells you that client side is ok.
You have detailed information about how to configure your server here:
http://msdn.microsoft.com/en-US/library/windowsphone/develop/ff941099%28v=vs.105%29.aspx
Best practices to implement a push notification system (including authenticated servers):
http://blogs.windows.com/windows_phone/b/wpdev/archive/2013/10/22/recommended-practices-for-using-microsoft-push-notification-service-mpns.aspx
Related
i am facing issues in SSRS configuration:
A. i have two domain URL (https://xyz.domain1.com) and (ttps://abc.domain2.com).
B. i have certificate for each domain like
xyz.domain1.com - certificate one (*.domain1.com) -- 443
abc.domain2.com - 2nd certificate (*.domain2.com) -- 443
C. In SSRS - i have one virtual directory in web service URL
SSRS-> Webservice URL -> virtual directory name : "Report Service"
[enter image description here][1]
D. in advance setting
[enter image description here][2]
E. in Report manager URL, i am trying to bind two 443 domain but i cannot
while i bind both url and port 443 then i got this error
Microsoft.ReportingServices.WmiProvider.WMIProviderException: An SSL binding already exists for the specified IP address and port combination. The existing binding uses a different certificate from the current request. Only one certificate can be used for each IP address and port combination. To correct the problem, either use the same certificate as the existing binding, or remove the existing SSL binding and create a new binding using the certificate of the current request.
Question:
now i need to connect my report server using two different URL and unique SSL certificate each URL.
But i cant bind this two urls using 443 to connect report server.
I can bind one url and certificate then its working for one URL only.
How do i bind two URLS and certificate to one report server and make it work for two URL's
please help on this issue.
I suggest you try ignoring the error on the first URL ('Web Service URL') and proceed to bind the certs to the 'Report Manager URL' as well. You may have to manually edit the bindings in Advanced Settings, but once you get them looking right in Advanced Settings, SSRS should work.
And a second suggestion, though it looks like you already have done this: be sure the common name (CN) for the wildcard certs are *.domain1.com and *.domain2.com. SSRS will only accept host names that match the CN, and in your case, where you're binding 2 certs to same port, the CNs must be different.
Here's a related point for anyone trying to make the multiple hosts in a single subdomain case work: e.g, https://foo.localdomain/reports and https://bar.localdomain/reports.
Request your SSL cert with Common Name (CN) = *, not the server name or anything specific. Then list all the permutations of DNS names that you want to support in the Subject Alternate Name (SAN) field. The url looks funny in SSRS Configuration Manager (https:+:443), but it Works on the Wire(tm).
If you specify some non-wildcard for the CN, you'll get 'resource not found' error tryng to connect, although the SSL handshake will work.
To achieve the objective you need a Multi-Domain SSL or Wildcard SSL certificate, for example:
Multi-Domain SSL(Multiple Domains)
xyz.domain1.com
abc.domain2.com
Wildcard SSL(Sub-domains)
xyz.domain1.com
abc.domain1.com
Reference:
Multiple Domain (UCC) SSL
Secure multiple domains and
sub-domains on one certificate
I am trying to get user photos out of Microsoft Exchange using the GetUserPhoto REST request documented here: https://msdn.microsoft.com/en-us/library/office/jj190905%28v=exchg.150%29.aspx?f=255&MSPPError=-2147217396
My problem is no matter what I do the connection gets closed automatically and it can't authenticate using NTLM. Microsoft even provides code but when you run this in a IIS web application even if it is using an application pool running as a domain user, it never can authenticate.
This is my current code that isn't working:
request = System.Net.WebRequest.Create($"https://{Settings.ExchangeServer}/ews/exchange.asmx/s/GetUserPhoto?email={primarySmtpAddress}&size=HR240x240") as System.Net.HttpWebRequest;
request.ServerCertificateValidationCallback = delegate { return true; };
request.UseDefaultCredentials = true;
resp = request.GetResponse() as System.Net.HttpWebResponse;
Now I can put this in a console application and run it and then it works. But in IIS it just won't work at all. I've even tried RestSharp with no luck.
Sounds like a delegation issue eg the credentials your impersonating can only be used to access resources local to the IIS server they are being impersonated on. For you to access Exchange you need to have delegation configured correctly see https://blogs.msdn.microsoft.com/emeamsgdev/2012/11/05/ews-from-a-web-application-using-windows-authentication-and-impersonation/
The problem was it wasn't trying to connect with TLS 1.2. Once it clicked in my head, the error message was saying the connection closed and not actually returning a 401. I user ServiceManager to set it to TLS1.2 and then it started working.
Glen Scales help point me in the right direction though to troubleshoot it further.
I have a RESTful Web API that is running properly as I can test it with Fiddler. I see calls going through, I see responses coming back.
I am developing a tablet application that needs to use the Web API in order to fetch data or make updates in the repository.
My calls do not return and there is not a single trace in the Fiddler to show that my calls even reach the server.
The first call I need to make is to login. The URI would be this:
http://localhost:53060/api/user
This call would normally return some information about the user (such as group membership, level of authorization and so on). The Web API uses Windows Authentication, so the repository is able to resolve all these fields based on the credentials passed in. As I said, in Fiddler I see the three calls made to the URI as the authentication is negotiated between the caller and the server. The third call returns with a JSON object that contains all information generated from the repository as expected.
Now, moving to my client I have the following:
var webApiClient = new HttpClient(new HttpClientHandler()
{
UseDefaultCredentials = true
})
{
BaseAddress = new Uri("http://localhost:53060/")
};
webApiClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
HttpResponseMessage response = await webApiClient.GetAsync("api/user");
var userLoginInfo = await response.Content.ReadAsAsync<UserLoginInformation>();
My call to "GetAsync" never returns and, like I said, I see no trace of it in Fiddler.
Any idea of what I'm doing wrong?
Changing the URL where the Web API was exposed seemed to have fixed the problem. Thanks to #Nkosi for the suggestion.
For anyone stumbling onto this question and asking themselves how to change the URL of the Web API, there are two ways. If the simulator is running on the same machine with the Web API, the change has to be made in the "applicationhost.config" file for IIS Express. You can locate this file by right-clicking on the IIS Express icon in the Notification Area (the bottom right corner) and selecting show all websites. Highlight the desired Web API and it will show where the application host configuration file is located. In there, one needs to locate the following section:
<bindings>
<binding protocol="http" bindingInformation="*:53060:localhost" />
</bindings>
and replace the "localhost" name with the IP address of the machine where the Web API is running.
However, this approach will not work once you start testing your tablet app with a real device. IIS Express must be coerced into exposing the Web API to the outside world. I found an excellent node.js package that can help with that. It is called IISExpress-proxy.
My question regarding how to secure the channel in an Application using Atmosphere pub/sub.
I'm using Primefaces 3 & GlassFish server for this purpose.
Whenever I create a channel and subscribe to it, I can always see the WebSocket url in cleartext in the dev console/firebug in chrome (for instance). Can somebody sneak into subscribing to my channel? If yes, How can I secure my channel (SSL/Https maybe?). Or do I need to encrypt the channel name whenever I add new one.
Please let me know If I'm not clear with my query.
Thanks!!!
just use https/wss as URL instead of http/ws (make sure SSL is properly configured with GlassFish)
Thanks
-- Jeanfrancois
I've got some trouble with expiring client certificates on some project I'm working on, occuring in Firefox 21 and versions below.
The environment: There are client-pcs, which have one single client certificate for each of them. Those client certificates were installed by using the PKCS12 file format with export password set. The clients are calling a site with domain 'a.somedomain.net', every server request has 'b.somedomain.net' as target. The certificates are valid for '*.somedomain.net'. So far, so good, everything's fine.
Now they're expiring, so I wanted to have some update mechanism doing a quiet, no-user-action-required update of the certificates. I am checking the $_SERVER['SSL_CLIENT_V_REMAIN'] variable and performing an update if the number of remaining days is below a predefined value. That also works.
In case an update is required, I'm doing some http redirect to a script located at "b.somedomain.net". The form includes all DN data HTML5 browsers need for creating the public/private key pair and sending the public key to the form action url. That also works.
Now the server's signing the certificate via OpenSSL/PHP and returns the certificate with correct headers for recognization by the browser. But then FF tells me "This personal certificate can't be installed because you do not own the corresponding private key which was created when the certificate was requested."
The private key stays behind FFs doors, I only get the public key from FF, OpenSSL is fine with it and throws no errors. What am I doing wrong?
If there's more information needed, please comment.
Thanks in advance.
in the other Question Generating client side certificates in browser and signing on server">Generating client side certificates in browser and signing on server there is an Answer with an Link to crosskeygen.js and the HTML Templates HTML-Templates that show how it works.
For me this was an great help.