javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching and org.bouncycastle.asn1.ASN1Exception: corrupted stream detected

Search Guard
1

Elasticsearch version:
7.7.0 with Search Guard 7.7.0-41.0.0

Server OS version:
CentOS 7.8.2003

Describe the issue:
A new machine tries to join the cluster and fails with:
org.elasticsearch.transport.ConnectTransportException: [<nodename>][127.0.0.1:9300] general node connection failure

On the master node, the logs contain:
java.security.cert.CertificateException: No subject alternative DNS name matching <fqdn> found.

I inspected the node certificate with sgtlsdiag.sh and this fails with error while reading elasticsearch-es-01.crt: org.bouncycastle.openssl.PEMException: problem parsing cert: org.bouncycastle.asn1.ASN1Exception: corrupted stream detected
For the master certificate information is displayed just fine. Also openssl x509 -in elasticsearch-es-01.crt -text -noout works just fine on both certificates

Provide configuration:
Configuration is managed by Puppet and identical on all nodes, except for the network.publish_host and node.name settings.

elasticsearch/config/elasticsearch.yml

### MANAGED BY PUPPET ###
---
cluster.name: <clustername>
discovery.zen.minimum_master_nodes: 2
discovery.zen.ping.unicast.hosts:
- <node1fqdn>:9300
- <node2fqdn>:9300
- <node3fqdn>:9300
network.bind_host: 0.0.0.0
network.publish_host: <node fqdn>
node.data: true
node.ingest: true
node.master: true
node.max_local_storage_nodes: 1
node.name: <node name>
path.data: "/var/lib/elasticsearch/es-01"
path.logs: "/var/log/elasticsearch/es-01"
searchguard.allow_default_init_sgindex: false
searchguard.audit.type: internal_elasticsearch
searchguard.authcz.admin_dn:
- <redacted>
searchguard.check_snapshot_restore_write_privileges: true
searchguard.enable_snapshot_restore_privilege: true
searchguard.enterprise_modules_enabled: false
searchguard.nodes_dn:
- CN=<redacted>*.lan,O=<redacted>
searchguard.restapi.roles_enabled:
- sg_all_access
searchguard.ssl.http.enable_openssl_if_available: true
searchguard.ssl.http.enabled: true
searchguard.ssl.http.pemcert_filepath: elasticsearch-es-01.crt
searchguard.ssl.http.pemkey_filepath: elasticsearch-es-01.key
searchguard.ssl.http.pemtrustedcas_filepath: ipa-ca.pem
searchguard.ssl.transport.enable_openssl_if_available: true
searchguard.ssl.transport.enforce_hostname_verification: true
searchguard.ssl.transport.pemcert_filepath: elasticsearch-es-01.crt
searchguard.ssl.transport.pemkey_filepath: elasticsearch-es-01.key
searchguard.ssl.transport.pemtrustedcas_filepath: ipa-ca.pem
searchguard.ssl.transport.resolve_hostname: true
xpack.license.self_generated.type: basic
xpack.ml.enabled: false
xpack.monitoring.enabled: true
xpack.security.enabled: false
xpack.watcher.enabled: false
2

It looks like the node hostnames in the TLS certificates are not resolved by DNS. And you configured Search Guard to check this explicitly. Make sure the hostnames are resolved or set the following option to false.

elasticsearch.yml

searchguard.ssl.transport.enforce_hostname_verification: true
1 Like
3

@srgbnd thank you for your fast reply! I used dig to perform a lookup on both machines and the right responses came back. Do you know how I can perform a DNS lookup which is very close to the one Search Guard performs?

What even more confuses me, I just rebooted the new machine (once again) and it joined the cluster without any problems.
Apparently the org.bouncycastle.asn1.ASN1Exception is not the root cause then.

4

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.