Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-8798

CLI Opertation 'load' for Elytron key-store does not change key used by management

XMLWordPrintable

    • Hide

      1) Create keystore and copy it to standalone/configuration/:

      keytool -genkeypair -alias alias1 -keyalg RSA -keysize 1024 -validity 365 -keystore keystore.jks -dname "CN=alias1" -keypass secret -storepass secret
      cp keystore.jks standalone/configuration/
      

      2) Create a key-store, key-manager, and server-ssl-context and enable HTTPS on the management interface:

      /subsystem=elytron/key-store=httpsKS:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
      /subsystem=elytron/key-managers=httpsKM:add(key-store=httpsKS,algorithm="SunX509",credential-reference={clear-text=secret})
      /subsystem=elytron/server-ssl-context=httpsSSC:add(key-managers=httpsKM,protocols=["TLSv1.2"])
      /core-service=management/management-interface=http-interface:write-attribute(name=ssl-context, value=httpsSSC)
      /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
      reload
      

      3) Try to access CLI - certificate CN=alias1 is exposed by server. Trust 'temporarily' to that certificate and try to read certificate in key-store:

      /subsystem=elytron/key-store=httpsKS/alias=alias1:read-attribute(name=certificate-chain)
      

      Certificate with CN=alias1 is displayed.

      4) Create new keystore with the same password and name but with different certificate and copy it again to standalone/configuration/ (it will replace original keystore):

      keytool -genkeypair -alias alias2 -keyalg RSA -keysize 1024 -validity 365 -keystore keystore2.jks -dname "CN=alias2" -keypass secret -storepass secret
      cp keystore2.jks standalone/configuration/keystore.jks
      

      5) Read certificate in key-store again, original certificate is still provided:

      /subsystem=elytron/key-store=httpsKS/alias=alias1:read-attribute(name=certificate-chain)
      

      6) Use load operation to re-reading keystore, the certificate (CN=alias2) is provided then - it is correct:

      /subsystem=elytron/key-store=httpsKS:load()
      /subsystem=elytron/key-store=httpsKS/alias=alias2:read-attribute(name=certificate-chain)
      

      7) Quit CLI and try to access it again - original certificate (CN=alias1) is still incorrectly provided - it should use the new CN=alias2 certificate. When server is reloaded then the new certificate (CN=alias2) is provided correctly.

      Show
      1) Create keystore and copy it to standalone/configuration/ : keytool -genkeypair -alias alias1 -keyalg RSA -keysize 1024 -validity 365 -keystore keystore.jks -dname "CN=alias1" -keypass secret -storepass secret cp keystore.jks standalone/configuration/ 2) Create a key-store, key-manager, and server-ssl-context and enable HTTPS on the management interface: /subsystem=elytron/key-store=httpsKS:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS) /subsystem=elytron/key-managers=httpsKM:add(key-store=httpsKS,algorithm= "SunX509" ,credential-reference={clear-text=secret}) /subsystem=elytron/server-ssl-context=httpsSSC:add(key-managers=httpsKM,protocols=[ "TLSv1.2" ]) /core-service=management/management- interface =http- interface :write-attribute(name=ssl-context, value=httpsSSC) /core-service=management/management- interface =http- interface :write-attribute(name=secure-socket-binding, value=management-https) reload 3) Try to access CLI - certificate CN=alias1 is exposed by server. Trust 'temporarily' to that certificate and try to read certificate in key-store: /subsystem=elytron/key-store=httpsKS/alias=alias1:read-attribute(name=certificate-chain) Certificate with CN=alias1 is displayed. 4) Create new keystore with the same password and name but with different certificate and copy it again to standalone/configuration/ (it will replace original keystore): keytool -genkeypair -alias alias2 -keyalg RSA -keysize 1024 -validity 365 -keystore keystore2.jks -dname "CN=alias2" -keypass secret -storepass secret cp keystore2.jks standalone/configuration/keystore.jks 5) Read certificate in key-store again, original certificate is still provided: /subsystem=elytron/key-store=httpsKS/alias=alias1:read-attribute(name=certificate-chain) 6) Use load operation to re-reading keystore, the certificate ( CN=alias2 ) is provided then - it is correct: /subsystem=elytron/key-store=httpsKS:load() /subsystem=elytron/key-store=httpsKS/alias=alias2:read-attribute(name=certificate-chain) 7) Quit CLI and try to access it again - original certificate ( CN=alias1 ) is still incorrectly provided - it should use the new CN=alias2 certificate . When server is reloaded then the new certificate ( CN=alias2 ) is provided correctly.

      When keystore (or cerficate in keystore) is changed during server runtime then CLI opertation load can be used for /subsystem=elytron/key-store=... to re-reading this keystore in server. However after calling this operation server still works with original keystore/certificate. Then CLI reads current keystore correctly, but in case when ssl-context which uses that key-store is used then original keystore is still used by server. Reload of server is required to correctly re-read the new keystore. See Steps to Reproduce for more details.

      We request blocker flag since this issue blocks RFE EAP7-455.

              jkalina@redhat.com Jan Kalina (Inactive)
              jkalina@redhat.com Jan Kalina (Inactive)
              Martin Svehla Martin Svehla
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: