[ 
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}} 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. 


> 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)

Reply via email to