Use TLS Certificates

Transport Layer Security (TLS) certificates provide secure communications between the client and server.
Companies frequently choose to conduct all web service requests over a secure HTTP connection (HTTPS). This is accomplished through a connection often referred to as Secure Socket Layer (SSL). The newer terminology (and protocol) for such a secure connection is Transport Layer Security (TLS).
About TLS Certificates
To configure TLS communications, you create TLS certificates and create data stores to hold those certificates. A server certificate represents your REST API server. Depending on your security needs you can also create a client certificate.
A server in a TLS conversation (in this case your REST API server) has a keystore in which it stores the certificates, which verify that the server is who it claims to be. The server sends its certificate to a client during TLS negotiation. A client has a truststore, in which it stores certificates that it is willing to trust. The client confirms the certificate that is sent by the server during TLS negotiations against the client’s truststore.
You can also optionally configure the additional TLS security of client-side certificates. This is not as frequently done, but it is a capability of certificates. In this scenario, you configure a server to demand a client certificate. You create a client certificate and store it into the client’s keystore and into the server’s truststore. This technique is essentially the reverse of the procedure that is used to deploy a server certificate. You must do this procedure for every remote client in your environment. During TLS negotiation, the server asks the client for its certificate. The client retrieves its certificate from its keystore and sends it to the server. The server verifies the certificate against the server’s truststore. Through this procedure, the server verifies that the client application can be trusted.
Using Certificate Authorities
Certificate Authorities, like VeriSign, Entrust, and DigiCert, can be used to sign a given server’s certificate. With a signed certificate, a client does not need a certificate from every server in the world stored in its truststore. If the client trusts a Certificate Authority, it knows that it can trust a certificate that it receives from an otherwise unknown server, as long as the certificate is signed by a Certificate Authority. Public web server applications and web browsers often use this type of approach, because of the sheer volume of clients and servers.
Obtaining a certificate that is signed by a Certificate Authority is beyond the scope of this document. The recommended practice for deploying certificates for your corporate REST API server is to obtain a certificate from your company’s security department. Individuals can create a self-signed certificate for a server. You may choose to do this to test an application while you wait for a certificate from your security department. Regardless of where it comes from, if your certificate is self-signed, you must place it into both the server’s keystore and into the client’s truststore.
Using the Keytool Program
One commonly available application for creating keystores and truststores is a program named keytool from your Java Runtime Environment. Keytool can also create a self-signed certificate, place a certificate into a keystore, import a certificate signed by a Certificate Authority, export a certificate from a keystore, and import a certificate into a truststore. Using these capabilities of keytool, you can create the various scenarios described above. You must read the documentation for keytool to learn the details required to accomplish those steps.