[NIFI-6178] Certificates generated for "localhost" need to have IP as a SAN in Java 11

• Type: Bug
• Status: Resolved
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 1.9.1
• Component/s: Security, Tools and Build
• Labels: Java11
• Assignee: Jeff Storck
• Reporter: Jeff Storck
• Created: 03/Apr/19 00:05
• Updated: 30/May/19 18:40
• Resolved: 30/May/19 18:40

Description

While running tests in nifi-standard-processors with Jetty 9.4.15.v20190215 (after attempting to update from Jetty 9.4.11.v20180605), several SSL tests failed.  After enabling javax.net.debug=ssl,handshake the following error occurs:

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

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, 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.

Issue Links

• blocks: NIFI-5176 NiFi needs to be buildable on Java 11
• relates to: NIFI-4247 TLS Toolkit should parse regex in SAN fields
• relates to: NIFI-5462 Refactor TLS Toolkit
• links to: GitHub Pull Request #3416