Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kibana doesn't properly trust server certificates with an empty Subject #57009

Closed
jportner opened this issue Feb 6, 2020 · 3 comments
Closed
Assignees
Labels
bug Fixes for quality problems that affect the customer experience Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!

Comments

@jportner
Copy link
Contributor

jportner commented Feb 6, 2020

Kibana version: 7.6 and below

Original install method (e.g. download page, yum, from source, etc.): source

Describe the bug: Kibana doesn't properly establish trust for server certificates that have an empty Subject and a valid Subject Alternative Name (SAN). This problem can be encountered any place in Kibana that establishes an outbound HTTPS connection.

Steps to reproduce:

  1. Generate a certificate authority (CA)
  2. Generate a certificate signing request (CSR) with an empty Subject and a valid Subject Alternative Name (SAN), then sign it with the CA to produce the server certificate
  3. Start Elasticsearch with the new server certificate
  4. Configure Kibana to trust the CA
  5. Start Kibana
Script to generate such a certificate
### GENERATE NEW P12 KEYSTORES
CA1='es-root-ca'
CA2='es-intermediate-ca'
EE1='elasticsearch'
bin/elasticsearch-certutil ca --ca-dn "CN=Elasticsearch Root CA" -days 18250 --out $CA1.p12 --pass castorepass
bin/elasticsearch-certutil ca --ca-dn "CN=Elasticsearch Intermediate CA" -days 18250 --out $CA2.p12 --pass castorepass

### CONVERT P12 KEYSTORES TO PEM FILES
openssl pkcs12 -in $CA1.p12 -out $CA1.crt -nokeys -passin pass:"castorepass" -passout pass:
openssl pkcs12 -in $CA1.p12 -nocerts -passin pass:"castorepass" -passout pass:"keypass" | openssl rsa -passin pass:"keypass" -out $CA1.key

openssl pkcs12 -in $CA2.p12 -out $CA2.crt -nokeys -passin pass:"castorepass" -passout pass:
openssl pkcs12 -in $CA2.p12 -nocerts -passin pass:"castorepass" -passout pass:"keypass" | openssl rsa -passin pass:"keypass" -out $CA2.key

### RE-SIGN INTERMEDIATE CA CERT
mkdir -p ./tmp
openssl x509 -x509toreq -in $CA2.crt -signkey $CA2.key -out ./tmp/$CA2.csr
dd if=/dev/urandom of=./tmp/rand bs=256 count=1
touch ./tmp/index.txt
echo "01" > ./tmp/serial
cp /System/Library/OpenSSL/openssl.cnf ./tmp/
echo "
[ tmpcnf ]
dir             = ./
certs           = ./
new_certs_dir   = ./tmp
crl_dir         = ./tmp/crl
database        = ./tmp/index.txt
unique_subject  = no
certificate     = ./$CA1.crt
serial          = ./tmp/serial
crlnumber       = ./tmp/crlnumber
crl             = ./tmp/crl.pem
private_key     = ./$CA1.key
RANDFILE        = ./tmp/rand
x509_extensions = v3_ca
name_opt        = ca_default
cert_opt        = ca_default
default_days    = 18250
default_crl_days= 30
default_md      = sha256
preserve        = no
policy          = policy_anything
" >> ./tmp/openssl.cnf

# The next command requires user input
openssl ca -config ./tmp/openssl.cnf -name tmpcnf -in ./tmp/$CA2.csr -out $CA2.crt -verbose

### RE-CREATE END-ENTITY CERT
echo "
[ req ]
encrypt_key        = no
distinguished_name = req_distinguished_name

[ req_distinguished_name ]
" > ./tmp/opensslreq.cnf
echo "
[ v3_req ]
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer
subjectAltName         = critical,DNS:localhost
basicConstraints       = CA:FALSE
" > ./tmp/opensslext.cnf
openssl req -new -newkey rsa:2048 -nodes -config ./tmp/opensslreq.cnf -subj "/" -outform pem -out $EE1.csr -keyout $EE1.key

# The next command requires user input
openssl x509 -req -days 18250 -in $EE1.csr -CA $CA2.crt -CAkey $CA2.key -CAcreateserial -CAserial ./tmp/$CA2.srl -sha256 -out $EE1.crt -outform pem -extensions v3_req -extfile ./tmp/opensslext.cnf

### CONVERT PEM FILES BACK TO P12 KEYSTORES
cat $CA2.key $CA2.crt $CA1.crt | openssl pkcs12 -export -name $CA2 -passout pass:"castorepass" -out $CA2.p12
cat $EE1.key $EE1.crt $CA1.crt $CA2.crt | openssl pkcs12 -export -name $EE1 -passout pass:"storepass" -out $EE1.p12

### VERIFY CONTENTS OF KEYSTORES
openssl pkcs12 -info -nodes -in $CA1.p12 -passin pass:"castorepass"
openssl pkcs12 -info -nodes -in $CA2.p12 -passin pass:"castorepass"
openssl pkcs12 -info -nodes -in $EE1.p12 -passin pass:"storepass"

### VERIFY CERT CHAIN IS PRESENTED (after Elasticsearch is running)
keytool -printcert -sslserver localhost:9200

Expected behavior: Kibana should connect to Elasticsearch and properly trust the TLS certificate. According to RFC 5280 section 4.1.2.6, an end-entity certificate does not have to have a Subject set to be valid.

Provide logs and/or server output (if relevant): As described above, this problem can be encountered any place in Kibana that establishes an outbound HTTPS connection. The specific error message is: Hostname/IP does not match certificate's altnames: Cert is empty. Sample server output:

server    log   [14:07:05.698] [error][admin][elasticsearch] Request error, retrying
GET https://localhost:9200/_nodes?filter_path=nodes.*.version%2Cnodes.*.http.publish_address%2Cnodes.*.ip => Hostname/IP does not match certificate's altnames: Cert is empty
server    log   [14:07:05.702] [error][data][elasticsearch] Request error, retrying
GET https://localhost:9200/_xpack => Hostname/IP does not match certificate's altnames: Cert is empty
server    log   [14:07:05.705] [error][data][elasticsearch] Request error, retrying
HEAD https://localhost:9200/.apm-agent-configuration => Hostname/IP does not match certificate's altnames: Cert is empty
server    log   [14:07:05.713] [warning][data][elasticsearch] Unable to revive connection: https://localhost:9200/
server    log   [14:07:05.713] [warning][data][elasticsearch] No living connections
server    log   [14:07:05.714] [warning][licensing][plugins] License information could not be obtained from Elasticsearch due to Error: No Living connections error
server    log   [14:07:05.716] [info][plugins][searchprofiler] You cannot use searchprofiler because license information is not available at this time.
server    log   [14:07:05.718] [warning][admin][elasticsearch] Unable to revive connection: https://localhost:9200/
server    log   [14:07:05.718] [warning][admin][elasticsearch] No living connections
server    log   [14:07:05.719] [error][elasticsearch-service] Unable to retrieve version information from Elasticsearch nodes.
server    log   [14:07:05.720] [warning][data][elasticsearch] Unable to revive connection: https://localhost:9200/
server    log   [14:07:05.720] [warning][data][elasticsearch] No living connections
Could not create APM Agent configuration: No Living connections

Any additional context: Kibana relies on the Node platform for TLS certificate validation. This problem was identified in nodejs/node#11771 and fixed in nodejs/node#22906. The fix is applied to Node version 13.3.0+ and 12.14.1+. However, Kibana currently uses Node 10.19.x.

@jportner jportner added bug Fixes for quality problems that affect the customer experience triaged Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! labels Feb 6, 2020
@jportner jportner self-assigned this Feb 6, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-security (Team:Security)

@jportner
Copy link
Contributor Author

jportner commented Feb 6, 2020

This will be fixed when #47968 is closed.

@jportner
Copy link
Contributor Author

jportner commented Dec 2, 2020

I manually tested and verified this is fixed now that we have upgraded to Node 12, which will be released in Kibana v7.11!

@jportner jportner closed this as completed Dec 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Projects
None yet
Development

No branches or pull requests

2 participants