I have created a scripted input and deployed it from the deployment server to the universal forwarder, but it's giving me the following error:
ERROR ExecProcessor - message from "/opt/splunk/etc/apps/tmdb/bin/tmdb.sh" curl: (77) Problem with the SSL CA cert (path? access rights
i gave all permissions to these files and folders, but was unable to resolve the issue:
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pempwd
/etc/pki/CA/certs
/etc/pki/CA/cri
I have my clusters on GCP (Google Cloud Platform).
Could someone please help me to resolve this?
Hello @shashi12345678 ,
the description of the error 77 could be misleading, read it as "curl cannot read the CA cert and it doesn't know what could went wrong. May be a wrong path? May be access right? May be something else?"
man 1 curl mentions: "77 Problem with reading the SSL CA cert (path? access rights?)."
Try to run the curl command with -vvvv switch, this can reveal some certificate related problems.
If it didn't help to find a culprit, a temporary workaround is to add a -k switch to the curl command:
-k, --insecure
(SSL) This option explicitly allows curl to perform "insecure" SSL connections
and transfers. All SSL connections are attempted to be made secure by using the
CA certificate bundle installed by default. This makes all connections consid‐
ered "insecure" fail unless -k, --insecure is used.
additonally you can save a trace for an analisys by using --trace-ascii /tmp/trace.txt:
--trace-ascii <file>
Enables a full trace dump of all incoming and outgoing data, including descrip‐
tive information, to the given output file. Use "-" as filename to have the out‐
put sent to stdout.
This is very similar to --trace, but leaves out the hex part and only shows the
ASCII part of the dump. It makes smaller output that might be easier to read for
untrained humans.
Access/Rights problems can be checked with a strace command (prepend your curl command with "strace -e open" and grep for "denied" string in the output).
If it doesn't help you can post the full curl command incl all switches (mask private data).
Hello @shashi12345678 ,
the description of the error 77 could be misleading, read it as "curl cannot read the CA cert and it doesn't know what could went wrong. May be a wrong path? May be access right? May be something else?"
man 1 curl mentions: "77 Problem with reading the SSL CA cert (path? access rights?)."
Try to run the curl command with -vvvv switch, this can reveal some certificate related problems.
If it didn't help to find a culprit, a temporary workaround is to add a -k switch to the curl command:
-k, --insecure
(SSL) This option explicitly allows curl to perform "insecure" SSL connections
and transfers. All SSL connections are attempted to be made secure by using the
CA certificate bundle installed by default. This makes all connections consid‐
ered "insecure" fail unless -k, --insecure is used.
additonally you can save a trace for an analisys by using --trace-ascii /tmp/trace.txt:
--trace-ascii <file>
Enables a full trace dump of all incoming and outgoing data, including descrip‐
tive information, to the given output file. Use "-" as filename to have the out‐
put sent to stdout.
This is very similar to --trace, but leaves out the hex part and only shows the
ASCII part of the dump. It makes smaller output that might be easier to read for
untrained humans.
Access/Rights problems can be checked with a strace command (prepend your curl command with "strace -e open" and grep for "denied" string in the output).
If it doesn't help you can post the full curl command incl all switches (mask private data).
@PavelP Thanks, It worked by using --insecure.