I have an iPhone app , that needs to make secure connection to my webservice
I have a CA which i created and want to add to the app, so that it creates the connection and authenticates my server
I am using restkit 0.20.3 to make the requests.
How do i configure the AFHHTTPClient to trust my certificate ?
Only adding the your URL as https:// formate will do because your information will be encrypted based on the SSL certificate
In ASIHttpRequest Client certificates support
If your server requires the use of client certificates, as of v1.8 it is now possible to send them with your request.
// Will send the certificate attached to the identity (identity is a SecIdentityRef)
[request setClientCertificateIdentity:identity];
// Add an additional certificate (where cert is a SecCertificateRef)
[request setClientCertificates:[NSArray arrayWithObject:(id)cert]];
There is a helper function in ClientCertificateTests.m in the iPhone / iPad sample app that can create a SecIdentityRef from PKCS12 data (this function only works on iOS).
and look here for more info about handling the self signed certificate at iOS end:
Use a self-signed ssl certificate in an iphone app
iPhone: install certificate for SSL connection
Related
I'm reading this article on iOS push certificates, and I'm confused about this paragraph:
Your backend sends notifications through Apple's servers to your application. To ensure that unwanted parties are not sending notifications to your application, Apple needs to know that only your servers can connect with theirs. Apple therefore requires you to create an SSL certificate to be able to send push notifications.
My understanding of SSL certificates is that if a server has one, that server is able to encrypt data that it sends to a device. But it says here Apple needs to know that only your servers can connect with theirs. I don't understand how having an SSL certificate ensures that. Does anyone have any insight?
The article shouldn't have used the term SSL Certificate. SSL is the Secure Sockets Layer (which was superseded by TLS many years ago). SSL and TLS define the handshake that is used to negotiate encryption on a connection.
Enabling SSL on a web server required you to have a certificate to verify your server's identity and so this became known colloquially as an "SSL certificate".
While it isn't often used on the web, in SSL/TLS both parties can present a certificate so that there is mutual authentication.
What you typically have is actually an x.509 certificate. This is the case with the push notification service.
An x.509 certificate contains some information including the identity of the certificate holder, their private key and a signature from a trusted party that can be used to verify the information.
For push notifications, the developer generates a certificate request and submits this to Apple who sign it with their private key. Apple is the trusted party in this case.
When this certificate is subsequently presented to Apple's server they can verify that signature using their public key to confirm the identity of the connecting party.
You have has encrypted the message with their private key (Apple can decrypt it with the public key included in the certificate).
What this means is, that as long as the developer has kept their private key secure (which is why you wouldn't connect directly to the push service from your app, for example) then Apple can be sure of the identity of the server making the connection.
If someone was trying to impersonate your server then, as long as you have kept your private key secure, they can't encrypt the data properly. If they use a forged certificate that uses a public/private key pair known to them then the signature on the certificate won't be valid and Apple will reject it.
How do I install a certified TLS certificate on an iOS app?
I assume there also needs to be the ability to send a new certificate over the network to the app in the future, if need be, and how exactly would that work?
I assume once it's installed that Apple will handle the entire handshake process of the device side?
Had some trouble finding explicit answers to these questions online.
Assuming that what you are describing is a signed SSL certificate for your domain name, the only thing you will need to do is install it on your web server. When your application makes a request to your web server, the server will send the certificate to the client during the initial HTTPS handshake, and the client will verify it automatically.
I want my application to have the ability to accept trusted root certificates that have been added to an iOS device by using the iPhone Configuration Utility.
I added a trusted certificate to an iOS device using the iPhone Configuration Utility and confirmed that Safari accepts my self-signed certificate by sending my server a https request. However, when I make a simple test app that uses NSURLConnection to make a GET request to my server using HTTPS, I get the following error message:
"
Error - The certificate for this server is invalid. You might be connecting to a server enter code here`that is pretending to be “myserver” which could put your confidential information at risk.
"
I imagine that my iOS app is sandboxed, and does not accept the self-signed certificate by default. I've tried manipulating code in willSendRequestForAuthenticationChallenge to accept the self signed certificate without success. I was hoping that someone else has figured out how to do this. I do not want to accept all self-signed certificates. I only want to accept self-signed certificates that have been configured to be trusted on the device.
I want to make a HTTPS POST to a server using two PEM files which contain my private key and certificate, and the CACertificate of the server. I've done doing this from a windows application for a while and it works just right. Now I have to do the same from an iOS application on the iPad. It seems the Cocoa Framework does not have functions for this type of requests... any idea on how to do this or how to bring cURL on a iOS device would be appreciated.
UPDATE: I ended up using cURL compiled for iOS 5.1 with openSSL. Works perfectly.
maybe ASIHTTPRequest could help with the
Client certificates methods
If your server requires the use of client certificates, as of v1.8 it
is now possible to send them with your request.
// Will send the certificate attached to the identity (identity is a SecIdentityRef)
[request setClientCertificateIdentity:identity];
// Add an additional certificate (where cert is a SecCertificateRef)
[request setClientCertificates:[NSArray arrayWithObject:(id)cert]];
There is a helper function in ClientCertificateTests.m in the iPhone /
iPad sample app that can create a SecIdentityRef from PKCS12 data
(this function only works on iOS).
The Application i am working on needs to connect to a webservice over https, The certificate is trusted and valid.
I have used NSURLConnection is previous projects to use soap over http
Can anybody please point the difference between the two above mentioned scenarios,
I also need to understand what exactly happens when connecting over https, is the certificate stored automatically on the device, how does ssl handshake happen.
Any Pointers in this direction will be really helpful.
Regards,
Ishan
I need some clarification. Is the certificate signed by Apple for use with notifications or is it signed by an SSL root certificate authority (like VeriSign)?
Apple signed certificates are only to be used with WebServer to Apple Server communications like the Apple Push Notification Service. They are not intended for iOS device to WebServer.
A SSL certificate signed by a SSL root certificate authority should just work.
I think you are looking for an HTTP over SSL/TLS primer. So, here it goes.
HTTP is an unencrypted channel. The request and response are in a plain text data stream. HTTPS is an encrypted channel. The request and response are in a data stream encrypted using a shared master key. The magic of SSL/TLS is how this encrypted channel is created.
First, the client and server say hello to each other (in a clear channel).
Next, the client downloads the server's public certificate (in a clear channel).
At this point, the client has some work to do. It needs to verify the certificate. It needs to know that it understands the certificate, that the date range is valid, that the certificate is signed by a trusted certificate authority, and that the certificate has not been revoked.
Now, the client knows that it can trust the server.
Next, It sends a few short messages encrypted with the public key of the server (which is in the server's public certificate). These messages can only be decrypted by the server's private key (which only the server knows about). These messages allow the client and the server to negotiate a master key.
Finally, the client and the server begin the normal HTTP request and response using the newly created encrypted channel.
I hope this is what you are looking for. For a more detailed description see: http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
If the certificate was issued by a chain of certificate authorities whose root is trusted by Apple, then there is nothing to do. The iOS device will accept the certificate, as long as it is otherwise valid (ie not expired, not revoked, etc).
If the CA chain's root is not trusted by Apple, you will need to download the root's certificate to the phone. This can be done (I think) via the iPhone Configuration Utility. Enterprise provisioning scenarios undoubtedly support this also.