[ 
https://issues.apache.org/jira/browse/NIFI-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545455#comment-16545455
 ] 

Andy LoPresto commented on NIFI-5370:
-------------------------------------

[~prashanv] yes, there are multiple ways to avoid/correct the behavior you are 
seeing here. The error appears because the certificate authority (CA) you are 
using to sign one set of certs is not the same as the one that signs the next 
set. The toolkit generates a truststore which contains that CA to allow for 
cross-node verification. In order for all nodes (added at different times) to 
verify each other, they must have all the CAs used in every truststore -- this 
can be accomplished by  signing all certs with the same CA, or adding multiple 
CAs to the same truststore. 

1. Run the TLS toolkit from the same directory and use the same output 
directory. On the first run, the TLS toolkit will create a CA if one is not 
present, and store the public key in {{nifi-cert.pem}} and the private key in 
{{nifi-key.key}}. On subsequent runs, the toolkit will detect that a CA is 
present and use it to sign the additional certs. 
1. Run the TLS toolkit in an arbitrary location, and import the newly-generated 
{{nifi-cert.pem}} into the already existing {{truststore.jks}} deployed on the 
existing nodes. You will also need to import the original {{nifi-cert.pem}} 
into the *new* {{truststore.jks}} for the new node. 
1. Run the TLS toolkit in *server* mode on an instance, and have the other 
nodes connect using *client* mode to receive their certificates. These certs 
will all be signed by the same CA, and new nodes can come online and have certs 
generated whenever you like. The *server* component runs indefinitely. 

More details on all of this are available in the [Admin 
Guide|https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#tls-generation-toolkit].
 If you have further questions, I would recommend asking on the 
*us...@nifi.apache.org* mailing list, as this issue is closed and community 
members are unlikely to see future comments here. 

> Cluster request replication failing with wildcard certs
> -------------------------------------------------------
>
>                 Key: NIFI-5370
>                 URL: https://issues.apache.org/jira/browse/NIFI-5370
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Core Framework
>    Affects Versions: 1.7.0
>            Reporter: Andy LoPresto
>            Assignee: Andy LoPresto
>            Priority: Major
>              Labels: certificate, cluster, security, tls, wildcard
>             Fix For: 1.8.0, 1.7.1
>
>
> From the users mailing list:
> {quote}
> Team,
>  
> NiFi secured cluster throws below error with wildcarded self-signed 
> standalone certificate.  Just a brief background, we are deploying nifi in 
> Kubernetes  where we have to use wildcarded certificates. Till nifi 1.6.0, it 
> was working fine.
> Also I tried bringing up NiFi in linux VM in secured cluster mode with 
> wildcarded certs, I am getting same error.
>  
> Toolkit command to generate certs:
> bin/tls-toolkit.sh standalone -n 
> '*.mynifi-nifi-headless.default.svc.cluster.local’ -C 'CN=admin, OU=NIFI' -o 
> <targetfolder>
>  
> Logs:
> 2018-07-02 12:40:32,369 WARN [Replicate Request Thread-1] 
> o.a.n.c.c.h.r.ThreadPoolRequestReplicator Failed to replicate request GET 
> /nifi-api/flow/current-user to 
> mynifi-nifi-1.mynifi-nifi-headless.default.svc.cluster.local:8443 due to 
> javax.net.ssl.SSLPeerUnverifiedException: Hostname 
> mynifi-nifi-1.mynifi-nifi-headless.default.svc.cluster.local not verified:
>     certificate: sha256/########################################
>     DN: CN=*.mynifi-nifi-headless.default.svc.cluster.local, OU=NIFI
>     subjectAltNames: [*.mynifi-nifi-headless.default.svc.cluster.local]
> 2018-07-02 12:40:32,370 WARN [Replicate Request Thread-1] 
> o.a.n.c.c.h.r.ThreadPoolRequestReplicator
> javax.net.ssl.SSLPeerUnverifiedException: Hostname 
> mynifi-nifi-1.mynifi-nifi-headless.default.svc.cluster.local not verified:
>     certificate: sha256/########################################
>     DN: CN=*.mynifi-nifi-headless.default.svc.cluster.local, OU=NIFI
>     subjectAltNames: [*.mynifi-nifi-headless.default.svc.cluster.local]
>         at 
> okhttp3.internal.connection.RealConnection.connectTls(RealConnection.java:316)
>  
> Please help me in resolving this.
>  
> Note: Same certificates is working for single mode setup.
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to