simple Akka ssl encryption

Question

There are several questions on stackoverflow regarding Akka, SSL and certificate management to enable secure (encrypted) peer to peer communication between Akka actors.

The Akka documentation on remoting (http://doc.akka.io/docs/akka/current/scala/remoting.html) points readers to this resource as an example of how to Generate X.509 Certificates.

http://typesafehub.github.io/ssl-config/CertificateGeneration.html#generating-a-server-ca

Since the actors are running on internal servers, the Generation of a server CA for example.com (or really any DNS name) seems unrelated. Most servers (for example EC2 instances running on Amazon Web Services) will be run in a VPC and the initial Akka remotes will be private IP addresses like

remote = "akka.tcp://[email protected]:2553"

My understanding, is that it should be possible to create a self signed certificate and generate a trust store that all peers share.

As more Akka nodes are brought online, they should (I assume) be able to use the same self signed certificate and trust store used by all other peers. I also assume, there is no need to trust all peers with an ever growing list of certificates, even if you don't have a CA, since the trust store would validate that certificate, and avoid man in the middle attacks.

The ideal solution, and hope - is that it possible to generate a single self signed certificate, without the CA steps, a single trust store file, and share it among any combination of Akka remotes / (both the client calling the remote and the remote, i.e. all peers)

There must be a simple to follow process to generate certificates for simple internal encryption and client authentication (just trust all peers the same)

Question: can these all be the same file on every peer, which will ensure they are talking to trusted clients, and enable encryption?

key-store = "/example/path/to/mykeystore.jks"
trust-store = "/example/path/to/mytruststore.jks"

Question: Are X.509 instructions linked above overkill - Is there a simple self signed / trust store approach without the CA steps? Specifically for internal IP addresses only (no DNS) and without an ever increasing web of IP addresses in a cert, since servers could autoscale up and down.

Answer 1

First, I have to admit that I do not know Akka, but I can give you the guidelines of identification with X509 certificates in the SSL protocol.

akka server configuration require a SSL certificate bound to a hostname

You will need a server with a DNS hostname assigned, for hostname verification. In this example, we assume the hostname is example.com.

A SSL certificate can be bound to a DNS name or an IP (not usual). In order for the client verification to be correct, it must correspond to the IP / hostname of the server

AKKA requires a certificate for each server, issued by a common CA

CA
  - server1: server1.yourdomain.com (or IP1)
  - server2: server2.yourdomain.com  (or IP2)

To simplify server deployment, you can use a wildcard *.yourdomain.com

CA
  - server1: *.yourdomain.com 
  - server2: *.yourdomain.com  

On the client side you need to configure a truststore including the public key of the CA certificate in the JKS. The client will trust in any certificate issued by this CA.

In the schema you have described I think you do not need the keystore. It is needed when you also want to identify the client with a certificate. The SSL encrypted channel will be stablished in both cases.

If you do not have a domain name like yourdomain.com and you want to use internal IP, I suggest to issue a certificate for each server and bound it to the IP address.

Depending on how akka is verifying the server certificate, it would be possible to use a unique self-signed certificate for all servers. Akka probably relies trust configuration to JVM defaults. If you include a self-signed certificate in the truststore (not the CA), the ssl socket factory will trust connections presenting this certificate, even if it is expired or if the hostname of the server and the certificate will not match. I do not recomend it