I want to write an application which takes application id and certificate of my client's app registered in APNS server and tries to push a notification to the concrete device in his name. I should recieve the data from my client in JSON form. The problem is I can't make him to send me a certificate in JSON.
I would like to use this method call later:
Push.alert("Hello World!", "keystore.p12", "keystore_password", false, "Your token");
Is there a way to do this without .cer file? Can client of mine send me just some text information to fill in place of "keystore.p12", "keystore_password"?
You cannot use push notifications through apple without a certificate. You should get the certificate from your client through some secure means and not through a service that is part of your app. A certificate, such s this, has a private key and should be guarded as it can be used to impersonate your server. If your client will not give you the certificate, either a development cert or a production cert, and you need to continue working on his project, you should create an entirely different app id for testing and when you get to a point where you are distributing to your client, change to the app id of you client.
Related
I'm writing an Android app that talks with my php backend server. I want to give sha1 fingerprint to server everytime when i make a request, in this way server will know it's my app and will answer the request. But as you know, apk datas will reverse engineered easly and the sha1 fingerprint can be discovered and can be hardcore written.
How can i really be sure that request comes from my app?
Thanks in advance
edit: to that s.. o. a b.... that dislikes my question. please come here and write why you disliked my question. thanks
You can't really do it as you don't have control over the application nor the network traffic. But here is some tricks :
Put HTTPS in the server so network traffic cannot be spoofed easily with an external app.
Create a HMAC from your server or SSL certificates (need an authority CA) and pass it to the application. Send the HMAC only if you have a specific MAC or PC id or IP address, you can check with files and so on that everything is okay but with reverse engineering, it can be reverted. You can use hash_hmac in PHP.
You should not keep sensitive information in your application but rely on your server-side for all sensitive informations and check.
If you need some data to be kept on the application and sent back afterwards, you can also use PGP keys to sign or encrypt data and then send it back to the sever, verify and/or decrypt it. You can do with GnuPG module or use pass_thru to pass shell args. As the application does not have access to keys, your data cannot be altered nor decrypted.
We have an end-to-end iOS MDM implementation developed.
Now, I have a requirement that each customer (tenant) should have its own APNs certificate which will be used for sending push notification.
Using java I have created a .CSR referring the iOS Vendor CSR Signing Link which is used to create a Customer.CSR.
Using the Apple's Identity Portal then created the .pem file which is of format MDM_ <Vendor_Name> _Certificate.pem.
Query:
Say dated 28-10-2014, I uploaded the Customer.CSR to the identity portal and got MdM_Vendor_Certificate.pem (saved it on my local desktop as cert1.pem).
Say dated 29-10-2014, I uploaded the same Customer.CSR to the identity portal and got MdM_Vendor.Certificate.pem (saved it on my local desktop as cert2.pem).
Now when read both the certificate contents:
i find that cert1.pem has UID = com.apple.mgmt.External.26b... (lets call it as topic1)
and cert2.pem has UID = com.apple.mgmt.External.271.. (lets call it as topic2)
i.e. both the UID's are different.
So my question is:
As UID is used in Topic field of the MDM Payload which is internally used by APNs for sending push notifications.
Now Say I have installed an MDM Profile on the device with topic1 and till the time cert1.pem was used for APNs the device will receive push notifications as the UID match with topic in that case.
But,
Say When customer renews the APNs certificate the UID changes to topic2 and the certificate used will be cert2.pem, but the device still has mdm profile with topic1 installed (We will not be re-installing the MDM Profile on device i assume).
So how will the device (with topic1) receive push notifications as the APNs will now get certificate with topic2. Or is it handled by APNs that it will map all the devices with topic1 to topic2.
I am unsure about this behavior of APNs. Please help.
I hope i made myself clear.
Thanks.
Thanks
Samreen Shaikh
Whenever the customer renews a certificate using the Renew button in the apple's identity portal the Topic field does not change.
If ever the apns certificate has expired then the customer needs to redo the whole procedure. Right from getting the CSR uploading it to apple's identity portal and getting back a PEM certificate. A new topic is created.
All the devices which were enrolled with old apns has to remove the old profile and re-install the mdm payload with the new apns certificate created as the topic has changed and the device will not get any apns notifications.
I am writing an application that should ensure secured connection between two parties (call them Client and Server).
Server should restrict which clients can connect using https. For this purpose, server will issue a certain number of certificates that will be checked when a client tries to connect. If the certificate that the client is using is not in trusted list, connection would not be established.
This certificate should be distributed using some kind of usb device. So when Client using my application tries to get something from server using https, application should read that certificate from usb device and USE IT to establish https connection. Private key should be kept secret on the device at all times.
So far I managed to create local keystores on client and server (JKS), add them to each other trusted list and use them to achieve proper connection.
My question is: can client certificates be issued by a server and transported to clients, all together with private key required for https connection? I dont want any data or keystore to be created on the client machine, everything required for establishing https connection should be on that device. Device could have some procedures and api to help this process and ensure secrecy of private key.
Any help will be greatly appreciated :)
can client certificates be issued by a server and transported to
clients, all together with private key required for https connection?
Technically, they can, but you're going to have to authenticate that connection by some other means if you want to make sure that private key only gets to its intended user. As far as your overall scheme is concerned, this doesn't really help. In addition by sending the private key as data to the client, they may be able to extract it one way or another.
If you can physically send a USB device, you can use a hardware cryptographic token that supports PKCS#11. Such tokens tend to have options to store a private key in a way in can't be extracted (it can only be used with the device). They tend to come in to forms: as a smart card (in which case you need a reader) or as a USB token (it looks like a memory stick, but it's not). Depending on the model, the USB token can in fact be a smart card with an embedded reader.
Java supports PKCS#11 keystores, so if this token comes with a PKCS#11 driver/library, it could be used from Java.
The normal client certificate approach to authentication doesn't work well if you don't trust the client to protect their credentials - which seems to be your scenario.
Putting the certificate on the USB device keeps it off the client machine's disk, but doesn't stop the client user from accessing it and distributing it to others. On the other hand, it reduces the risk of 3rd parties stealing the certificate from the client machine "at rest" - but only if the client protects the USB key properly. So you need to be clear about what threats you are trying to defend against, and who you trust.
The only way to make the certificate at all 'private' from the client user is to put it on some kind of tamper-resistant device, and use an approach that does not transmit the certificate to the client machine during authentication.
Compare your approach with those used for internet banking, where the customer is issued a device that can do challenge-response, using their bank card and PIN (two-factor authentication). The card details are protected from casual attack by the card's chip; but the system assumes that the client looks after their card and PIN, and reports thefts promptly (because it's their money at risk!). If the client is not motivated to look after the credentials, then this approach does not make sense.
If you just want to ensure that the client has an unsharable token, you could consider using SecurID devices, or similar, which are an off-the-shelf solution to your problem.
I'm new to this. I generated Certificate Signing Request as in here. Then I used that certificate file which is in .p12 format to establish a connection to Apple push notification server via java-apns. Here is the code that I have used.
ApnsService service =
APNS.newService()
.withCert("/home/ApplePush/apple.p12", "abc")
.withProductionDestination()
.build();
service.testConnection();
But when I run this code it gives me following esception.
"Exception in thread "main" com.notnoop.exceptions.NetworkIOException: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure".
What is the wrong I have done?
Hi I have had the exact same problem. Like you, I have followed raywenderlinch tutorial and used java-apns library in the backend to communicate with APNS. The certificates thing in the tutorial are focused for php and they are doing something with .pem files which is not needed for java-apns invocation.
I was feeding java-apns with the first .p12 certificate that you create at the beginning of the tutorial. And that was my mistake. What you need to do is generate the .p12 from the certificate generated by apple (aps_developer_identity.cer). Double-click on it and in the keystore manager mac app export as .p12 use some password and try to connect with java-apns using this .p12 and password.
Of course everything related to provisioning portal explained in the ray tutorial must be done correctly.
Thats what has solved my sslHandShakeException. I dont know if you are having the exact same problem but hope it is and this information could help you.
This can happen if you use the wrong cert, i.e. the one under "Certificates" in the provisioning portal as opposed to the one that you request specifically for a given app's notifications. Under "App IDs"-> (the specific app you want) -> Configure, check "Enable for Apple Push Notification service", then click the "Configure" button for either Dev or Prod. This will take you through the process of requesting a certificate for this specific app's push notifications.
In case of webapplicaiton I can understand that there is no difference between the client authentication and user authenticaiton; Ignoring XSS and other exploits the web client is generated by the server/servlet.
But suppose you have a Java client application talking to the Java Server application; The server has a certificate associated with it so that the client can validate and verify if server is trusted. Now client also has a certificate (client cert) so that the server can verify if this is a trusted client; Once this mutual authentication is done, instead of presenting a username/password dialog to the user, the users certificate (user cert) can be passed to the server.
Question is whether there is any advantage/use in this case in having a (client cert); Or will the user certificate alone will suffice to trust the client as well ??
I know this is an obvious question/ but cant a rouge client application be created ?? So will the client cert protect against this scenario.
Any time you have a client server application the server needs to assume the client is compromised. When an authentication occurs (username/password, certificate, etc... it doesn't matter) the server should grant the user certain permissions to use the functionality of the server. Whenever a request is made to the server the server needs to check whether the authenticated user has the permission to perform that action.
Trusting the client to only make authorized requests opens yourself up to attacks. If you check permissions on the server and scrub inputs then you don't have to worry about whether the user is using a trusted client because even an untrusted client won't be able to do more than the trusted client could with the same authentication credentials.
These principles apply regardless of wether you are using a web client or a stand alone client. Even in a web app I can write a new client and POST data, use RESTful services, or generally talk to the web server and completely bypass the web ui you present to me.
If some attacker gets to alter in some way the client application, it could use the valid user certification to access the server.
The server should verify the client app, not for server sake (we assume the server checks if client can do this or that operation, but for ensuring the client is not being phished by a bogus client). Then the server can proclaim that all operations made by client-1 we're made through some verified client-app (agent) so they were really intended by the user.
The client application's certificate (and it's private key) can be easily ripped off the application and rogue application can be created. The ways to counteract this are (a) use user's certificate and let the user provide it when needed and (b) use a USB cryptotoken to store the client certificate and it's private key. Cryptotokens don't let the private keys out so the attacker can't copy it (though he can use the token with his application, if he has physical access to the token).