glassfish
  1. glassfish
  2. GLASSFISH-20994

communication between DAS and instance fails if master password != changeit

    Details

    • Type: Bug Bug
    • Status: In Progress
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 4.1
    • Fix Version/s: None
    • Component/s: admin
    • Labels:
      None

      Description

      if GlassFish is started using --passswordfile command line option, GF should take passwords provided in this file instead of defaults.

      1. create a domain with one DAS, clusters and instances
      2. start instances, the config is retrieved from DAS
      3. open admin gui and change something, push to instance fails with
      javax.net.ssl.SSLException: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.IllegalArgumentException

      root cause is com.sun.enterprise.security.store.AsadminSecurityUtil#defaultMasterPassword()
      it checks an undocumented system property or falls back to 'changeit' (see stack trace below)

      if the system property is provided as jvm-option then the communcation works. however, providing passwords at several places (--passwordfile and jvm-option) is error prone and bad practice...

      	AsadminSecurityUtil.defaultMasterPassword() line: 269	
      	AsadminSecurityUtil.chooseMasterPassword(char[]) line: 252	
      	AsadminSecurityUtil.init(char[], boolean) line: 170	
      	AsadminSecurityUtil.<init>(char[], boolean) line: 135	
      	AsadminSecurityUtil.getInstance(char[], boolean) line: 84	
      	AsadminSecurityUtil.getInstance(boolean) line: 96	
      	AsadminTruststore.newInstance() line: 84	
      	AsadminTrustManager.checkCertificate(X509Certificate[]) line: 209	
      	AsadminTrustManager.checkServerTrusted(X509Certificate[], String) line: 136	
      	AbstractTrustManagerWrapper.checkServerTrusted(X509Certificate[], String, Socket) line: 813	
      	ClientHandshaker.serverCertificate(HandshakeMessage$CertificateMsg) line: 1323	
      	ClientHandshaker.processMessage(byte, int) line: 153	
      	ClientHandshaker(Handshaker).processLoop() line: 868	
      	ClientHandshaker(Handshaker).process_record(InputRecord, boolean) line: 804	
      	SSLSocketImpl.readRecord(InputRecord, boolean) line: 1016	
      	SSLSocketImpl.performInitialHandshake() line: 1312	
      	SSLSocketImpl.startHandshake(boolean) line: 1339	
      	SSLSocketImpl.startHandshake() line: 1323	
      	HttpsClient.afterConnect() line: 563	
      	DelegateHttpsURLConnection(AbstractDelegateHttpsURLConnection).connect() line: 185	
      	DelegateHttpsURLConnection(HttpURLConnection).getOutputStream() line: 1091	
      	HttpsURLConnectionImpl.getOutputStream() line: 250	
      	ParameterMapFormProprietaryWriter.writeTo(Object, HttpURLConnection) line: 81	
      	RemoteRestAdminCommand$1.prepareConnection(HttpURLConnection) line: 763	
      	InstanceRestCommandExecutor(RemoteRestAdminCommand).doHttpCommand(String, String, RemoteRestAdminCommand$HttpCommand, boolean) line: 1058	
      	InstanceRestCommandExecutor(RemoteRestAdminCommand).doHttpCommand(String, String, RemoteRestAdminCommand$HttpCommand) line: 958	
      	InstanceRestCommandExecutor(RemoteRestAdminCommand).executeRemoteCommand(ParameterMap) line: 733	
      	InstanceRestCommandExecutor(RemoteRestAdminCommand).executeCommand(ParameterMap) line: 548	
      	InstanceRestCommandExecutor.run() line: 132	
      	Executors$RunnableAdapter<T>.call() line: 471	
      	FutureTask<V>.run() line: 262	
      	Executors$RunnableAdapter<T>.call() line: 471	
      	FutureTask<V>.run() line: 262	
      	ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1145	
      	ThreadPoolExecutor$Worker.run() line: 615	
      	Thread.run() line: 744	
      

        Activity

        Hide
        smillidge-c2b2 added a comment - - edited

        I believe this occurs if you disable the JMX connectors in GlassFish. The JMX connectors set the system properties javax.net.ssl.keyStorePassword and javax.net.ssl.trustStorePassword if they are disabled these are never set resulting in communication failure between the DAS and any instances with the error above.

        This Payara commit https://github.com/smillidge/Payara/commit/7318105bf17f6ee231bd3c818425169a7996bdd0 is an attempt at fixing this issue by moving the initialisation of these properties to the IdmService once it has obtained the MasterPassword. This is probably not the best fix. It is probably better to rewrite AsadminSecurityUtil to use the IdmService rather than relying on the system property.

        Show
        smillidge-c2b2 added a comment - - edited I believe this occurs if you disable the JMX connectors in GlassFish. The JMX connectors set the system properties javax.net.ssl.keyStorePassword and javax.net.ssl.trustStorePassword if they are disabled these are never set resulting in communication failure between the DAS and any instances with the error above. This Payara commit https://github.com/smillidge/Payara/commit/7318105bf17f6ee231bd3c818425169a7996bdd0 is an attempt at fixing this issue by moving the initialisation of these properties to the IdmService once it has obtained the MasterPassword. This is probably not the best fix. It is probably better to rewrite AsadminSecurityUtil to use the IdmService rather than relying on the system property.
        Hide
        Vinay Vishal added a comment -

        Exact issue as mentioned in the bug couldn't be reproduced. Exact steps to reproduce the same will be helpful. After changing the master password from default changeit to something else, domain server was started using password file. Password file had the new password as key value pair for key AS_ADMIN_MASTERPASSWORD. DAS got started successfully. Post this, a change was made in admin gui. Change successfully got saved.

        If this issue is related to communication between DAS and other instances and cluster, --passwordfile option will work fine if instance is started using "start-local-instance" command. However, for start-cluster or start-instance to work correctly, its important to have master-password file placed in node/agent directory on the host where instances are configured. For security reasons, master-password at present is not transmitted over the wire and hence start-cluster or start-instance being Remote CLI commands, will not work until or unless master-password file is present in the node/agent directory.

        Refer to following wiki for discussion around this: https://wikis.oracle.com/display/GlassFish/3.1+Master+Password

        Similar other issue: https://java.net/jira/browse/GLASSFISH-16149?jql=text%20~%20start-cluster

        Show
        Vinay Vishal added a comment - Exact issue as mentioned in the bug couldn't be reproduced. Exact steps to reproduce the same will be helpful. After changing the master password from default changeit to something else, domain server was started using password file. Password file had the new password as key value pair for key AS_ADMIN_MASTERPASSWORD. DAS got started successfully. Post this, a change was made in admin gui. Change successfully got saved. If this issue is related to communication between DAS and other instances and cluster, --passwordfile option will work fine if instance is started using "start-local-instance" command. However, for start-cluster or start-instance to work correctly, its important to have master-password file placed in node/agent directory on the host where instances are configured. For security reasons, master-password at present is not transmitted over the wire and hence start-cluster or start-instance being Remote CLI commands, will not work until or unless master-password file is present in the node/agent directory. Refer to following wiki for discussion around this: https://wikis.oracle.com/display/GlassFish/3.1+Master+Password Similar other issue: https://java.net/jira/browse/GLASSFISH-16149?jql=text%20~%20start-cluster
        Hide
        ChristianSch added a comment -

        the comment from smillidge provides a plausible root cause for the observed behavior. if password is not set, then GF falls back to 'changeit'

        @Vinay Vishal: instances have access to the correct master password

        Show
        ChristianSch added a comment - the comment from smillidge provides a plausible root cause for the observed behavior. if password is not set, then GF falls back to 'changeit' @Vinay Vishal: instances have access to the correct master password

          People

          • Assignee:
            Vinay Vishal
            Reporter:
            ChristianSch
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: