Bug 1026418 - Command passed as argument is not executed while accepting SSL certificate.
Summary: Command passed as argument is not executed while accepting SSL certificate.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: CLI
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: DR6
: EAP 6.3.0
Assignee: Darran Lofthouse
QA Contact: Petr Kremensky
Russell Dickenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-04 15:30 UTC by Petr Kremensky
Modified: 2014-06-28 15:28 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
When starting the JBoss EAP 6 CLI with a command being passed as an argument, if that server prompted the user to accept a server certificate, it logged that prompt as an error. This resulted in any command passed as an argument being skipped, as those commands are only executed if no errors have occurred. This issue was fixed by outputting the certificate acceptance prompt as normal output instead of as an error. As a result, a command as an argument when starting the CLI is successfully executed after the user has accepted the server's certificate.
Clone Of:
Environment:
Last Closed: 2014-06-28 15:28:09 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFLY-2538 0 Major Closed Certificate acceptance causing command entered on starting the CLI to be skipped. 2018-08-14 13:49:09 UTC
Red Hat Issue Tracker WFLY-2950 0 Major Closed jboss-cli using https-remoting: command not executed if certificate is unrecognised 2018-08-14 13:49:09 UTC

Description Petr Kremensky 2013-11-04 15:30:41 UTC 
Description of problem:
 Command passed as arguments to CLI is not executed once I choose to accept the SSL certificate only temporarily. 

Version-Release number of selected component (if applicable):
 EAP 6.2.0.ER7

How reproducible:
 Always

Steps to Reproduce:
 0. Navigate to JBOSS_HOME/bin.
 1. Create SSL certificate like: 
keytool -genkeypair -alias alias -keyalg RSA -keystore ssl-test.keystore -storepass password --dname "CN=jboss,OU=Engineering,O=redhat.com,L=Brno,C=CZ"
 2. Start standalone server.
 3. Secure ManagementRealm with SSL: 
./jboss-cli.sh -c command="/core-service=management/security-realm=ManagementRealm/server-identity=ssl:add(keystore-path=ssl-test.keystore,keystore-password="password")"
 4. Restart server
 5. Stop the server using non-interactive CLI mode, accept the certificate only temporarily.
./jboss-cli.sh -c shutdown
Accept certificate? [N]o, [T]emporarily, [P]ermenantly : T

Actual results:
 CLI command is not executed.

Expected results:
 CLI command is executed.

Additional info:
 Even if I accept the certificate permanently the first command is not executed (step 5). After accepting the certificate, one must call the command again to shutdown the server.
Comment 1 Darran Lofthouse 2013-11-19 14:13:04 UTC 
Assigning to me as I am currently working on improving the certificate acceptance logic upstream.
Comment 2 JBoss JIRA Server 2013-11-19 19:28:47 UTC 
Darran Lofthouse <darran.lofthouse> made a comment on jira WFLY-2538

Additional testing and this does not seem to be restricted to the certificate acceptance prompt, if the user is required to authenticate and provide a username and password the same behaviour is observed.
Comment 3 JBoss JIRA Server 2013-11-19 19:40:49 UTC 
Darran Lofthouse <darran.lofthouse> made a comment on jira WFLY-2538

-Additional testing and this does not seem to be restricted to the certificate acceptance prompt, if the user is required to authenticate and provide a username and password the same behaviour is observed.-

Ignore this comment, further testing does appear to be specific to certificate acceptance.
Comment 4 JBoss JIRA Server 2013-11-21 18:00:46 UTC 
Darran Lofthouse <darran.lofthouse> updated the status of jira WFLY-2538 to Coding In Progress
Comment 5 Darran Lofthouse 2014-02-11 12:37:24 UTC 
Adding devel_ack as the upstream issue is resolved so should be a trivial backport.
Comment 8 Petr Kremensky 2014-03-31 07:06:30 UTC 
Verified on EAP 6.3.0.DR6.
Note You need to log in before you can comment on or make changes to this bug.