You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nifi.apache.org by "Aldrin Piri (JIRA)" <ji...@apache.org> on 2015/11/13 18:34:11 UTC

[jira] [Updated] (NIFI-1163) GetHTTP throws an NPE if a context service is used with only a truststore and no keystore

     [ https://issues.apache.org/jira/browse/NIFI-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aldrin Piri updated NIFI-1163:
------------------------------
    Description: 
Consider a one-way SSL connection to an HTTPS endpoint.  We might want to specify a truststore to talk with that endpoint but not a keystore.

The problem stems from the following method: 

{code}
    private SSLContext createSSLContext(final SSLContextService service)
            throws KeyStoreException, IOException, NoSuchAlgorithmException, CertificateException, KeyManagementException, UnrecoverableKeyException {
        final KeyStore truststore = KeyStore.getInstance(service.getTrustStoreType());
        try (final InputStream in = new FileInputStream(new File(service.getTrustStoreFile()))) {
            truststore.load(in, service.getTrustStorePassword().toCharArray());
        }

        final KeyStore keystore = KeyStore.getInstance(service.getKeyStoreType());
        try (final InputStream in = new FileInputStream(new File(service.getKeyStoreFile()))) {
            keystore.load(in, service.getKeyStorePassword().toCharArray());
        }

        final SSLContext sslContext = SSLContexts.custom().loadTrustMaterial(truststore, new TrustSelfSignedStrategy()).loadKeyMaterial(keystore, service.getKeyStorePassword().toCharArray()).build();

        return sslContext;
    }
{code}

In this case there are no keystore properties causing this process to fail.

  was:
Consider a one-way SSL connection to an HTTPS endpoint.  We might want to specify a truststore to talk with that endpoint but not a keystore.

The problem stems from the following method: 

{code}
        final SSLContext sslContext = SSLContexts.custom().loadTrustMaterial(truststore, new TrustSelfSignedStrategy()).loadKeyMaterial(null, service.getKeyStorePassword().toCharArray()).build();
{code}

In this case there are no keystore properties causing this process to fail.


> GetHTTP throws an NPE if a context service is used with only a truststore and no keystore 
> ------------------------------------------------------------------------------------------
>
>                 Key: NIFI-1163
>                 URL: https://issues.apache.org/jira/browse/NIFI-1163
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Extensions
>    Affects Versions: 0.3.0
>            Reporter: Aldrin Piri
>            Assignee: Aldrin Piri
>
> Consider a one-way SSL connection to an HTTPS endpoint.  We might want to specify a truststore to talk with that endpoint but not a keystore.
> The problem stems from the following method: 
> {code}
>     private SSLContext createSSLContext(final SSLContextService service)
>             throws KeyStoreException, IOException, NoSuchAlgorithmException, CertificateException, KeyManagementException, UnrecoverableKeyException {
>         final KeyStore truststore = KeyStore.getInstance(service.getTrustStoreType());
>         try (final InputStream in = new FileInputStream(new File(service.getTrustStoreFile()))) {
>             truststore.load(in, service.getTrustStorePassword().toCharArray());
>         }
>         final KeyStore keystore = KeyStore.getInstance(service.getKeyStoreType());
>         try (final InputStream in = new FileInputStream(new File(service.getKeyStoreFile()))) {
>             keystore.load(in, service.getKeyStorePassword().toCharArray());
>         }
>         final SSLContext sslContext = SSLContexts.custom().loadTrustMaterial(truststore, new TrustSelfSignedStrategy()).loadKeyMaterial(keystore, service.getKeyStorePassword().toCharArray()).build();
>         return sslContext;
>     }
> {code}
> In this case there are no keystore properties causing this process to fail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)