Closed jammie96 closed 1 year ago
rsenden
commented
1 year ago Hi, thanks for reporting this issue. Can you please share which fcli version you are using, and whether you're using the Java version or native binary?
Any chance you can try with the Java version of fcli without configuring the trust store in fcli (in which case, the Java version will use the standard Java trust store)?
jammie96
commented
1 year ago Hi, I am using fcli version 1.3.2, pulled from the latest release from the docker hub website and uses the native binary version.
Since there exists the docker version of fortify, it makes more sense to just use that image.
rsenden
commented
1 year ago Are you planning to use fcli interactively or for CI/CD integration? The fortify-ci-tools image is meant for the latter and contains some other CI/CD-related software, so may be overkill if you just want to use fcli.
It would still be good if you can test with a local fcli installation; both the .jar version and native binary if possible to get a better understanding of why you're seeing this behavior.
With the .jar version, if you don't explicitly configure a trust store through the fcli config commands, it will use the standard Java truststore. So, if this fails after adding your certificate to the standard java trust store, the problem is likely not fcli-related but possibly an issue with the certificate.
If the above succeeds, then you can try explicitly configuring the trust store through the fcli config commands on the .jar version of fcli. If this fails, it may be a generic fcli issue that we can investigate further.
If the above succeeds, you can try the same with a locally installed native fcli binary. If this fails, we'll need to investigate why the native binary behaves different from the .jar version. Especially in situations like these where low-level Java features are being used, we may need to make some changes to have both native binaries and .jar version behave the same.
If the above succeeds, it's likely a Docker-related issue. Both Java trust store and fcli configuration are local to a container instance, so you'll need to run keytool, fcli config and subsequent fcli ssc commands all in the same container instance. If you run the keytool and/or fcli config commands in one container instance and then run the fcli ssc commands in another container instance, the fcli ssc commands won't see the updated trust store and/or fcli trust store configuration.
If you want to persist the Java trust store and/or fcli configuration, you'll either need to use volume mappings to store this data on a local or persistent volume, or build a custom image that's based on fortify-ci-tools and contains RUN-commands to do the necessary Java trust store and fcli configuration.
jammie96
commented
1 year ago Hi yes i am planning to use fcli for CI/CD integration. Thanks for the suggesting to use the .jar version and i have found out another issue regarding that.
I believe the cert issue is now resolved. However connection still can’t be established when using a valid user / password. I am able to see a result through CURL through.
root@ff8210b54957:/# curl -k https://****.***/ssc/
<!doctype html>
<html>
<head>
<meta charset="utf-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"/>
<base href="/ssc/html/login/">
<!--[if IE]><script type="text/javascript">
// Fix for IE ignoring relative base tags.
// See http://stackoverflow.com/questions/3926197/html-base-tag-and-local-folder-path-with-internet-explorer
(function() {
var baseTag = document.getElementsByTagName('base')[0];
baseTag.href = baseTag.href;
})();
</script><![endif]-->
<link rel="shortcut icon" type="image/png" href="/ssc/images/favicon.ico"/>
root@ff8210b54957:/# fcli ssc session login --url= https://****.***/ssc/' -u='ssc_user' -p
Enter value for --password (SSC password):
kong.unirest.UnirestException: org.apache.http.conn.ConnectTimeoutException: Connect to ****.*** [****.***] failed: connect timed out
at com.fortify.cli.common.rest.runner.config.UnirestUnexpectedHttpResponseConfigurer$UnexpectedHttpResponseInterceptor.onFail(UnirestUnexpectedHttpResponseConfigurer.java:54)
at kong.unirest.CompoundInterceptor.lambda$onFail$2(CompoundInterceptor.java:54)
at [java.base@11.0.18/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)](mailto:java.base@11.0.18/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195))
at [java.base@11.0.18/java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1632)](mailto:java.base@11.0.18/java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1632))
at [java.base@11.0.18/java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:127)](mailto:java.base@11.0.18/java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:127))
at [java.base@11.0.18/java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:502)](mailto:java.base@11.0.18/java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:502))
at [java.base@11.0.18/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:488)](mailto:java.base@11.0.18/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:488))
at [java.base@11.0.18/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)](mailto:java.base@11.0.18/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474))
at [java.base@11.0.18/java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:150)](mailto:java.base@11.0.18/java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:150))
at [java.base@11.0.18/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)](mailto:java.base@11.0.18/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234))
at [java.base@11.0.18/java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:543)](mailto:java.base@11.0.18/java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:543))
at kong.unirest.CompoundInterceptor.onFail(CompoundInterceptor.java:56)
at kong.unirest.apache.ApacheClient.request(ApacheClient.java:138)
at kong.unirest.Client.request(Client.java:57)
at kong.unirest.BaseRequest.request(BaseRequest.java:359)
at kong.unirest.BaseRequest.asObject(BaseRequest.java:260)
at com.fortify.cli.ssc.token.helper.SSCTokenHelper.createToken(SSCTokenHelper.java:119)
at com.fortify.cli.ssc.token.helper.SSCTokenHelper.lambda$createToken$4(SSCTokenHelper.java:72)
at com.fortify.cli.common.rest.runner.GenericUnirestRunner.run(GenericUnirestRunner.java:40)
at com.fortify.cli.ssc.token.helper.SSCTokenHelper.createToken(SSCTokenHelper.java:72)
at com.fortify.cli.ssc.session.manager.SSCSessionData.generateToken(SSCSessionData.java:99)
at com.fortify.cli.ssc.session.manager.SSCSessionData.<init>(SSCSessionData.java:55)
at com.fortify.cli.ssc.session.cli.cmd.SSCSessionLoginCommand.login(SSCSessionLoginCommand.java:56)
at com.fortify.cli.ssc.session.cli.cmd.SSCSessionLoginCommand.login(SSCSessionLoginCommand.java:41)
at com.fortify.cli.common.session.cli.cmd.AbstractSessionLoginCommand.getJsonNode(AbstractSessionLoginCommand.java:53)
at com.fortify.cli.common.output.cli.cmd.basic.AbstractBasicOutputCommand.run(AbstractBasicOutputCommand.java:39)
at picocli.CommandLine.executeUserObject(CommandLine.java:2026)
at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2461)
at picocli.CommandLine$RunLast.handle(CommandLine.java:2453)
at picocli.CommandLine$RunLast.handle(CommandLine.java:2415)
at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2273)
at picocli.CommandLine$RunLast.execute(CommandLine.java:2417)
at picocli.CommandLine.execute(CommandLine.java:2170)
at com.fortify.cli.app.FortifyCLI.execute(FortifyCLI.java:83)
at com.fortify.cli.app.FortifyCLI.main(FortifyCLI.java:62)
Caused by: org.apache.http.conn.ConnectTimeoutException: Connect to ****.*** [****.***] failed: connect timed out
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:151)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376)
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:118)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
at kong.unirest.apache.ApacheClient.request(ApacheClient.java:129)
... 22 more
Caused by: java.net.SocketTimeoutException: connect timed out
at org.graalvm.nativeimage.builder/com.oracle.svm.core.jni.functions.JNIFunctions$NewObjectWithObjectArrayArgFunctionPointer.invoke(JNIFunctions.java)
at org.graalvm.nativeimage.builder/com.oracle.svm.core.jni.functions.JNIFunctions.ThrowNew(JNIFunctions.java:882)
at [java.base@11.0.18/java.net.PlainSocketImpl.socketConnect(PlainSocketImpl.java)](mailto:java.base@11.0.18/java.net.PlainSocketImpl.socketConnect(PlainSocketImpl.java))
at [java.base@11.0.18/java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:412)](mailto:java.base@11.0.18/java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:412))
at [java.base@11.0.18/java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:255)](mailto:java.base@11.0.18/java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:255))
at [java.base@11.0.18/java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:237)](mailto:java.base@11.0.18/java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:237))
at [java.base@11.0.18/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)](mailto:java.base@11.0.18/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392))
at [java.base@11.0.18/java.net.Socket.connect(Socket.java:609)](mailto:java.base@11.0.18/java.net.Socket.connect(Socket.java:609))
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:368)
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)To add on, no errors were prompted when username is not provided, or using a token.
root@ff8210b54957:/# fcli ssc session login --url='https://****.***/ssc/'
Name Type Url Created Expired Action
default SSC https://****.***/ssc/ 2023-10-26 09:37:19 UTC Unknown CREATEDWhat other suggestions can be done? I have censored the address for confidentiality issue. I really appreciate your help thus far and hopefully there would be a resolution regarding this issue.
rsenden
commented
1 year ago Hi, good to hear that the certificate issues now seem to be resolved.
To start with, we've released fcli 2.0.0 yesterday, so I'd recommend to upgrade to this latest version to benefit from the latest features and fixes. Note that many fcli commands have been renamed or moved, so you may need to update your fcli invocations accordingly.
The stack trace shows a connection timeout, so either your SSC instance is not accessible from the system from where you're running fcli, or it takes too long to connect to and/or receive data from your SSC instance. The fcli ssc session login command in the fcli 2.0.0 release provides new --connect-timeout and --socket-timeout options to handle the latter.
If that doesn't help, you'll need to check your connectivity. Are you running the curl command from the same system/container as the fcli commands? Maybe there's a firewall blocking the requests, maybe there's a networking component that blocks requests to the SSC API endpoints while allowing access to the HTML interface (allowing curl to successfully load SSC HTML pages but preventing fcli from connecting to API endpoints), maybe you need to configure a proxy server using the fcli config proxy commands, maybe it's a Docker networking issue (if you're still running this from the Docker container), ...
As for your 'add on' comment, the fcli ssc session login command should require either username/password or token to be specified,. If you don't see an error messages stating that required options are missing if you omitted all of these, that should be considered an fcli bug. Again, potentially this has already been fixed in fcli 2.0.0.
Note that the fcli ssc session login command only connects to SSC when username/password are provided. When logging in with a token, the login command doesn't connect to SSC (there's no generic SSC API endpoint that can be invoked by all token types). So, when authenticating with a token, you won't see any connection issues until you run another fcli command that actually connects to SSC.
jammie96
commented
1 year ago Hi, just to update. I have solved this cacert issue and this can be closed.
Found out that the issue lies with docker ubuntu mounting settings and require cacert mounting to the docker ubuntu's fcli.
Thanks for your solutions! Really appreciated that!
For some reason I am unable to configure the self-signed cert on SSC into JAVA keystore (/opt/java/openjdk/lib/security/cacerts). I have used these commands to import, set and have logged in to fcli ssc:
The above mport the self-signed cert on SSC into JAVA keystore (/opt/java/openjdk/lib/security/cacerts)
The above which sets keystore into FCLI.
I have then logged in using an auth token and used this command:
Which in the end gives this error:
Am i missing any step? Any further help would be grateful. Thank you
Update: Apologies for accidentally closing and reopening this issue.