RESTful service with self-signed SSL
We are building an end-to-end solution that will allow our clients to access their ERP data hosted on their own servers through mobile applications. Version 1 will be an iOS app.
We need to make sure the traffic between the client and the server is SSL encrypted. The problem is that we want to keep the server setup as simple as possible, so we don't want the client to go through the process of buying and installing SSL certificates. Not to mention the need to renew this certificate every year.
We thought to create our own CA certificate and use it to create child certificates for each client to install on their servers (along with the public CA certificate). We would automate the child certificate generation process and include it as part of the installation process. The certificate will also have a very long expiration date to avoid having to deal with expiration. But if we use this certificate, requests from the client will not be trusted, since the CA will not be trusted.
- Can a CA be added to an iOS app or device?
- Is there a security issue with this implementation?
source to share
Now 2017 and letsencrypt exists, which provides free domain verification and TLS certificate signing so browsers / OS HTTPS or TLS Libraries and frameworks will accept them, and it is relatively easy to set up automatic renewals via certbot . I won't describe it here because this is a specific deployment, but they have good docs. When combined, they are probably the best solution out there.
Binding and using self-signed certificates is seriously suboptimal for a variety of reasons, and there is no reason to do it anymore (other than perhaps gross laziness), so don't do it.
Free is provided only for domain-certified base certificates, that is, where letencrypt.org confirms that you own the domain you say you own (and certbot is used to automate this process). You still need to pay for additional verification steps if you want to. However, for internal TLS connections between your application and your server, you really need domain validation, because you only need to be sure that you are talking to your server. The additional steps are more focused on customer confidence in the company, so they can transfer more sensitive data with more peace of mind. Generally speaking, if they are using your application, this assumes that they trust your company already, so additional verification is not important (and probablyinvisible to the client).
In development, if you want to use self-signed certificates, this might make sense. Check out my answer to this question on how to install self-signed certificates for all apps on your iOS device.
source to share