Uploaded image for project: 'AMQ Broker'
  1. AMQ Broker
  2. ENTMQBR-4917

[LTS] SSLSupport Does Not Work With PKCS11

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Critical
    • Resolution: Done
    • AMQ 7.4.4.GA, AMQ 7.8.0.GA
    • None
    • None
    • None
    • Hide

      I was able to reproduce this with the embedded (JBoss EAP) broker by following the instructions at https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.3/html/how_to_configure_server_security/securing_the_server_and_its_interfaces#configure_ssl_fips_nss_database to create an nss db to use as a PKCS11 provder (no hard token / reader needed), then configuring my server as shown in the attachments (standalone-full.xml, standalone.conf, java.security, nss_pkcs11_fips.cfg). I did deviate a bit from the instruction as I had certs and ca certs already that I imported into nssdb via pk12util.

      Show
      I was able to reproduce this with the embedded (JBoss EAP) broker by following the instructions at https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.3/html/how_to_configure_server_security/securing_the_server_and_its_interfaces#configure_ssl_fips_nss_database to create an nss db to use as a PKCS11 provder (no hard token / reader needed), then configuring my server as shown in the attachments (standalone-full.xml, standalone.conf, java.security, nss_pkcs11_fips.cfg). I did deviate a bit from the instruction as I had certs and ca certs already that I imported into nssdb via pk12util.
    • Documentation (Ref Guide, User Guide, etc.), Release Notes
    • Hide
      This fix changes the meaning of the `keyStoreProvider` and `trustStoreProvider` connector/acceptor URL parameters. They no longer define the "type" of store (e.g. JKS, JCEKS, PKCS12, etc.). They now define the actual provider (e.g. SunJCE, SUN, SunJSSE, etc.). The *new* `keyStoreType` and `trustStoreType` parameters define the type of store. This change **will break** any existing client that is setting either `keyStoreProvider` or `trustStoreProvider` upon upgrade. Client URLs should be updated to use `keyStoreType` and `trustStoreType` instead of `keyStoreProvider` or `trustStoreProvider` respectively.
      Show
      This fix changes the meaning of the `keyStoreProvider` and `trustStoreProvider` connector/acceptor URL parameters. They no longer define the "type" of store (e.g. JKS, JCEKS, PKCS12, etc.). They now define the actual provider (e.g. SunJCE, SUN, SunJSSE, etc.). The *new* `keyStoreType` and `trustStoreType` parameters define the type of store. This change **will break** any existing client that is setting either `keyStoreProvider` or `trustStoreProvider` upon upgrade. Client URLs should be updated to use `keyStoreType` and `trustStoreType` instead of `keyStoreProvider` or `trustStoreProvider` respectively.

    Description

      The SSLSupport class expects the keyStore / trustStore path to be null when configuring PKCS11; however the java standard is to use a path of "NONE". This results in URL conversion and other errors when attempting to configure a PKCS11 SSL provider.

      Attachments

        Issue Links

          Activity

            People

              rhn-support-jbertram Justin Bertram
              rhn-support-jsherman Jason Sherman
              Mikhail Krutov Mikhail Krutov
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: