I suspect you have not completed a step, or missing something.  The cacerts works for me in all cases if the cert is publicly trusted (standard public cert from public CA) which it should be.    You should share info on the configurations you tried and what if any errors you got from that.  The bare minimum settings you need for that are keystore (file location), password, key type (jks), and TLS version.   Assuming you copied your java cacert file to all nodes as /nifi/ssl/cacerts the controller service properties should look like:       If cacerts doesnt work, then you must create keystores and/or trust stores with the public cert.   Use the openssl command to get the cert.  That command looks like:   openssl s_client -connect https://secure.domain.com   You can also get it from the browser when you visit the elk interface; for example cluster health, or indexes.   Double click cert lock icon in the browser then use the browser's interface to see/view/download public certificate.  You need the .cer or .crt file.   Then you use the cert to create the keystore with keytool commands.  An example is:   keytool -import -trustcacerts -alias ambari -file cert.cer -keystore keystore.jks   Once you have created a keystore/truststore file you need to copy it to all nifi nodes, ensure the correct ownership, and make sure all the details are correct in the SSL Context Service.  Lastly you may need to modify the TLS type until testing works.   Here is working example of getting the cert and using it with keytool from a recent use case:   echo -n|openssl s_client -connect https://secure.domain.com | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > publiccert.crt keytool -import -file publiccert.crt -alias astra -keystore keyStore.jks -storepass password -noprompt  keytool -import -file publiccert.crt -alias astra -keystore trustStore.jks -storepass password -noprompt  mkdir -p /etc/nifi/ssl/ cp *.jks /etc/nifi/ssl chown -R nifi:nifi /etc/nifi/ssl/     ... View more

@Gubbi    The solution you are looking for is ConvertRecord + ParquetRecordReader + CSVRecordWriter.  The ParquetRecordReader is included in NiFi 1.10 and up.  If you have an older nifi, here is a post where I talk about adding the required jar files to nifi 1.9 (older version doesn't have parquet):   https://community.cloudera.com/t5/Support-Questions/Can-I-put-the-NiFi-1-10-Parquet-Record-Reader-in-NiFi-1-9/td-p/286465   Another suggestion: If you are working with nifi and hadoop/hdfs/hive,  you could store the raw parquet, create external hive table on parquet, then select results and insert them into similar table of csv format.  Then you select the csv table results and create csv file.      Also in order to validate/inspect your parquet, or to read the schema (if you need it for controller services) you use parquet tools:   https://community.cloudera.com/t5/Community-Articles/Build-and-use-Parquet-tools-to-read-parquet-files/ta-p/248629     If this answer resolves your issue or allows you to move forward, please choose to ACCEPT this solution and close this topic. If you have further dialogue on this topic please comment here or feel free to private message me. If you have new questions related to your Use Case please create separate topic and feel free to tag me in your post.     Thanks, Steven @ DFHZ ... View more

I think the most straight forward would be to drop the infer schema into your version of NiFi.   The procedure is not that hard, you just have to be surgically careful.  The process is explained a bit here in reference to adding parquet jars from new version, into older version.   Be sure to read all the comments:   https://community.cloudera.com/t5/Support-Questions/Can-I-put-the-NiFi-1-10-Parquet-Record-Reader-in-NiFi-1-9/td-p/286465   ... View more

@mike_bronson7  oddly enough, the top post recommendations is this same question you asked 2 years ago:   https://community.cloudera.com/t5/Support-Questions/how-to-change-hostnames-on-all-machines-in-ambari-cluster/m-p/217984#M179885   To confirm, the hostname and the domain name are one in the same.  The "domain.com" is just part of the hostname.  The first part is the subdomain.  So the procedure to change "domain.com" is the same as subdomain.    HOWEVER,  I would highly recommend testing this in a dev cluster before production, especially if you have ssl/kerberos.   This is a major change that affects ambari and all components.  If the ambari command agains the new json mapping fails, or there is any incomplete action within any agent/component,  you are going to bomb the whole cluster.     If this answer resolves your issue or allows you to move forward, please choose to ACCEPT this solution and close this topic. If you have further dialogue on this topic please comment here or feel free to private message me. If you have new questions related to your Use Case please create separate topic and feel free to tag me in your post.     Thanks, Steven @ DFHZ ... View more