3 Replies Latest reply on Aug 25, 2021 3:31 AM by Philipp Holler

    Supplier Portal Keystore Integration with Windows Keystore

    Philipp Holler New Member

      Hello,

       

      we are currently facing a security issue with our Supplier Portal and the SSL-certificate. In the standard informatica solution the tomcat connector looks like this:

       

      <Connector port="9443" protocol="org.apache.coyote.http11.Http11NioProtocol" 
      maxThreads="150" scheme="https" secure="true" SSLEnabled="true" 
      keystoreFile="XXXXX/keystore.jks" keystorePass="XXXXXX" 
      clientAuth="false" keyAlias="XXXXXX" 
      sslProtocol="TLS" URIEncoding="UTF-8"/>
      

       

      We are currently planing to move the SSL-certificate into the Windows Keystore instead of using the java-generated .jks-file.

      The connector should work looking like this:

       

      <Connector port="8443" 
        protocol="org.apache.coyote.http11.Http11NioProtocol"
        SSLEnabled="true"
        maxThreads="150" 
        scheme="https" 
        secure="true"
        keyAlias="XXXXXX"
        keystoreFile=""
        keystoreType="Windows-My"
        clientAuth="false" 
        sslProtocol="TLS"
        keepAliveTimeout="200000" />

       

      Does anyone has a similar architecture or is using the Windows Keystore?

      I would like to know if the Supplier Portal is working without any issues or if you have a other solution where the password for the keystore is not saved unencrypted.

      Thank you in advance!

        • 1. Re: Supplier Portal Keystore Integration with Windows Keystore
          purusottam nayak Guru

          Hi Philipp,

           

          Are you facing any issues while using this architecture ?

           

          Regards,

          Puru

          • 2. Re: Supplier Portal Keystore Integration with Windows Keystore
            Sathiesh M Guru

            SSL config with Windows Keystore for Tomcat Connector:

             

             

            https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html

             

             

            Tomcat currently operates only on JKS, PKCS11 or PKCS12 format keystores. The JKS format is Java's standard "Java KeyStore" format, and is the format created by the keytool command-line utility. This tool is included in the JDK. The PKCS12 format is an internet standard, and can be manipulated via (among other things) OpenSSL and Microsoft's Key-Manager.

            To define a Java (JSSE) connector, regardless of whether the APR library is loaded or not, use one of the following:

             

             

            <!-- Define an HTTP/1.1 Connector on port 8443, JSSE NIO implementation -->

            <Connector protocol="org.apache.coyote.http11.Http11NioProtocol"

                       sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"

                       port="8443" .../>

             

             

            <!-- Define an HTTP/1.1 Connector on port 8443, JSSE NIO2 implementation -->

            <Connector protocol="org.apache.coyote.http11.Http11Nio2Protocol"

                       sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"

                       port="8443" .../>

             

             

            The final step is to configure the Connector in the $CATALINA_BASE/conf/server.xml file, where $CATALINA_BASE represents the base directory for the Tomcat instance. An example <Connector> element for an SSL connector is included in the default server.xml file installed with Tomcat. To configure an SSL connector that uses JSSE, you will need to remove the comments and edit it so it looks something like this:

             

             

            <!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->

            <Connector

                       protocol="org.apache.coyote.http11.Http11NioProtocol"

                       port="8443" maxThreads="200"

                       scheme="https" secure="true" SSLEnabled="true"

                       keystoreFile="${user.home}/.keystore" keystorePass="changeit"

                       clientAuth="false" sslProtocol="TLS"/>

            Set the keystoreType value to JKS or PKCS12 as required. If the key store contains multiple certificates, use the keyAlias attribute to set the alias.

             

             

            https://www.oracle.com/technical-resources/articles/javase/security.html

             

             

            Keys and certificates stored in MS Windows key containers and certificate stores, known as keystores, can be accessed by using the java.security.KeyStore class and the SunMSCAPI provider. The same set of KeyStore APIs are used for accessing MS Windows keystores and other types of keystores, such as JKS or PKCS12. However, because MS Windows keystores do not use passwords and cannot be imported or exported, values for password and input-output stream arguments should be null. By default, the SunMSCAPI provider silently ignores non-null values

            • 3. Re: Supplier Portal Keystore Integration with Windows Keystore
              Philipp Holler New Member

              Hi,

               

              pnayak

              so far we are running with this solution but had some issues with implementation.

               

              The Windows certificate store is seperated in two different parts: Windows-Root and Windows-My. Windows-My includes the certificates for the local computer and for the user, both accessed with "Windows-My".
              Well unfortunatly there is a bug in the openJDK which is used by Tomcat. The <Connector> - String is only able to access the certificates of the user but not of the local computer. Therefore you have to import the certificate to the user, which is running the Tomcat-service. Took some time to find this bug.

               

              For reference you can check:

              [JDK-6782021] It is not possible to read local computer certificates with the SunMSCAPI provider - Java Bug System

               

              Regards,

               

              Philipp

              1 of 1 people found this helpful