You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Jeff Storck (JIRA)" <ji...@apache.org> on 2019/04/03 00:06:00 UTC
[jira] [Created] (NIFI-6178) Certificates generated for "localhost"
need to have IP as a SAN in Java 11
Jeff Storck created NIFI-6178:
---------------------------------
Summary: Certificates generated for "localhost" need to have IP as a SAN in Java 11
Key: NIFI-6178
URL: https://issues.apache.org/jira/browse/NIFI-6178
Project: Apache NiFi
Issue Type: Bug
Components: Security, Tools and Build
Affects Versions: 1.9.1
Reporter: Jeff Storck
Assignee: Jeff Storck
While running tests in {{nifi-standard-processors}} with JDK 11, several tests failed with the following error after enabling {{javax.net.debug=ssl,handshake}}:
{code:java}
javax.net.ssl|ERROR|1B|ListenHTTP (07d9bfd1-56c3-46f1-b4a7-570eaf13c7cc) Web Server-27|2019-04-02 17:44:57.177 EDT|TransportContext.java:313|Fatal (CERTIFICATE_UNKNOWN): No subject alternative names matching IP address 127.0.0.1 found (
"throwable" : {
java.security.cert.CertificateException: No subject alternative names matching IP address 127.0.0.1 found
{code}
It appears that when using a cert for {{localhost}} the hostname is resolved to 127.0.0.1, after which the existing SANs in the cert are checked for a matching IP SAN.
The TLS Toolkit currently generates certs with SANs assumed to be domain names ([TlsHelper.java:305|https://github.com/apache/nifi/blob/master/nifi-toolkit/nifi-toolkit-tls/src/main/java/org/apache/nifi/toolkit/tls/util/TlsHelper.java#L305], uses GeneralName.dNSName explicitly). Adding the IP as a SAN with the TLS Toolkit currently adds it as a DNS SAN, which does not resolve the issue.
Support must be added to allow IPs to be added as SANs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)