The variable value can be passed in using -D system properties, but not as an environment variable (Phils example set the -D system property configuration by supplying it to the startup script via an environment variable the startup script uses to enable such configuration).
Robbie On 11 December 2012 21:47, <[email protected]> wrote: > Hi, Robbie, > > Make sense. > > The ssl keystore/truststore/passwords in connection url is for client > side only. > > But for broker, the configuration should go in config.xml where the > variable can be used as per Phil and the value of the variables can be > passed in using -D or via environment variable. > > Again, I will leave JMX out of the scope at this point. > > Thanks, > David > > -----Original Message----- > From: Robbie Gemmell [mailto:[email protected]] > Sent: Tuesday, December 11, 2012 4:43 PM > To: [email protected] > Subject: Re: How to encrypt ssl keystore password in config.xml > > Hi David, > > There seems to be a bit of confusion here. > > The brokers SSL configuration in relation to the messaging ports can > only be controlled using the <connector><ssl> elements in config.xml. > Phil was suggesting that you could use system properties (which will be > resolved at broker startup) in the config file rather than placing the > actual values in the config file. These system property could be the > standard SSL system properties, or any other name of your own choosing. > In this case anyone able to connect via JMX and view the contents of the > JVMs 'Platform' > MBeanServer (which is what gets used by default by the broker for its > MBeans and by the JVM itself for all its standard MBeans, and then gets > exposed via JMX either by the brokers JMXConnectorServer or the JVMs own > if is enabled at startup or activated by 'locally' attaching JConsole > etc as the user who started the process) would be able to view the > arguments used to start the JVM since one of the standard MBeans exposes > these (as used to populate the VM Summary tab in JConsole), and those > would include the system properties. There is one way around that, as > mentioned in my earlier email and further explained below [*]. > > The ability to specify SSL options in the clients connection url (as > opposed to via the client JVMs SSL system properties) only influences > the clients SSL configuration, not the brokers. The keystore and > truststore configuration for the server and client side are entirely > independent. When the broker has an SSL certificate it needs a keystore, > and the client needs a truststore containing trust information for that > certificate (assuming it is not trusted at the JVM installation level). > When the broker additionionally requires client certificates be > presented then the client will also need a keystore to contain its > certificate, and the broker will then need a truststore containing trust > information relating to the client certificates (again assuming they are > not already trusted at the JVM installation level). > > Robbie > > [*] You could move the brokers MBeans out of the Platform MBeanServer > using the configuration I mentioned previously, which would prevent > people from being able to see the argument information (along with all > the Thread, Memory etc information) when connecting to the > JMXConnectorServer started by the broker. People connecting to the JVMs > own Platform JMXConnectorServer (which gets used when you have started > in the JVM using the com.sun.management.* options and then do a 'remote' > JConsole etc connection to the JMXConnectorServer, on that port, or > perform a 'local' > connection to a JVM with JConsole etc whereby a management agent is > injected in the running JVM using the Attach API) would still be viewing > the contents of the Platform MBeanServer and thus be able to view that > argument information, but would not be able to view the brokers MBeans > since they would now be in a separate MBeanServer. Unless you start the > JVM the com.sun.management.* options to enable its platform > JMXConnectorServer, the ability to access the Platform > JMXConnectorServer would only apply to the user who started the broker, > such that they can do a 'local' JMX connection with JConsole etc, and > they obviously already had acess to the argument information anyway when > starting the broker. > > On 11 December 2012 17:04, <[email protected]> wrote: > > > Hi, Phil, > > > > With another of the response, you seem have recommended two approaches > > > on doing this - > > > > 1. use system variable > > (1) use java option -D to pass the value in > > (2) export variable to pass in the value > > > > 2. Pass the keystore and password via connection URL (like your test > > case). It means that that the one passed in via connection URL > > overrides the one defined in config.xml, correct? > > > > For 1(1), the password will be exposed in Jconsole. For 1(2), the > > password will be in starting script. > > > > The better approach is 2 where we can programatically construct the > URL. > > The password can be passed-in in encrypted format and can be decrypted > > > when constructing URL. > > > > Still it seems there is no out-of-box solution, we need to write our > > own client (in the context of Synapse, we need to write our own > JMSListener. > > It goes back to my understanding before. > > > > Thanks for all the help. > > > > David > > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Phil Harvey > > Sent: Tuesday, December 11, 2012 2:00 AM > > To: [email protected] > > Subject: Re: How to encrypt ssl keystore password in config.xml > > > > Hi David, > > > > You can't exactly encrypt it, but you can avoid hard coding it. You > > can refer to system properties in config.xml using the form > ${mypassword}. > > > > Expose system properties to the broker before starting it like so: > > > > export QPID_OPTS='-Dmypassword=password1' > > > > I think the broker automatically picks up the value of system property > > > javax.net.ssl.keyStorePassword but iirc this depends on the broker > > version and whether you're setting it for messaging connections or for > > > management. > > I will check. By the way what is your brother version? > > > > A word of warning: anyone who can connect JConsole to the broker can > > inspect system properties (possibly excluding > > javax.net.ssl.keyStorePassword, but I'm not sure), so you should > > consider ways of controlling access. The online broker documentation > > describes how to apply authentication and authorisation to JMX access. > > > > Hope that helps, > > Phil > > On Dec 8, 2012 12:21 AM, <[email protected]> wrote: > > > > > ** > > > > > > Hi, Guys, > > > > > > Is there a way to encrypt keystore password in ssl configuration in > > > config.xml? > > > > > > David > > > > > > *David Hu* > > > UBS, Group Technology Platform Service > > > 1-201-318-7435 > > > ChatID: huda > > > > > > > > > Visit our website at http://www.ubs.com > > > > > > This message contains confidential information and is intended only > > > for the individual named. If you are not the named addressee you > > > should not disseminate, distribute or copy this e-mail. Please > > > notify > > > > > the sender immediately by e-mail if you have received this e-mail by > > > > mistake and delete this e-mail from your system. > > > > > > E-mails are not encrypted and cannot be guaranteed to be secure or > > > error-free as information could be intercepted, corrupted, lost, > > > destroyed, arrive late or incomplete, or contain viruses. The > > > sender therefore does not accept liability for any errors or > > > omissions in the > > > > > contents of this message which arise as a result of e-mail > > transmission. > > > If verification is required please request a hard-copy version. > > > This message is provided for informational purposes and should not > > > be construed as a solicitation or offer to buy or sell any > > > securities or related financial instruments. > > > > > > > > > UBS reserves the right to retain all messages. Messages are > > > protected and accessed only in legally justified cases. > > > > > > > > > -------------------------------------------------------------------- > > > - To unsubscribe, e-mail: [email protected] For > > > additional commands, e-mail: [email protected] > > > > > Visit our website at http://www.ubs.com > > > > This message contains confidential information and is intended only > > for the individual named. If you are not the named addressee you > > should not disseminate, distribute or copy this e-mail. Please notify > > > the sender immediately by e-mail if you have received this e-mail by > > mistake and delete this e-mail from your system. > > > > E-mails are not encrypted and cannot be guaranteed to be secure or > > error-free as information could be intercepted, corrupted, lost, > > destroyed, arrive late or incomplete, or contain viruses. The sender > > therefore does not accept liability for any errors or omissions in the > > > contents of this message which arise as a result of e-mail > transmission. > > If verification is required please request a hard-copy version. This > > message is provided for informational purposes and should not be > > construed as a solicitation or offer to buy or sell any securities or > > related financial instruments. > > > > > > UBS reserves the right to retain all messages. Messages are protected > > and accessed only in legally justified cases. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] For > > additional commands, e-mail: [email protected] > > > > > Visit our website at http://www.ubs.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mails are not encrypted and cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, > destroyed, arrive late or incomplete, or contain viruses. The sender > therefore does not accept liability for any errors or omissions in the > contents of this message which arise as a result of e-mail transmission. > If verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities > or related financial instruments. > > > UBS reserves the right to retain all messages. Messages are protected > and accessed only in legally justified cases. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
