[
https://issues.apache.org/jira/browse/NIFI-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-3788:
--------------------------------
Description:
Some users have reported issues when attempting to connect to an external
service which is secured for TLS via a wildcard certificate (i.e. hostname is
{{https://example.domain.com}} and the certificate DN contains
{{CN=*.domain.com}} when **using the Amazon Web Services (AWS S3) processors**.
-This requires changes in the {{SSLStandardContextService}} to correctly parse
the CN and evaluate wildcard entries if present- This required changes in the
{{DefaultHostnameVerifier}} instance being passed to the
{{SdkTLSSocketFactory}} and {{AmazonHTTPClientConfig}} in
{{AbstractAWSProcessor}}.
In addition, as specified by [RFC 2818|https://tools.ietf.org/html/rfc2818],
certificate evaluation (specifically hostname validation) should prioritize
Subject Alternative Names over DN parsing. Chrome 58+ has begun to implement
this prioritization, which can cause issues with certificate validation even if
the CN matches the hostname but SANs are present but do not include the
hostname.
was:
Some users have reported issues when attempting to connect to an external
service which is secured for TLS via a wildcard certificate (i.e. hostname is
{{https://example.domain.com}} and the certificate DN contains
{{CN=*.domain.com}} **using the Amazon Web Services (AWS S3) processors**.
-This requires changes in the {{SSLStandardContextService}} to correctly parse
the CN and evaluate wildcard entries if present- This required changes in the
{{DefaultHostnameVerifier}} instance being passed to the
{{SdkTLSSocketFactory}} and {{AmazonHTTPClientConfig}} in
{{AbstractAWSProcessor}}.
In addition, as specified by [RFC 2818|https://tools.ietf.org/html/rfc2818],
certificate evaluation (specifically hostname validation) should prioritize
Subject Alternative Names over DN parsing. Chrome 58+ has begun to implement
this prioritization, which can cause issues with certificate validation even if
the CN matches the hostname but SANs are present but do not include the
hostname.
> Support wildcard certificates in SSLStandardContextService
> ----------------------------------------------------------
>
> Key: NIFI-3788
> URL: https://issues.apache.org/jira/browse/NIFI-3788
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Affects Versions: 1.1.1
> Reporter: Andy LoPresto
> Assignee: Andy LoPresto
> Labels: certificate, pki, security, tls
> Fix For: 1.2.0
>
>
> Some users have reported issues when attempting to connect to an external
> service which is secured for TLS via a wildcard certificate (i.e. hostname is
> {{https://example.domain.com}} and the certificate DN contains
> {{CN=*.domain.com}} when **using the Amazon Web Services (AWS S3)
> processors**. -This requires changes in the {{SSLStandardContextService}} to
> correctly parse the CN and evaluate wildcard entries if present- This
> required changes in the {{DefaultHostnameVerifier}} instance being passed to
> the {{SdkTLSSocketFactory}} and {{AmazonHTTPClientConfig}} in
> {{AbstractAWSProcessor}}.
> In addition, as specified by [RFC 2818|https://tools.ietf.org/html/rfc2818],
> certificate evaluation (specifically hostname validation) should prioritize
> Subject Alternative Names over DN parsing. Chrome 58+ has begun to implement
> this prioritization, which can cause issues with certificate validation even
> if the CN matches the hostname but SANs are present but do not include the
> hostname.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
