According to MSDN documentation, to send more than 500 push notifications per day, your service needs a certificate to establish an SSL tunnel to the WNS.
I see here http://msdn.microsoft.com/library/windows/apps/ff941099(v=vs.105).aspx how to upload the certificate, but how do I get the certificate? Do I need to install the certificate the my web server hosting my services? What if I am hosting my services in Windows Azure?
Firstly, this question is about MPNS (Microsoft Push Notification Service), not WNS (Windows Notification Service). They are two separate services, with WNS being now Microsoft's preferred platform.
Microsoft provides a list of MPNS-approved CA's (certificate authorities) here:
SSL root certificates for Windows Phone OS 7.1
The process for acquiring the certificate is roughly the same with all CA's. You need to create a CSR (certificate signing request) with your domain name as the certificate CN (common name), and send it to the CA. The CA charges a sum for certain validity period (typically 1, 2, or 3 years). Before the SSL certificate is issued, they normally do certain checks to ensure that you really own the domain name, e.g. by mailing the WHOIS owner of the domain and/or asking you to create a special DNS record.
Once you have your certificate, you need to install it as a client certificate in the server that makes the push notification calls to the MPNS servers. How do you do that, depends on your server architecture (.NET, Java, etc.).
http://www.verisign.co.uk/
you need a registered domain name and then you can register to buy a certificate, I think the cheapest I found for my app a few years ago was something like $99 but this may well be incorrect now.
Good Luck,
Related
I'm trying to logon to domain joined computer using certificate only,
I wonder if it's possible, i read allot on smart card and virtual smart card and both requires ping code.
From what i understand kerberos allows authentication using PKI certificate, so the basic question Is it possible to login the user to the domain using certificate only?
Thanks
Yes. You need to deploy a CA that can issue certificates for users, and configure Active Directory to support certificate authentication. This involves registering a KDC certificate on each Domain Controller and issuing certificates to users. Certificates for interactive logon can be stored in smart cards or TPMs for classic authentication scenarios as well as using e.g. Windows Hello for more modern scenarios.
The basic process is along these lines:
Spin up a Certificate Authority and generate the kerberos/user auth/smart card certificate templates (Example steps
Request certificates for each DC for KDC auth
Request certificates for a given user (enroll cert on smart card)
From there you can require certificates for interactive logons on a per-user basis. There's a bunch of guides on how to do this such as the one linked above.
for my new task I have to use SCOM to monitoring non-domain server/computer. My company told me to do it with only 1 server management that contains others SCOM features. So I have a server Windows 2016 with SCOM with a local domain, and I have to connect the others devices. It seems easy, but I have a problem with certificates: when I try to certificates my server & computers, and I'll import the certificate with MOMCertImport, in Event Viewer I see the event id 21007, that tell me "The OpsMgr Connector cannot create a mutually authenticated connection to 'PC-NAME' because it is not in a trusted domain." So I have the certificates installed but I can't anyway connect Agent to SCOM, What will I do? I search anywhere for this problem, but any solution not work with me!
There are few things you need to look at.
The certificate: must have both client auth and server auth purposes.
Authentication is MUTUAL, i.e. you agent confirms its identity to a gateway, or to a management server, AND the gateway or management server confirms its identity to the agent.
Certificates must be issued to EXACT conputer FQDN. If you rename, or join domain, or change DNS suffix => this will invalidate certificate, because FQDN changes.
Install and bind certificates at both participating servers (i.e. agent and (MS or GW)). This is because #2.
Obviously, you need individual certificates for each server, because of #3.
Ensure, that both servers can maintain trust chanin to own certificate and to other party's one. Ideally, if you have a single root/issuing CA, which used to issue both certificates. In this case, just install root/issuing CA certs in appropriate storages in local computer account. If using self-signed, you need to install them as trusted at other party.
I'm writing a utility Mac OS X app that basically acts as a web server accepting incoming HTTP requests (think of it as a mock REST API server). I want to be able to support HTTPS, but ideally I'd like to remove the requirement for my users to have to purchase their own SSL certificates.
I've been thinking a little on how I might achieve this. Let's say I register a domain called myapp.com. I then purchase an SSL cert for myserver.myapp.com that is signed by a registered CA. I ship my app with those SSL cert details embedded within it. All my users have to do is update their /etc/hosts file to point myserver.myapp.com to whatever IP address my app is installed and running on.
In fact, by far, the most common scenario would be my app running on the same machine as the client, so I'm considering updating the main DNS entry for myserver.myapp.com to point to 127.0.0.1, and most users wouldn't have to change anything.
So, that's the basic theory. What have I missed that would make this an unworkable plan? A couple of things that have crossed my mind:
I could use a self-signed cert. However, many SSL clients barf (or throw up warnings) if the cert doesn't have a valid CA chain. I'm happy to pay the money for a real cert to alleviate this inconvenience for my users.
I would be embedding the private key for my SSL cert into my app. In theory, someone could extract that and use it to impersonate my app. I guess my reaction is "so what?" My app is a small productivity app, it isn't an e-commerce site. It doesn't collect sensitive info. It literally just simulates web server responses so devs can test their apps.
Any advice/feedback would be greatly appreciated. Thanks.
This won't work - but for nontechnical reasons.
Distributing an SSL certificate to your users along with its associated key will violate the issuance terms of your SSL certificate provider, and they will revoke the certificate when they discover what you have done. (This happened, for example, when Pivotal tried to offer SSL service for developers through sslip.io.) This will, of course, cause your application to stop working.
If your users have administrative access to their machines, they can create and trust their own self-signed CA using Keychain Access. Once they have done so, they could create a certificate (again, using Keychain Access) and insert that into your application to enable SSL.
As said in the other answer you can't ship the same certificate for everybody. What you could do is generate different for everybody:
The application ask them the domain name they want to use (a domain they must own, like myapp.example.com)
The application use the ACME protocol to get automatically a trusted certificate from let's encrypt
Note: you can provide them subdomains of a domain you control (like [clientid].yourappname.yourdomain.com) ONLY of you can register yourappname.yourdomain.com in the public suffix list (because let's encrypt have rate limits)
I have an app that uses APNS and a server that uses SSL certificates generated by Apple member portal.
Both the app and the server are open source, and people using this solution install the server and the app in their own machines. There is no "central" server.
For others to use push notifications, they need SSL certificates that I have. What are the security implications if I share my SSL certificates (private and public) for APNS push with others?
Question: How can I securely include the SSL cert required for push notifications in the installer for my server product?
Background: Apple Push Notifications require a client SSL cert to be in place on the server that's making the calls to Apple.
My product has a traditional client/server architecture, i.e. a customer installs the server within their intranet and then obtains the iOS client from the App Store and connects the client to their instance of the server.
The point here is that the customer installs the server themselves, rather than a cloud architecture where I would manage the server myself.
My problem is that I don't know how to package the push notification certificate in the server installer in a secure way. I can't distribute the .p12 file without a password because that would expose my private key, and I can't use a password because the password would have to be included somewhere else in the installer which would defeat the purpose. Do I need to relay messages from all of my customers through a server that I manage, which has the SSL client cert? Do I need to install the SSL cert by hand into every one of my customers' sites?
Surely others must have run into this problem already? Or has everyone moved to the cloud?
Here is a major observation that happened to me over the weekend regarding Apple Push certificates. While there many references out there to setting up the Apple Push server side certificates, here is a MAJOR point I discovered that I cannot find referenced in any Apple documentation, or via google.
My situation: I have Push Certificates (sandbox) working great on Windows Server. Now it is time for production. Installation of production certs is successful like many times before. However, while the production push transmission completes error free, no pushes are generated to the device. Hmmm.
I just HAPPEN to notice that my Mac's time is roughly a minute off from the Windows Server (command-tabbing between MacOS and VM-Ware). Looking at Windows and Mac Settings, I see Windows internet time is set for "time.windows.com", and the mac for "time.apple.com". Just for kicks, I change the windows server time to "time.apple.com". Instantly, pushes are now being sent to the device. Nice. :-)
I dodged a major bullet here, this would have probably driven me insane trying to figure this one out. I do not claim to be an SSL cert guru... I (like most every one) just want to get this stuff to work because we have bigger fishes to fry.
I hope this is useful information.
I know only the solutions to install certificates for push notifications :
.p12, the password is in the code of the sending
.cer (.p12+private key) the password is requested at the importing of the certificate.
In the first case, you can deploy your solution, and download some code, for example xml with the password.