Using a self signed SSL certificate just for a web service

Question

I have a web service that clients will have and I want the data that's sent to the server encrypted. To test this I used a self signed SSL certificate. I know that when you use a self signed cert and when you navigate to whatever address is using it that the web browser will warn you that it's unsafe etc.

I am wondering if I'm I going to run into any problems if I used this certificate instead of a verified one when the web service goes live?

Also I don't have a domain name for the server, so I am just going to use the IP address given by my ISP, is this ok to do so with the certificate, because everywhere I read about them people are talking about using them with domain names?

Answer 1

An SSL certificate is usually issued to a domain and is signed by an issuing authority. When a browser connects to a server the server presents its certificate to the client. The client then verifies the certificate by checking if the domain that it is accessing is the same one as mentioned in the certificate. Also, it verifies its trust chain. This means that the issuer's certificate should also be valid. If the issuer is not the root signing authority then the issuer's issuer's certificate is verified. And, ultimately the root signing authority should be trusted which means the root signing authority should be in your truststore. All major signing authorities like Verisign, Thawte etc are by default in the JDK trustore hence if you have a certificate signed by them then you do not have issues in the verification of your trust chain. If your certificate is signed by an authority that is not trusted then you need to import the issuer's certificate in your trust chain manually.

Now, when using a self signed certificate, the entity to whom the certificate is issued is itself is the root signing authority. And hence the certificate should be imported into your truststore manually. You need to do this to get your SSL handshake through. But this alone does not solve your problem. Since, you are not using any domain name, your IP is likely to be changed every time you restart your server if you are obtaining your server IP automatically through a DHCP server. If this is the case then even a trusted self signed certificate won't work once the IP changes. Because, the certificate is issued to an IP and once the IP changes the certificate would become invalid. To get around this you need to get a static IP address for your server from your network admin. Then generate a self signed certificate for your static IP. Then ask your clients to add your server certificate in their trust store.

This would be a bit tedious for your clients. But, if you have a fixed number of clients and the client machines are under your control then you could add the server certificate to the client trust store yourself. But, if your server is open to all or have a huge number of client then I would suggest to get a certificate signed by a well known and trusted certification authority. Again, you would still need to have a static IP irrespective of who signs your certificate unless your server gets a domain name.

Answer 2

The issue with self-signed certificates is the same in any scenario, browser or non-browser: it assures absolutely nothing by itself. The purpose of SSL is two-fold: encryption and authentication. Typically both aspects are being used/required by SSL clients for a connection to be really regarded as secure.

For authentication ("who am I talking to?"), certificates are used. To authenticate your peer with a certificate, you will either have to have a copy of that certificate to compare to, or you will need to have a copy of the certificate of a signer of that certificate to compare the signature to. If you have neither, the certificate doesn't assure anything.

Meaning: self-signed certificates are fine if the client has a copy of that certificate and can trust the source of where they got the certificate from. If you have a very narrow use case where every client that's going to connect to your web service will have had prior contact with you (e.g. via email) and you are able to give a copy of the certificate to them for them to install into their local trust store, then they are able to establish a secure and authenticated connection to you regardless.

This is not workable for a typical website with arbitrary, random visitors; that's what signed certificates are for, where an already trusted entity can vouch for a heretofore unknown 3rd entity. It may be workable in a vendor-customer scenario though.

Having said that, certificates are dirt-cheap to free nowadays and lend more credibility and professionalism to your service.

And yes, certificates can be issued for IP addresses.