I have trouble using SSL keystore or truststore to connect to Elasticsearch client using DBeaver. This is an elastic stack on k8s installation on my local machine. I followed this official tutorial to set up a connection using DBeaver, but I have trouble figuring out how to make cert validation work.
I logged into the elasticsearch pod, downloaded the cert and key at /usr/share/elasticsearch/config/http-certs/tls.crt and /usr/share/elasticsearch/config/http-certs/tls.key. I combined them into a p12 format using this command:
openssl pkcs12 -export -in combined.pem -out cert.p12
elasticsearch.config:
http:
ssl:
certificate: /usr/share/elasticsearch/config/http-certs/tls.crt
certificate_authorities: /usr/share/elasticsearch/config/http-certs/ca.crt
enabled: true
key: /usr/share/elasticsearch/config/http-certs/tls.key
transport:
ssl:
certificate: /usr/share/elasticsearch/config/node-transport-cert/transport.tls.crt
certificate_authorities:
- /usr/share/elasticsearch/config/transport-certs/ca.crt
- /usr/share/elasticsearch/config/transport-remote-certs/ca.crt
enabled: "true"
key: /usr/share/elasticsearch/config/node-transport-cert/transport.tls.key
verification_mode: certificate
However, I'm getting this invalid cert error:
These are the driver parameters:
What certs do I need in order to pass the cert check? I wish there was an insecure flag to ignore the validation since it runs in localhost.
Related
I can't get Elastic and Kibana to work with real certificates from either Let's encrypt or Comodo.
I've thought about it a thousand times, but no matter how much I read and reread, I can't find the error of something as simple as installing certificate chains. At first I thought it was a Let's Encrypt issue but this afternoon I bought some certificates issued by Comodo and nothing, the same.
/usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic
17:21:59.701 [main] WARN org.elasticsearch.common.ssl.DiagnosticTrustManager - failed to establish trust with server at [91.121.226.53]; the server provided a certificate with subject name [CN=elk2.mydomain.ovh], fingerprint [f611c9e9ce2462ed1f3c7e29035f2db2347e39df], keyUsage [digitalSignature, keyEncipherment] and extendedKeyUsage [serverAuth, clientAuth]; the session uses cipher suite [TLS_AES_256_GCM_SHA384] and protocol [TLSv1.3]; the certificate has subject alternative names [DNS:elk2.mydomain.ovh,DNS:www.elk2.mydomain.ovh]; the certificate is issued by [CN=Don Dominio / MrDomain RSA DV CA,O=Soluciones Corporativas IP\, SL,L=Manacor,ST=Illes Balears,C=ES] but the server did not provide a copy of the issuing certificate in the certificate chain; the issuing certificate with fingerprint [ce1710a80bd0dfb6ed688c37c8fc066268bd814b] is trusted in this ssl context ([xpack.security.http.ssl (with trust configuration: PEM-trust{/etc/elasticsearch/certs/elk2.mydomain.ovh.ca.crt})])
/etc/kibana/kibana.yml
server.host: "91.121.226.53"
server.publicBaseUrl: "https://elk2.mydomain.ovh:5601"
server.name: "elk2.mydomain.ovh"
server.ssl.enabled: true
server.ssl.certificate: certs/elk2.mydomain.ovh.crt
server.ssl.key: certs/elk2.mydomain.ovh.key
server.ssl.certificateAuthorities: ["certs/elk2.mydomain.ovh.ca.crt"]
elasticsearch.hosts: ["https://elk2.mydomain.ovh:9200"]
elasticsearch.ssl.certificate: certs/elk2.mydomain.ovh.crt
elasticsearch.ssl.key: certs/elk2.mydomain.ovh.key
elasticsearch.ssl.certificateAuthorities: [ "certs/elk2.mydomain.ovh.ca.crt" ]
elasticsearch.ssl.verificationMode: none
logging:
appenders:
file:
type: file
fileName: /var/log/kibana/kibana.log
layout:
type: json
root:
appenders:
- default
- file
pid.file: /run/kibana/kibana.pid
Elasticsearch
root#elk2:/etc/ssl# grep -Ev '^#|^$' /etc/elasticsearch/elasticsearch.yml
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
xpack.security.enabled: true
xpack.security.enrollment.enabled: true
xpack.security.http.ssl:
enabled: true
key: certs/elk2.mydomain.ovh.key
certificate: certs/elk2.mydomain.ovh.crt
certificate_authorities: ["certs/elk2.mydomain.ovh.ca.crt"]
xpack.security.transport.ssl:
enabled: true
verification_mode: certificate
key: certs/elk2.mydomain.ovh.key
certificate: certs/elk2.mydomain.ovh.crt
certificate_authorities: ["certs/elk2.mydomain.ovh.ca.crt"]
cluster.initial_master_nodes: ["elk2.mydomain.ovh"]
http.host: 0.0.0.0
Of course I have verified the files found in both the elasticsearch and kibana certs, just as I do with any software installation that requires certificates, including authority or CA
Way with LetsEncript
elasticsearch.yml
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
xpack.security.enabled: true
xpack.security.enrollment.enabled: true
xpack.security.http.ssl:
enabled: true
key: certs/privkey.pem
certificate: certs/fullchain.pem
certificate_authorities: [
"certs/chain.pem",
"certs/cacert.r3.pem"
]
xpack.security.transport.ssl:
enabled: true
verification_mode: certificate
key: certs/privkey.pem
certificate: certs/fullchain.pem
certificate_authorities: [
"certs/chain.pem",
"certs/cacert.r3.pem" ### Try also with pem root ISRG Root X1 cacert.x1.pem
]
cluster.initial_master_nodes: ["elk2.mydomain.ovh"]
http.host: 0.0.0.0
kibana.yml
server.host: "91.121.226.53"
server.publicBaseUrl: "https://elk2.mydomain.ovh:5601"
server.name: "elk2.mydomain.ovh"
server.ssl.enabled: true
server.ssl.certificate: certs/fullchain.pem
server.ssl.key: certs/key.pem
server.ssl.certificateAuthorities: [
"certs/chain.pem",
"certs/cacert.r3.pem"
]
elasticsearch.hosts: ["https://elk2.mydomain.ovh:9200"]
elasticsearch.ssl.certificate: certs/fullchain.pem
elasticsearch.ssl.key: certs/fullchain.key
elasticsearch.ssl.certificateAuthorities: [
"certs/chain.pem",
"certs/cacert.r3.pem"
]]
logging:
appenders:
file:
type: file
fileName: /var/log/kibana/kibana.log
layout:
type: json
root:
appenders:
- default
- file
pid.file: /run/kibana/kibana.pid
Error
/usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic
18:28:33.799 [main] WARN org.elasticsearch.common.ssl.DiagnosticTrustManager - failed to establish trust with server at [91.121.226.53]; the server provided a certificate with subject name [CN=elk2.endesarrollo.ovh], fingerprint [d3432f5a03043e533bd1a7a1aeabce8964bd1ac2], keyUsage [digitalSignature, keyEncipherment] and extendedKeyUsage [serverAuth, clientAuth]; the session uses cipher suite [TLS_AES_256_GCM_SHA384] and protocol [TLSv1.3]; the certificate has subject alternative names [DNS:elk2.endesarrollo.ovh]; the certificate is issued by [CN=R3,O=Let's Encrypt,C=US]; the certificate is signed by (subject [CN=R3,O=Let's Encrypt,C=US] fingerprint [a053375bfe84e8b748782c7cee15827a6af5a405] {trusted issuer}) signed by (subject [CN=ISRG Root X1,O=Internet Security Research Group,C=US] fingerprint [933c6ddee95c9c41a40f9f50493d82be03ad87bf] {trusted issuer}) which is issued by [CN=DST Root CA X3,O=Digital Signature Trust Co.] (but that issuer certificate was not provided in the chain); this ssl context ([xpack.security.http.ssl (with trust configuration: PEM-trust{/etc/elasticsearch/certs/chain.pem,/etc/elasticsearch/certs/cacert.r3.pem})]) is not configured to trust that issuer but trusts [2] other issuers ([CN=ISRG Root X1,O=Internet Security Research Group,C=US, CN=R3,O=Let's Encrypt,C=US])
java.security.cert.CertificateException: No subject alternative names matching IP address 91.121.226.53 found
```
Apreciate help.
I'm using http-server to serve my local project through HTTPS. To create the key.pem and the cert.pem files, I followed the documentation:
First, you need to make sure that openssl is installed correctly, and
you have key.pem and cert.pem files. You can generate them using this
command:
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem
You will be prompted with a few questions after
entering the command. Use 127.0.0.1 as value for "Common name" if you
want to be able to install the certificate in your OS's root
certificate store or browser so that it is trusted.
This generates a cert-key pair and it will be valid for 3650 days
(about 10 years).
Then you need to run the server with -S for enabling SSL and -C for
your certificate file.
http-server -S -C cert.pem
I used the openssl.exe come with the Git, and installed the generated certificate on Windows (onto the "Trusted Root Certification Authorities" entry). Here is the output after running the server:
Starting up http-server, serving ./ through https
http-server version: 14.1.1
http-server settings:
CORS: disabled
Cache: 3600 seconds
Connection Timeout: 120 seconds
Directory Listings: visible
AutoIndex: visible
Serve GZIP Files: false
Serve Brotli Files: false
Default File Extension: none
Available on:
https://10.20.30.232:8080
https://192.168.56.1:8080
https://192.168.1.126:8080
https://127.0.0.1:8080
Hit CTRL-C to stop the server
But, when I access the https://127.0.0.1:8080, I'm encountered with the following error on Google Chrome:
Your connection is not private
...
NET::ERR_CERT_COMMON_NAME_INVALID
Subject: 127.0.0.1
Issuer: 127.0.0.1
...
This server could not prove that it is 127.0.0.1; its security certificate does not specify Subject Alternative Names.
And, the following is the error message Mozilla Firefox presents:
127.0.0.1:8080 uses an invalid security certificate.
The certificate does not come from a trusted source.
Error code: MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY
https://127.0.0.1:8080/
The server uses a certificate with a basic constraints extension identifying it
as a certificate authority. For a properly-issued certificate, this should not
be the case.
HTTP Strict Transport Security: false
HTTP Public Key Pinning: false
So, what am I missing on setting up the HTTPS server to avoid the aforementioned errors?!
Chrome should accept this certificate if you explicitly list 127.0.0.1 as a "Subject Alternative Name" (SAN) of type IP. You can do so by adding -addext "subjectAltName = IP:127.0.0.1" to the openssl command:
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem -addext "subjectAltName = IP:127.0.0.1"
Firefox complains about a very different issue, i.e. that a certificate with a basic constraints extension with CA:TRUE is being used as an end-entity certificate. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1034124
You could try to generate the certificate without the basic constraints extenstion.
The shortcut solution would be to leverage existing solutions like https://github.com/FiloSottile/mkcert or https://github.com/davewasmer/devcert.
i try to develop my SpringBoot Backend Application on STRATO.de
i buyed a ubunutu vServer and runned my spring app via jar.
but backend (http) and frontend (https) cant connect because of the ssl. I created a self signed jks file for my spring boot app and the https works but when i open my backend ip adress and port firstly i get the message "this ist not a secure connection" and i have to accept the certificate. After that everything works fine.
Is there a Option to get a secure connection? i try to use LetsEncrypt CerBot etc. nothing works. The Tutorials are not for the newest Ubuntu version.
Where can i secure my SpringBoot app via HTTPS without a SelfSigned certificate?
Both frontend & backend needs to have https connection for secured communication. Hence it's necessary to use https for your spring-boot application. Self signed jks is only good for development, which is not meant to be used for production.
You may follow these steps:
Install OpenSSL if not available in your server. How to install OpenSSL
Run this command, # openssl req -new -newkey rsa:2048 -nodes -keyout yourkey.key -out yourcsr.csr
Here, yourkey.key = It’s your private key and
yourcsr.csr = Your Certificate Signing Request which needs to send to CA authorities. While creating CSR, it will ask some questions, which will be later required for keystore. Hence, save them properly.
Buy your SSL certificate from your preferable registrant, ie name.com
Send your yourcsr.csr file information to the registrants. Please follow their respective instructions.
Once approved, you will receive two files. yourserver.crt and yourca.crt
# openssl pkcs12 -export -in yourserver.crt -inkey yourkey.key -out yourkeystore.p12 -name somealias -certfile yourca.crt -caname root
It will ask some questions, pls make sure it matches the information that you provided earlier while creating the CSR. It will prompt for password for the keystore. This command will create a keystore named yourkeystore.p12
# keytool -importkeystore -srckeystore yourkeystore.p12 -srcstoretype PKCS12 -destkeystore yourkeystore.jks -deststoretype JKS -deststorepass newkeystorepassword -destkeypass newkeypassword Convert to JKS, if you specifically want to use JKS for spring boot. This command will create a keystore named yourkeystore.jks
Put required information at application.properties.
server.port: 8443
server.ssl.key-store: classpath: yourkeystore.jks
server.ssl.key-store-password: newkeystorepassword
server.ssl.key-store-type: jks
server.ssl.key-alias: somealias
server.ssl.key-password: newkeypassword
I'm receiving the following SSL error on my rake rspec unit tests when I try to connect to the vault on my docker container using HTTPS:
OpenSSL::SSL::SSLError:
SSL_connect returned=1 errno=0 state=error: wrong version number
We're using docker to load a local instance of a hashicorp vault
Here's the command I run to generate the TLS Certificates
RUN openssl req -new -newkey rsa:4096 -x509 -sha256 -days 365 -nodes -subj "$SUBJ" -out /vault/certificates/tls/vault.crt \
-keyout /vault/certificates/tls/vault.key
When I log into the docker container and run openssl version I get:
/ # openssl version
OpenSSL 1.1.1k 25 Mar 2021
When I try to connect to the docker container from my local prompt, I get:
$ openssl s_client -connect 'localhost:8200'
CONNECTED(000001F0)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 308 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1620224762
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
26612:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:827:
When I run this command in my local irb I get:
irb(main):001:0> require 'openssl'
=> true
irb(main):002:0> OpenSSL::SSL::SSLContext::DEFAULT_PARAMS
=> {:min_version=>769, :verify_mode=>1, :verify_hostname=>true, :options=>2147614804}
irb(main):003:0>
This is my vault configurations:
listener "tcp" {
address = "[::]:8200"
cluster_address = "[::]:8201"
tls_cert_file = "/vault/certificates/tls/vault.crt"
tls_key_file = "/vault/certificates/tls/vault.key"
}
Also, i noticed in the docker logs we have two listeners now:
Listener 1: tcp (addr: "0.0.0.0:1234", cluster address: "0.0.0.0:1235", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
Listener 2: tcp (addr: "[::]:8200", cluster address: "[::]:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "enabled")
And my docker vault server startup command is:
vault server -config=/vault/config -dev-root-token-id=myroot -dev-listen-address=0.0.0.0:1234 -dev &
And i noticed in the logs its still seeing an http connection...
Error writing data to pki/root/generate/internal: Put https://127.0.0.1:1234/v1/pki/root/generate/internal: http: server gave HTTP response to HTTPS client
Error writing data to pki/config/urls: Put https://127.0.0.1:1234/v1/pki/config/urls: http: server gave HTTP response to HTTPS client
Error writing data to pki/roles/localhost: Put https://127.0.0.1:1234/v1/pki/roles/localhost: http: server gave HTTP response to HTTPS client
Error writing data to pki/issue/localhost: Put https://127.0.0.1:1234/v1/pki/issue/localhost: http: server gave HTTP response to HTTPS client
I'm kind of lost right now on how to handle this.
In Burp Suite, from Project Options -> SSL we can import PKCS#12 files with password for specific hostnames.
I tried manually using commands below to export block and key files and then pass them to my http client in golang using tls.LoadX509KeyPair(). But upon sending any requests, I receive remote error: tls: handshake failure.
These are the commands I used:
openssl pkcs12 -in cert.p12 -clcerts -nokeys -out usercert.pem
openssl pkcs12 -in cert.p12 -nocerts -out userkey.pem -nodes
What am I missing?
If using a self-signed certificate specify InsecureSkipVerify: true in your tls configuration. Pulled from the documentation:
// InsecureSkipVerify controls whether a client verifies the
// server's certificate chain and host name.
// If InsecureSkipVerify is true, TLS accepts any certificate
// presented by the server and any host name in that certificate.
// In this mode, TLS is susceptible to man-in-the-middle attacks.
// This should be used only for testing.```
Otherwise, add your certificate to the Certificates list in your tls configuration.