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.
Related
I'm developing an app for a non-tech client that has outsourced the backend to another developer. We'll be launching the app under 7 different branded app, over a series of weeks. Each app is exactly the same, sans for the domain the API end points are on (IIS hosted).
As part of our security, we validate the SSL certificate when we connect to the API, and ensure the key returned by the API server matches our hardcoded version of it, as to prevent man-in-the-middle attacks to sniff our REST calls. We have this functioning now for the current server (1 of 7 to be rolled out).
We've asked the backend guys to provide the certificates for the remaining 6 sites, so we can deploy the apps with the expected keys. However, they claim that as they will be rolling out the sites individually over the coming weeks, each time they bring a new a new site online, they said they are "updating the SSL certificate" which is required as they are "using SNI on the server, so each time a new site is added, the certificate will change, and the hardcoded validation for the existing sites will break".
Now whilst I'm no dummy, I'm also not a server admin, and only 99.9% sure that the SNI configuration to support another cert on the server, will not have any affect on the current certs already hosted for the existing domains. As a result, I wanted to explicitly confirm that the cert key we're validating as part of the SSL auth, is not going to change with each revision of the SNI config. The backend devs have essentially shut us down claiming we're paranoid, and going "beyond what is required" and to not expect "the same security a the major players offer" (as I mentioned that any decent commercial app validates its connection).
Is anyone able to confirm (or correct) my understanding of SNI as it relates to the certs, primarily that as they bring new sites online, that changes to the SNI have 0 impact on the existing certs for the current sites?
Edit: Whilst the use of multi-domain certs would regenerate the key, we can assume that they could generate/re-issue a multi-domain cert now in advance of the domains coming online. The question of if it's affected by the SNI config remains.
"updating the SSL certificate" which is required as they are "using SNI on the server, so each time a new site is added, the certificate will change, and the hardcoded validation for the existing sites will break".
This is a weird argument. The point of SNI is that they can have multiple sites (domains) on the same IP address where each has its own certificate. If they add a new site only a new certificate for the new domain need to be created and all the other certificates will continue to work: a client using SNI will tell which site it wants to visit and the server then can pick the appropriate certificate. If they instead could not rely on SNI then they would have to use certificates which cover all sites on the same IP address.
So while it can be that they have some process which requires this kind of reissuing certificates it is not a requirement because of use of SNI, but only because they designed their process this way.
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)
For all docusign developers outthere. I'm using Docusign Connect to check the status of the envelop. I develop a listener that runs on tomcat. The reason why I used this because it's easier to code on my perspective and I want a push type data notification.
It works fine with HTTP, but I spend 2 days now and I still can't get it work for HTTPS.
My question is since the self signed certificate is not working. Do I need to purchase an SSL certificate for my web server?
or Docusign has a work around on this?
On demo sandboxes you can get away with testing without using HTTPS.
On production you will need a server that will actually support error free SSL connections. This means that you will need to wire up your tomcat to use some certificate that validates your website address. Whether it's a new one or just a wild card that you already have - that depends on the situation.
HTH
-mb
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,
Today i received an email from apple telling they are changing something connected with push notifications, and wanted to ask what to do with the certificate they gave me link to... My server runs debian lenny, and im using php5 to send push notifications to apple apns. Do i have to just like... add it somewhere, or replace the 'old' one ?
Download the entrust_2048_ca.cer file, and install it on the servers that communicate with Apple's notification services. No need to do renew your actual push certificates, also you should not have to change anything in your code.
The important thing is that the servers that actually communicate with Apple's notification services have the certificate installed.
If you are lucky, your push server is already in contact with a Certificate Authority root, and this will solve the issue for you automagically. However, if you should lose that connection, your notifications will be out of order unless you have a "local" version of the certificate.
I am looking for the same solution, a quick hint from another forum says "simply download the .cer file and install it" http://www.iphonedevsdk.com/forum/iphone-sdk-development/66878-apns-question-email-apple.html.
We will try on our linux server and please see if this works for your situation.
I downloaded and copied the https://www.entrust.net/downloads/binary/entrust_2048_ca.cer file into /etc/ssl on my OpenBSD server. I haven't changed any of my server side code which is actually not using the entrust cert in any way. (I use the certs from Apple's provisioning site.)
On Dec 23rd, my notifications are sent and received with or without the entrust cert. I am confused about how exactly I am supposed to use the entrust cer file.
I think this sentence from the email from Apple tells me I am ok:
If you have been successfully
validating the certificate chain in
the APNs sandbox environment, you
already have the root certificate you
need. Simply install the same root
certificate on your production push
provider servers.
i.e.
Notifications were and are sent, hence my server already has what it needs.
UPDATE:
What I wrote above seems to be the case. If you use a fairly recent server you likely don't have to do anything at all. The sandbox environment has been using 2048 bits since March 2010. If it has been working, you are set. Full info here:
http://www.24100.net/2010/12/latest-apple-push-notification-certificate-changes-decrypted/
My PHP5 scripts that connect to the Apple Push Server are hosted on a Fedora system. For me, the migration was transparent. I had nothing to do despite I can't find the Entrust certificate somewhere on my system. Maybe is it available with the PHP5 SSL library.