Ci sono diverse domande sullo stackoverflow relative ad Akka, SSL e gestione dei certificati per consentire comunicazioni peer-to-peer sicure (crittografate) tra gli attori Akka.
La documentazione di Akka sui servizi remoti indirizza i lettori a questa risorsa come esempio di come generare X. 509 certificati.
Poiché gli attori sono in esecuzione su server interni, la generazione di una CA server per example.com (o qualsiasi nome DNS) sembra non correlata.
La maggior parte dei server (ad esempio istanze EC2 in esecuzione su Amazon Web Services) verranno eseguiti in un VPC e i primi telecomandi di Akka saranno indirizzi IP privati come
remote = "akka.tcp://[email protected]:2553"
La mia comprensione è che dovrebbe essere possibile creare un certificato autofirmato e generare un negozio di fiducia condiviso da tutti i peer.
Man mano che più nodi Akka vengono portati online, dovrebbero (presumo) essere in grado di utilizzare lo stesso certificato autofirmato e lo stesso trust store utilizzato da tutti gli altri peer. Suppongo anche che non sia necessario affidarsi a tutti i peer con un elenco sempre crescente di certificati, anche se non si dispone di una CA, poiché il trust store convalida tale certificato ed evita gli attacchi man in the middle.
La soluzione ideale, e speriamo - è che sia possibile generare un singolo certificato autofirmato, senza i passaggi della CA, un singolo file di fiduciario e condividerlo tra qualsiasi combinazione di telecomandi Akka / (sia il client che chiama il telecomando e il telecomando, ovvero tutti i peer)
Ci deve essere un processo semplice da seguire per generare certificati per la semplice crittografia interna e l'autenticazione del client (fidati solo di tutti i peer)
Domanda: possono essere tutti lo stesso file su ogni peer poiché sono interni e privati (senza DNS)?
key-store = "/example/path/to/mykeystore.jks"
trust-store = "/example/path/to/mytruststore.jks"
Domanda: le istruzioni X.509 sono collegate sopra l'overkill? Esiste un semplice approccio self-signed / trust store senza i passaggi della CA? Specificamente per gli indirizzi IP interni (senza DNS) e senza una rete sempre crescente di indirizzi IP in un certificato, poiché i server possono eseguire la scalabilità automatica verso l'alto e verso il basso.
Poiché tutto è interno e amp; privato, possiamo solo fare questo:
#!/bin/bash
# create self signed certificate for use in Java SSL
export PW='pwgen -Bs 10 1'
echo $PW > example-self-cert-password
# generate a key valid for 9999 days, or 27 years
# self signed certificate for encryption
keytool -genkeypair -alias example-self -keyalg RSA \
-keypass:env PW -storepass:env PW \
-keystore example-self-keystore.jks -validity 9999 \
-keysize 4096 \
-dname "CN=example-selfCA, OU=Cloud Services, O=example company, L=San Francisco, ST=m=California, C=US"
# Extract the certificate
keytool -export -keystore example-self-keystore.jks -alias example-self -file example-self.cer \
-keypass:env PW \
-storepass:env PW
# Importing into the truststore
keytool -import -alias example-self -file example-self.cer -keystore example-self-truststore.jks \
-storepass:env PW << EOF
yes
EOF
# optional
# list out to confirm
keytool -list -v \
-keystore example-self-truststore.jks \
-storepass:env PW
# optional
# if you want an openssl PEM file, convert it
openssl x509 -inform der -in example-self.cer -out example-self.pem