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)