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://sampleActorSystem#172.16.0.10: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.
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
Related
I was able to achieve ssl offloading with Haproxy. So great product and appreciate that capability!
With that said, I need to doing mutual TLS but am a little confused on how that will work with the ingress controller configmap.
Going through this reference i've created a client cert, intermediate cert and root cert.
To note, I am terminating the ssl cert (which is from letsencrpt) on the load balancer currently.
However, the client cert and org CA are different than the lesencrypt tls/ssl cert that I have assigned as the SSL now; does that matter?
So, the first question I would have is does the ssl-certificate have to be set to the CA that will sign the client and server certs or can I just use the new ones I created in the instruction.
Setting up the configmap.
This is the part i'm confused on.
You can setup server-ca and server-crt but I don't think that applys here because after the ssl offloading there is nothing meant to be checked. However, I do want mTLS via the ssl termination.
So there is an configuration client-ca
Sets the client certificate authority enabling HAProxy to check clients certificate (TLS authentication), thus enabling client mTLS.
NB, ssl-offloading should be enabled for TLS authentication to work.
The client in this case being the actual client I want which is the device/frontend. Not the loadbalancer acting as a client to the backend server.
When I look at how this is setup:
frontend mysite
bind 192.168.56.20:80
bind 192.168.56.20:443 ssl crt /etc/haproxy/certs/ssl.crt verify required ca-file /etc/haproxy/certs/intermediate-ca.crt ca-verify-file /etc/haproxy/certs/root-ca.crt
http-request redirect scheme https unless { ssl_fc }
default_backend apiservers
Is it possible to do the same with the controller configmap as what is listed here below? There's a lot more going on that what I am seeing as flags / configurations that are in this methodology of applying client mTLS. Is there a way to achieve this in kubernetes without configmap?
The ssl parameter enables SSL termination for this listener. The crt parameter identifies the location of the PEM-formatted SSL certificate. This certificate should contain both the public certificate and private key.
You can restrict who can access your application by giving trusted clients a certificate that they must present when connecting. HAProxy will check for this if you add a verify required parameter to the bind line, as shown:
the ssl argument enables HTTPS
the crt argument specifies the server SSL certificate, which you will typically obtain from a certificate provider like Let’s Encrypt
the verify required argument requires clients to send a client certificate
the ca-file argument specifies the intermediate certificate with which we will verify that the client’s certificate has been signed with our organization’s CA
the ca-verify-file argument (introduced in HAProxy 2.2) includes the root CA certificate, allowing HAProxy to send a shorter list of CAs to the client in the SERVER HELLO message that will be used for verification, but keeping upper level CAs, such as the root, out of that list. HAProxy requires the root CA to be set with this argument or else included in the intermediate-ca.crt file (compatibility with older versions of HAProxy).
Also, my reasoning for now wanting to use letsencrypt and rather a private CA is because I can't renew device certificates every 60 - 90 days. That would not be efficient. In this case, and please let me know otherwise, I think it better to use either a real key/cert provider or in development testing utilize the openssl certs like in the HAProxy instruction.
It's odd but you really have to think about what a "client" is with these abstractions because I would never use this for a normal web page login but rather the server to server communication and in that sense this server is a client to this server. Or in my case this device is a client to this loadbalancer.
Can I use a certificate from letsencrypt to sign local certificates?
I'm annoyed when accessing routers and APs at 192.168.x.x to get security warnings.
I could create my own root cert, and import it into all my browsers etc, and create certs for all the local servers.
But I'd rather have the chain device -> www.example.com -> letsencrypt -> root
Then also guests could use my local servers/services without this security error.
No, you can not because the certificate issued to you by letsencrypt will not have the keyusage certificate signing enabled. Without this attribute in the issuer, any browser or SSL client musth reject the certificate.
If this were possible, anyone could issue valid certificates for any server simply by having a valid certificate from a trusted CA
If you want to issue certificates for your local servers you will need to create your own CA and include the root certificate in the truststore of each client
Yes, you can... but not like that
Yes, you can get certificates for servers on a private network. The domain must be a real domain with public txt records, but the A, AAAA, and CNAME records can be private/non-routable (or in a private zone).
No, the way to do that isn't by using Let's Encrypt certificates to sign local certificates.
You can accomplish exactly what you want to accomplish using the DNS-01 challenge (setting txt records for your domain).
Who is your domain / dns provider?
Immediate, but Temporary Solution
If you want to test it out real quick, try https://greenlock.domains and choose DNS instead of HTTP for the "how do you want to do this" step.
Automatable Integration
If you want a configurable, automatable, deployable solution try greenlock.js (there are node plugins for Cloudflare, Route 53, Digital Ocean, and a few other DNS providers).
Both use Let's Encrypt under the hood. Certbot can also be used for either case and can use python plugins.
Possibly related...
P.S. You might also be interested in a service like Telebit, localtunnel, or ngrok.
1) I am trying to setup an FTPS server on my EC2 Ubuntu instance. I can only find resources to setup tutorials for an SFTP server.
2)From what I understand, the SSL certificate is only applicable to the server. When a user tries to FTPS to my server, should he/she upload a certificate or public/private key file similar to SFTP? Or only hostname, port, username, password is sufficient?
You might have better luck searching for "ftp over tls" which is another name for ftps. TLS is the successor protocol to SSL, though often still referred to casually as "SSL."
I use proftpd and I mention that primarily because their docs discuss some theory and troubleshooting techniques using openssl s_client -connect which you will find quite handy regardless of which server you deploy.
The SSL cert is only required at the server side, and if you happen to have a web server "wildcard" cert, you may be able to reuse that, and avoid purchasing a new one.
Client certs are optional; username and password will suffice in many applications. Properly configured, authentication will only happen over encrypted connections. (Don't configure the server to also operate in cleartext mode on the standard ftp port; inevitably you'll find a client who thinks they are using TLS when they are not).
If client certs are required, it is because of your policy, rather than technical reasons. You'll find that SSL client certs operate differently than SSH. Typically the client certs are signed you a certificate authority that you create, and then you trust them because they are signed by your certificate authority as opposed to your possession of their public key, as in SSH.
Is there a way to secure the transport layer without any server certificate?
I read RFC 4492 and it is saying there is a key exchange algorithm name ECDH_ANON which does this, but on many of the links I found that it is not recommended to use this as it is prone to MITM (Man in the Middle) attack.
I just want to mention that my server is not public and my server and clients are in the same local subnet. My server is accepting connection on websocket.
What are the options if I want to secure my transport layer? I don't want to do it by manually encrypting the payload.
You could use a solution called TLS-SRP, if supported by your server and client(s). But probably more common is to just install a self-signed server certificate for your local system, or set up your own CA and issue your own cert to the server and install the CA's root cert as a trusted root on your clients.
I have a requirement to host address-bound or domain-bound certificates in either DNS CERT records or LDAP servers that are discoverable by other parties.
I tried to search on internet about them but didn't got much information.
So basically I need some link or some little explanation about address-bound or domain-bound certificates.
Thanks.
X.509 certificates when used for authentication of servers during SSL/TLS handshake include the server's host name or IP address in Subject.CommonName field and/or in the corresponding field SubjectAlternativeName extension. This information restricts the use of the certificate to certain host and also identifies the host. When the client connects to host A using IP address 1 and receives the certificate issued for host B and/or IP address 2, this is an evidence of either misconfigured server or fake server or stolen certificate. In these cases security of the communication can not be guaranteed.
What you are asking for are not standard terms, that's why you can't find information about them. The certificate can have both host name (or several) and IP address (or several) in it, so the certificate can't be called strictly "something-bound".