Andy LoPresto created NIFI-4222:
-----------------------------------
Summary: TLS Toolkit should provide SAN by default
Key: NIFI-4222
URL: https://issues.apache.org/jira/browse/NIFI-4222
Project: Apache NiFi
Issue Type: Improvement
Components: Tools and Build
Affects Versions: 1.3.0
Reporter: Andy LoPresto
As of Chrome 58, the browser will only use the *SubjectAlternativeName* entries
to determine hostname verification, rather than the *CN*. This is specified in
RFC 6215 [1], TLS hostname verification must attempt to use the SAN entries
first and may only use the CN entry if no SAN entries are available.
Chrome takes this a step further [2]:
{quote}
During Transport Layer Security (TLS) connections, Chrome browser checks to
make sure the connection to the site is using a valid, trusted server
certificate.
For Chrome 58 and later, only the subjectAlternativeName extension, not
commonName, is used to match the domain name and site certificate. The
certificate subject alternative name can be a domain name or IP address. If the
certificate doesn’t have the correct subjectAlternativeName extension, users
get a NET::ERR_CERT_COMMON_NAME_INVALID error letting them know that the
connection isn’t private. If the certificate is missing a
subjectAlternativeName extension, users see a warning in the Security panel in
Chrome DevTools that lets them know the subject alternative name is missing.
{quote}
As this will cause issues for users who do not manually provide a SAN when
generating their certificates using the TLS Toolkit, the toolkit should be
modified to automatically include the provided CN as a SAN entry, in addition
to any manually-provided SAN entries.
[1] https://tools.ietf.org/html/rfc6125#section-6.4.4
[2] https://support.google.com/chrome/a/answer/7391219?hl=en
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
