That error could be thrown if the file does not have OS level permissions that 
allow the user running NiFi to read it. I’m a little surprised there is no 
nifi-app.log file, as that gets written to as soon as the application starts 
up. If you are able to configure a processor or controller service through the 
API / UI, that file should exist.

Can you provide the contents of your $NIFI_HOME/conf/logback.xml file and a 
directory listing of $NIFI_HOME/logs?


Andy LoPresto
[email protected]
[email protected]
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Dec 8, 2017, at 2:11 PM, Eric Chaves <[email protected]> wrote:
> 
> Hi Andy,
> 
> The log from bulletin board is:
> 
> PostHTTP[id=3253a78a-0160-1000-b7cf-6d7878f13efa] Unable to communicate with 
> destination https://mandrillapp.com/api/1.0/messages/send.json 
> <https://mandrillapp.com/api/1.0/messages/send.json> to determine whether or 
> not it can accept flowfiles/gzip; routing 
> StandardFlowFileRecord[uuid=cffc2f1d-97cb-423f-9296-5e796fd49a99,claim=StandardContentClaim
>  [resourceClaim=StandardResourceClaim[id=1512770613805-1, container=default, 
> section=1], offset=15244, length=2260],offset=0,name=emails 
> sample.csv,size=2260] to failure due to javax.net.ssl.SSLException: 
> java.lang.RuntimeException: Unexpected error: 
> java.security.InvalidAlgorithmParameterException: the trustAnchors parameter 
> must be non-empty: java.lang.RuntimeException: Unexpected error: 
> java.security.InvalidAlgorithmParameterException: the trustAnchors parameter 
> must be non-empty
> 
> For some reason that I couldn't investigate yet my current nifi setup is not 
> generating the nifi-app.log.
> 
> Googling the error message the reason would be lacking of a truststore file 
> but I have the exported file in place so I really dont know where else to 
> look.
> 
> Do you have any idea?
> 
> Regards,
> 
> Eric
> 
> 2017-12-08 19:31 GMT-02:00 Andy LoPresto <[email protected] 
> <mailto:[email protected]>>:
> Hi Eric,
> 
> The truststore is a collection of trusted public key certificates. As you 
> noted, the /etc/ssl/ directory contains pre-loaded CA certificates to be used 
> for this. You can also use the JVM cacerts file, which is already in JKS 
> format.
> 
> If this isn’t sufficient, can you provide an error from the log or a further 
> description of the issue you’re encountering? Thanks.
> 
> Andy LoPresto
> [email protected] <mailto:[email protected]>
> [email protected] <mailto:[email protected]>
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> 
>> On Dec 8, 2017, at 10:21 AM, Eric Chaves <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> Hi,
>> 
>> I'd like to make an HTTPS request to an internet public service but I'm 
>> failing to to setup the SSL Context Service. I tried to export my system 
>> certs to be used as truststore.
>> 
>> openssl pkcs12 -export -nokeys -in /etc/ssl/certs/ca-certificates.crt -out 
>> ./assets/truststore.p12
>> 
>> Can someone help me out with a step-by-step?
>> 
>> Thanks
> 
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to