My application uses ASIHttpRequest for my server communication. I have a requirement that I should block HTTP protocol cos I dont wont to transmit that data over insecure link. So only SSL over HTTPS will be allowed. Also even thought the link is HTTPS I need to ensure that I am calling to the correct certificate. So I need a server certificate validation in my code. Please guide me how to do this.
I researched on this. I found few possible answers. One is to create a client certificate and do the validation. Also there are ways to "Client certificates support" under ASIHttpRequest documentation. So how to achieve my requirements above. Also integration of CFNetwork code into ASIHttpRequest will also do.
Regards,
Dilshan
You can get a validated certificate from an certificate authority like StartSSL or Thawte. Then iOS checks if the certificate is trusted by an authority. iOS comes with different trusted authorites.
If the server certificate is not validated by an authority the connection is rejected.
You don't need to do something special in code. Only use a https connection.
Related
I am developing an app with a server part programmed in Go and a client programmed in C#, the connection between the two is made using TCP socket communication, and to ensure the connection I am using TLS.
My question is whether there would be any security problem in my case when using self-signed certificates for TLS communication.
I understand that for a web server that uses https it is necessary to use certificates signed by a certificate authority (CA) but in my case, when connecting my own client application I don't see why I should use one of these.
If anyone knows anything about it, it would be a great help.
Certificates are used for authenticating the end points, and usually the cert is signed by a certificate authority which your client (such as a web browser) already trusts. Using a self-signed cert in that scenario can lead to problems, as the browser won't trust it, and so will pop a warning box. However, the real issue is that for the typical user, a warning from your server is as good as indistinguishable from an attacker using another self-signed certificate. They'll click-away and KABOOM!
If this is a closed environment, and you control both the server and client, then the self-signed certificate is irrelevant. In fact, you don't even need one at all, and may be better off with one of the alternatives, like TLS-PSK, or TLS-SRP.
I have to develop a web application that is both secured over https and uses client authentication certificates. The clients are connecting via invitation, thus it is not intended for users stumbling upon this application by googling around.
The ideal would be to get an intermediate CA certificate form a public root authority and sign both the ssl certificate and use it to issue client authentication certificates. I think that won't work, as simply put I will never qualify for such an intermediate CA (as far as I know, but maybe I am wrong with that).
Second guess: create own Root CA, an intermediate CA and use them. Because of what I wrote about the users, I can embed the necessary certificate chain in the issued certificates. This technically works.
What I would prefer is to get an ssl certificate from public authority and to use my own chain to issue authentication certificates and verify the users. According to this it is possible. But I haven't found anything about how to configure IIS for example (or Kestrel) to request client certificates issued by a specific CA, even less some standard specification where this flow is described.
I am trying to set up self signed SSL certificate for my IOS app which has a REST backend.
My question is should I use [securityPolicy setAllowInvalidCertificates:YES]; when we use self signed certificates? And NO with trusted certificates?
I didn't understand the exact mechanism however I read about SSL for hours.. It works with setAllowInvalidCertificates:YES but otherwise I get 1012 error.
Yes, you should set [securityPolicy setAllowInvalidCertificates:YES]; when using self signed certificates. And correct; you should use NO with trusted certificates.
You are likely still getting the error when it is set to NO because a part of your certificate chain is not trusted. Try using an app called SSL Detective to make sure the entire chain is trusted with no red (untrusted) components. AFNetworking doesn't like those.
My question is should I use [securityPolicy setAllowInvalidCertificates:YES]; when we use self signed certificates? And NO with trusted certificates?
No! This would defeat the whole purpose of SSL because it would make man-in-the-middle attacks possible. Better use public key pinning. I don't know how to do this with AFNetwork, but the linked resource has code for lots of environments.
I am implementing a push notification system for one of my apps, so I am following this tutorial and generating a SSL certificate for that.
This app of mine involves also, some exchange of data between the app and the server and I would like it to be SSL protected and I was wondering of getting a SSL certificate from verisign or other company like that.
My question is: is this SSL certificate created for push a regular SSL certificate, so in that can use it also to establish a https connection to the server (and save a couple hundred dollars to order a third party certificate)? I don't know much about SSL certificates, but I hope it can be used for that...
This will be amazing!
Since each certificate is tied to a specific domain, I'm not sure how this would work. There is a concept of wildcard certificates, but I still think they have to be for the same domain.
In your case, it sounds like you will have the Apple push certificate, which validates the connection between your server and Apple's push notification server. The other certificate would be to validate/secure the connection between your iOS app and your server. Both of these are assigned a different domain (gateway.sandbox.push.apple.com vs. yourserver.com).
One option you do have depending on how your iOS app is structured is to use a self-signed certificate between your iOS app and your server. I'm guessing the end-user will not be seeing the certificate anyway. This might be a way to save you money before deciding on a third party certificate.
Is there a way to create self-signed certificate on IOS programatically?
We have a client-server connection, where the pairing is confirmed just once and then the certificate is used every time to re-establish connection.
right now we're doing it using openssl, but that is a little bit excessive for our needs. does ios have any mechanisms that would
generate the x509 certificate
apply it to socket (ergo create equivalent of SSL socket)
query certificate sent by the server, so that it could be stored to verify server identity?
thank you!