Support Questions

Find answers, ask questions, and share your expertise

java.security.cert.CertificateException: No subject alternative names present

New Contributor

I am seeing the below error when I am enabling SSL for the first time in cloudera manager. Cloudera Management servcies fail to start with below error:

 

Failed to publish event: SimpleEvent{attributes={ROLE_TYPE=[EVENTSERVER], EXCEPTION_TYPES=[javax.net.ssl.SSLHandshakeException, java.security.cert.CertificateException], HOST_IDS=[xxx], STACKTRACE=[javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names present

.

.

No descriptor fetched from https://<ip>:7183 on after 1 tries, sleeping for 2 secs

No descriptor fetched from https://<ip>:7183 on after 2 tries, sleeping for 2 secs

No descriptor fetched from https://<ip>:7183 on after 3 tries, sleeping for 2 secs

No descriptor fetched from https://<ip>:7183 on after 4 tries, sleeping for 2 secs

No descriptor fetched from https://<ip>:7183 on after 5 tries, sleeping for 2 secs

Could not fetch descriptor after 5 tries, exiting.

 

What could the problem be here ?

2 REPLIES 2

Master Guru
The reason for that message is that the certs only publish the hostname
they can authenticate as, but when you connect by an IP then there's no
entry in the cert (such as a Subject Alternative Name field) that matches
the IP. The solution for this isn't to add the IP to the SAN field though,
the problem is instead this: You shouldn't even be seeing the IP being used
to connect to the CM in the MGMT services as your log currently indicates.

Run the Host Inspector (CM -> Hosts -> All Hosts -> Inspect All Hosts
button). Does it fully pass on its DNS forward and reverse lookup tests
across all hosts? Without that TLS or even Kerberos is not expected to
work. Network/OS requirements for clusters is covered here:
https://www.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html#cdh_...

New Contributor

Thank you Harsha for the clarification.

 

The servers do not have an FQDN configured. We just have hostnames. Can we continue with SSL with just these? Or do we need to have FQDN mandatorily for SSL.

 

Note: We are trying to configure Self-signed SSL.