Please help me to understand one thing.
There is block of settings in cassandra for client's path of keystore and truststore SSL. I.e. I should configure in server node of Cassandra paths to CLIENT keystore.
But how does it work? It seems It is correct would be locate keystore/truststore of cliet on Application host, like POD, docker or
Application server and use keystore to connect to DBMS Cassandra. How client can use
his keystore, which is located on server?
enabled: true
keystore: E:/apache-cassandra-2.1.4/conf/.keystore
keystore_password: cassandra
# require_client_auth: false
# Set trustore and truststore_password if require_client_auth is true
# truststore: conf/.truststore
# truststore_password: cassandra
# More advanced defaults below:
# protocol: TLS
# algorithm: SunX509
# store_type: JKS
# cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
This block is used to check that the clients have valid certificate (that it's signed by trusted authority), use correct cipher, etc., or even enforce that client's certificate is registered in the truststore (if you set require_client_auth: true).
Basically, what you need is that your clients did use certificate that is signed by valid authority, known by Cassandra. DataStax has very detailed documentation on how to setup client-to-server SSL. Cassandra site also includes a lot, but some things could be specific to 4.0 release.
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.
I'm currently trying to setup GlusterFS integration for a Kubernetes cluster. Volume provisioning is done with Heketi.
GlusterFS-cluster has a pool of 3 VMs
1st node has Heketi server and client configured. Heketi API is secured with a self-signed certificate OpenSSL and can be accessed.
e.g. curl https://heketinodeip:8080/hello -k
returns the expected response.
StorageClass definition sets the "resturl" to Heketi API https://heketinodeip:8080
When storageclass was created successfully and I try to create a PVC, this fails:
"x509: certificate signed by unknown authority"
This is expected, as ususally one has to allow this insecure HTTPS-connection or explicitly import the issuer CA (e.g. a file simply containing the pem-String)
But: How is this done for Kubernetes? How do I allow this insecure connection to Heketi from Kubernetes, allowing insecure self-signed cert HTTPS or where/how do I import a CA?
It is not an DNS/IP problem, this was resolved with correct subjectAltName settings.
(seems that everybody is using Heketi, and it seems to be still a standard usecase for GlusterFS integration, but always without SSL, if connected to Kubernetes)
Thank you!
To skip verification of server cert, caller just need specify InsecureSkipVerify: true. Refer this github issue for more information (https://github.com/heketi/heketi/issues/1467)
In this page, they have specified a way to use self signed certificate. Not explained thoroughly but still can be useful (https://github.com/gluster/gluster-kubernetes/blob/master/docs/design/tls-security.md#self-signed-keys).
I use cert-manager to generate TLS certificates for my application on Kubernetes with Let's Encrypt.
It is running and I can see "ca.crt", "tls.crt" and "tsl.key" inside the container of my application (in /etc/letsencrypt/).
But "ca.crt" is empty, and the application complains about it (Error: Unable to load CA certificates. Check cafile "/etc/letsencrypt/ca.crt"). The two other files look like normal certificates.
What does that mean?
With cert-manager you have to use the nginx-ingress controller which will work as expose point.
ingress nginx controller will create one load balancer and you can setup your application tls certificate there.
There is nothing regarding certificate inside the pod of cert-manager.
so setup nginx ingress with cert-manager that will help to manage the tls certificate. that certificate will be stored in kubernetes secret.
Please follow this guide for more details:
https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes
I noticed this:
$ kubectl describe certificate iot-mysmartliving -n mqtt
...
Status:
Conditions:
...
Message: Certificate issuance in progress. Temporary certificate issued.
and a related line in the docs:
https://docs.cert-manager.io/en/latest/tasks/issuing-certificates/index.html?highlight=gce#temporary-certificates-whilst-issuing
They explain that the two existing certificates are generated for some compatibility, but they are not valid until the issuer has done its work.
So that suggests that the issuer is not properly set up.
Edit: yes it was. The DNS challenge was failing, the debug line that helped was
kubectl describe challenge --all-namespaces=true
More generally,
kubectl describe clusterissuer,certificate,order,challenge --all-namespaces=true
According to the documentation, cafile is for something else (trusted root certificates), and it would probably be more correct to use capath /etc/ssl/certs on most systems.
You can follow this guide if you have Windows Operating System:
tls.
Article is about how to enable Mosquitto and clients to use the TLS protocol.
Establishing a secure TLS connection to the Mosquitto broker requires key and certificate files. Creating all these files with the correct settings is not the easiest thing, but is rewarded with a secure way to communicate with the MQTT broker.
If you want to use TLS certificates you've generated using the Let's Encrypt service.
You need to be aware that current versions of mosquitto never update listener settings when running, so when you regenerate the server certificates you will need to completely restart the broker.
If you use DigitalOcean Kubernetes try to follow this instruction: ca-ninx, you can use Cert-Manager and ingress nginx controller, they will work like certbot.
Another solution is to create the certificate locally on your machine and then upload it to kubernetes secret and use secret on ingress.
I am getting this error from filebeat:
Failed to connect to backoff(elasticsearch(https://elk.example.com:9200)): Get https://elk.example.com:9200: x509: certificate signed by unknown authority
INFO pipeline/output.go:93 Attempting to reconnect to backoff(elasticsearch(https://elk.example.com:9200)) with 1468 reconnect attempt(s)
INFO [publish] pipeline/retry.go:189 retryer: send unwait-signal to consumer
INFO [publish] pipeline/retry.go:191 done
INFO [publish] pipeline/retry.go:166 retryer: send wait signal to consumer
INFO [publish] pipeline/retry.go:168 done
However, elasticsearch is having valid SSL by letsencrypt. (This is not a self-signed certificate).
Filebeat kubernetes config:
output.elasticsearch:
hosts: ['${ELASTICSEARCH_HOST:elasticsearch}:${ELASTICSEARCH_PORT:9200}']
username: ${ELASTICSEARCH_USERNAME}
password: ${ELASTICSEARCH_PASSWORD}
I tried adding these parameters in config file and it worked. But, why do I need to bypass verification even if certificate is valid.
ssl.verification_mode: "none"
The reason is either an old default operating system truststore that does not feature your very much valid and well-known trusted CA chains or the Elasticsearch certificate is self-signed or signed by a private CA.
You can choose from a number of solutions:
Run your filebeat in an environment (server, container, etc) with an updated default truststore that knows the CA that signed your certificate - i.e: upgrade to a newer version of the operating system or updated container image.
Remove your ssl.verification_mode: "none" configuration and add a ssl.certificate_authorities point to one or more PEM files with the to-be trusted CA certificates.
output.elasticsearch:
hosts: ['${ELASTICSEARCH_HOST:elasticsearch}:${ELASTICSEARCH_PORT:9200}']
username: ${ELASTICSEARCH_USERNAME}
password: ${ELASTICSEARCH_PASSWORD}
ssl.certificate_authorities: ["/path/to/ca.pem"]
Remove your ssl.verification_mode: "none" configuration and add a ssl.certificate_authorities configuration with the embedded to-be trusted CA certificate directly in the YAML configuration.
Example from filebeat configuration documentation.
certificate_authorities:
- |
-----BEGIN CERTIFICATE-----
MIIDCjCCAfKgAwIBAgITJ706Mu2wJlKckpIvkWxEHvEyijANBgkqhkiG9w0BAQsF
ADAUMRIwEAYDVQQDDAlsb2NhbGhvc3QwIBcNMTkwNzIyMTkyOTA0WhgPMjExOTA2
MjgxOTI5MDRaMBQxEjAQBgNVBAMMCWxvY2FsaG9zdDCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBANce58Y/JykI58iyOXpxGfw0/gMvF0hUQAcUrSMxEO6n
fZRA49b4OV4SwWmA3395uL2eB2NB8y8qdQ9muXUdPBWE4l9rMZ6gmfu90N5B5uEl
94NcfBfYOKi1fJQ9i7WKhTjlRkMCgBkWPkUokvBZFRt8RtF7zI77BSEorHGQCk9t
/D7BS0GJyfVEhftbWcFEAG3VRcoMhF7kUzYwp+qESoriFRYLeDWv68ZOvG7eoWnP
PsvZStEVEimjvK5NSESEQa9xWyJOmlOKXhkdymtcUd/nXnx6UTCFgnkgzSdTWV41
CI6B6aJ9svCTI2QuoIq2HxX/ix7OvW1huVmcyHVxyUECAwEAAaNTMFEwHQYDVR0O
BBYEFPwN1OceFGm9v6ux8G+DZ3TUDYxqMB8GA1UdIwQYMBaAFPwN1OceFGm9v6ux
8G+DZ3TUDYxqMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAG5D
874A4YI7YUwOVsVAdbWtgp1d0zKcPRR+r2OdSbTAV5/gcS3jgBJ3i1BN34JuDVFw
3DeJSYT3nxy2Y56lLnxDeF8CUTUtVQx3CuGkRg1ouGAHpO/6OqOhwLLorEmxi7tA
H2O8mtT0poX5AnOAhzVy7QW0D/k4WaoLyckM5hUa6RtvgvLxOwA0U+VGurCDoctu
8F4QOgTAWyh8EZIwaKCliFRSynDpv3JTUwtfZkxo6K6nce1RhCWFAsMvDZL8Dgc0
yvgJ38BRsFOtkRuAGSf6ZUwTO8JJRRIFnpUzXflAnGivK9M13D5GEQMmIl6U9Pvk
sxSmbIUfc2SGJGCJD4I=
-----END CERTIFICATE-----
Disclaimer: You have not provided a filebeat version so I assumed the latest one. Nevertheless, this kind of configuration will probably be the same across filebeat versions.
I have a Mosca MQTT broker running on a node instance and I would like to encrypt all the incoming communications with SSL/TLS (MQTTs protocol) but without the client having to link any certificate to the connexion (I guess it has to do with self-signed certificates) just as https works. I want all my clients to connect just with credentials specifying the MQTTs protocol and the communication can be encrypted. I was using Amazon MQ just before and that's how it works so I want the same.
I can't figure how to configure properly Mosca to do so, I don't know what kind of certificate I must use.
I added the secure field in the configuration as shown here
For the certificate I tried to create a self signed certificate as shown here
I also tried with certbot certificates (Let's Encrypt) registered for my domain name : mq.xxx.com .
I'm running everything on a ec2 (ubuntu 18) and my network and firewall are open for 1883 and 8883. My key and cert are at the root of my project where the deamon is running with good rights and ownership. I know my instance access them correctly.
new mosca.Server({
port: 1883,
secure: {
keyPath: "./privkey.pem",
certPath: "./cert.pem"
},
backend: {
type: 'redis',
redis: require('redis'),
host: "localhost",
port: 6379,
db: 0,
return_buffers: true,
},
persistence: {
factory: mosca.persistence.Redis
}
});
My server is running and working with simple mqtt on port 1883 but when I try to connect with ssl/tls with a client on port 8883 specifying that the server uses self-signed certificates (I tried with MQTT.fx) it fails saying : "unable to find valid certification path to requested target".
I can't make my head around this issue, I think somehow the client cannot "accept" or "verify" the certificate provided. Maybe I'm providing the wrong key or certificate to Mosca but there is only one of each resulting openssl or certbot. Maybe I created wrong but I follow many tutorials on the very same subject such as this one
What kind of certificate do I need to do ?
Is there something more to do with them ?
Thank you.
If you are using a self created certificate then the client will need a copy of certificate that signed the broker's certificate. This certificate will be added to the list of trusted sources so it can prove the broker is who it claims to be.
If you do not want to / can not distribute a certificate then you will need to use a certificate for your broker that is issued by CA (Certificate Authority) whoes signing certificate you already have (bundled into the OS/client that you are using).
The Lets Encrypt signing certificates should be bundled into most OSes by now but they are also cross signed by IdenTrust again who's certs should be bundled with most OSes. If you are having problems with the Lets Encrypt certs then I suggest you ask a new question with the exact details of how you configured mosca with those certs and more details of how you are configuring MQTT.fx and the errors you receive.