Bookmark this page

Guided Exercise: Securing HTTP Connections

Configure a HTTPS connection to allow secure connections from a browser, increase the number of HTTP connections supported by JBoss EAP, and enable an AJP listener to support communication with a load balancer.

Resources
Files: /home/student/AD248/labs/web-configuring/standalone
Application URL: http://workstation.lab.example.com:8080/temperature-converter
  https://workstation.lab.example.com:8443/temperature-converter
Resources /home/student/AD248/labs/web-configuring/temperature-converter.war
  /home/student/AD248/labs/web-configuring/workstation.p12

Outcomes

You should be able to access Red Hat JBoss Enterprise Application Platform (JBoss EAP) by using a secure connection from a browser, enable AJP, and set a maximum number of HTTP concurrent connections.

Before beginning the guided exercise, run the following command to prepare the environment:

[student@workstation ~]$ lab start web-configuring

The exercise environment enables the Red Hat Training Certificate Authority (CA) as a trusted certificates issuer. The /home/student/AD248/labs/web-configuring/workstation.p12 file is a signed certificate file to identify the workstation.lab.example.com server name. The certificate file uses password as the password.

Instructions

  1. Start the JBoss EAP standalone server.

    Use workstation.lab.example.com as the bind address. Use the following command to start a JBoss EAP instance:

    [student@workstation ~]$ cd /opt/jboss-eap-7.4/bin
    [student@workstation bin]$ ./standalone.sh \
    -Djboss.server.base.dir=/home/student/AD248/labs/web-configuring/standalone/ \
    -b workstation.lab.example.com

    Wait for the server to finish starting before proceeding.

  2. Deploy the temperature converter application.

    1. Open a new terminal window and run the following commands to start the management CLI connection to your JBoss EAP instance:

      [student@workstation ~]$ cd /opt/jboss-eap-7.4/bin
      [student@workstation bin]$ ./jboss-cli.sh -c
      [standalone@localhost:9990 /]
    2. Deploy the /home/student/AD248/labs/web-configuring/temperature-converter.war application file:

      [standalone@localhost:9990 /] deploy \
      /home/student/AD248/labs/web-configuring/temperature-converter.war
    3. Open a web browser on the workstation and navigate to http://workstation.lab.example.com:8080/temperature-converter to validate the deployment.

      The application front page shows.

    4. Open a web browser on the workstation and navigate to https://workstation.lab.example.com:8443/temperature-converter to validate the HTTPS connection.

      The browser self-signed certificate security warning shows.

  3. Create a Java Key Store (JKS) by importing the certificate that the exercise provides.

    1. In a new terminal, change to the exercise working directory, and import the workstation.p12 private certificate into a new identity.jks by using the keytool command.

      Use the password value as the destination and source keystore passwords.

      Note

      You can safely ignore the warning about the JKS format.

      [student@workstation ~]$ cd /home/student/AD248/labs/web-configuring/
      [student@workstation web-configuring]$ keytool -v -importkeystore \
      -srckeystore workstation.p12 -srcstoretype PKCS12 \
      -destkeystore identity.jks -deststoretype JKS
      Importing keystore workstation.p12 to identity.jks...
      Enter destination keystore password:
      Re-enter new password:
      Enter source keystore password:
      Entry for alias 1 successfully imported.
      Import command completed:  1 entries successfully imported, 0 entries failed or cancelled
      [Storing identity.jks]
      
      Warning:
      The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore identity.jks -destkeystore identity.jks -deststoretype pkcs12".
    2. Verify that the certificates that are available in the identity.jks keystore. Use the password value as the keystore password.

      [student@workstation web-configuring]$ keytool -list -v \
       -keystore /home/student/AD248/labs/web-configuring/identity.jks
      
      Enter keystore password:
      Keystore type: JKS
      Keystore provider: SUN
      
      Your keystore contains 1 entry
      
      Alias name: 1
      Creation date: Oct 23, 2023
      Entry type: PrivateKeyEntry
      Certificate chain length: 1
      Certificate[1]:
      Owner: CN=workstation.lab.example.com, O=EXAMPLE.COM
      Issuer: CN=Red Hat Training Certificate Authority, O=EXAMPLE.COM
      Serial number: 1c
      Valid from: Wed Oct 18 15:55:36 EDT 2023 until: Tue Oct 17 15:55:36 EDT 2028
      ...output omitted...
      #6: ObjectId: 2.5.29.17 Criticality=false
      SubjectAlternativeName [
        DNSName: workstation.lab.example.com
        DNSName: *.workstation.lab.example.com
      ]
      ...output omitted...
  4. Create the SSL connection configuration.

    Configure the https listener in the undertow subsystem by using the management CLI. To do this, create a HTTPSRealm security realm to store the certificate information.

    1. Return to the management CLI and add an HTTPSRealm security realm to the management core service:

      [standalone@localhost:9990 /] /core-service=\
      management/security-realm=HTTPSRealm:add()
      {"outcome" => "success"}
    2. Configure the HTTPSRealm realm to load the /home/student/AD248/labs/web-configuring/identity.jks keystore file. Use the password value as the password, and 1 as the alias.

      [standalone@localhost:9990 /] /core-service=management/security-realm=\
      HTTPSRealm/server-identity=ssl:add\
      (keystore-path=/home/student/AD248/labs/web-configuring/identity.jks, \
      keystore-password=password, alias=1)
      {
          "outcome" => "success",
          "response-headers" => {
              "operation-requires-reload" => true,
              "process-state" => "reload-required"
          }
      }

      Note

      Red Hat recommends to use a vault to protect the certificate password in production environments.

    3. Reload the server to enable the new realm:

      [standalone@localhost:9990 /] reload
  5. Configure the HTTPS listener.

    1. Modify the HTTPS listener to use the HTTPSRealm security realm.

      [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/\
      https-listener=https:write-attribute(name=security-realm,value=HTTPSRealm)
      {
          "outcome" => "success",
          "response-headers" => {
              "operation-requires-reload" => true,
              "process-state" => "reload-required"
          }
      }
    2. Reload the server to enable the new realm in the https connector:

      [standalone@localhost:9990 /] reload
    3. Open a web browser and navigate to https://workstation.lab.example.com:8443/temperature-converter to test the SSL connection.

    4. The SSL connection is available for all applications including the root application. Navigate to https://workstation.lab.example.com:8443/ and test the SSL connection for the root application.

  6. Enable the AJP protocol.

    1. To enable the AJP protocol, you must configure the AJP listener. Run the following command to enable the AJP protocol:

      [standalone@localhost:9990 /] /subsystem=undertow/server=\
      default-server/ajp-listener=ajp:add(socket-binding=ajp)
      {"outcome" => "success"}
    2. Verify that the AJP listener is configured by reading its properties:

      [standalone@localhost:9990 /] /subsystem=undertow/server=\
      default-server/ajp-listener=ajp:read-resource
      {
          "outcome" => "success",
          "result" => {
              "allow-encoded-slash" => false,
              "allow-equals-in-cookie-value" => false,
              "allow-unescaped-characters-in-url" => false,
              "always-set-keep-alive" => true,
              "buffer-pipelined-data" => false,
              "buffer-pool" => "default",
              "decode-url" => true,
              "disallowed-methods" => ["TRACE"],
              "enabled" => true,
              "max-ajp-packet-size" => 8192,
              "max-buffered-request-size" => 16384,
              "max-connections" => undefined,
              "max-cookies" => 200,
              "max-header-size" => 1048576,
              "max-headers" => 200,
              "max-parameters" => 1000,
              "max-post-size" => 10485760L,
              "no-request-timeout" => 60000,
              "read-timeout" => undefined,
              "receive-buffer" => undefined,
              "record-request-start-time" => false,
              "redirect-socket" => undefined,
              "request-parse-timeout" => undefined,
              "resolve-peer-address" => false,
              "rfc6265-cookie-validation" => false,
              "scheme" => undefined,
              "secure" => false,
              "send-buffer" => undefined,
              "socket-binding" => "ajp",
              "tcp-backlog" => 10000,
              "tcp-keep-alive" => undefined,
              "url-charset" => "UTF-8",
              "worker" => "default",
              "write-timeout" => undefined
          }
      }
  7. Tuning the HTTP listener.

    By default, the maximum connections number of all the listeners is unlimited. To avoid excessive compute resources usage, and to have a predictable capacity, set the maximum possible connections for the HTTP listener.

    1. You can update the number of connections by using the default server within the undertow subsystem. Set the maximum possible connections to 200 in the http-listener section:

      [standalone@localhost:9990 /] /subsystem=undertow/server=\
      default-server/http-listener=default:\
      write-attribute(name=max-connections, value=200)
      {
          "outcome" => "success",
          "response-headers" => {
              "operation-requires-reload" => true,
              "process-state" => "reload-required"
          }
      }

      Note

      It is also possible to define the maximum connections to the https-listener and to the ajp-listener.

    2. Reload the server to enable the maximum connections value:

      [standalone@localhost:9990 /] reload
      {
          "outcome" => "success",
          "result" => undefined
      }
    3. Verify that the max-connections attribute was changed:

      [standalone@localhost:9990 /] /subsystem=undertow/server=\
      default-server/http-listener=default:read-attribute(name=max-connections)
      {
          "outcome" => "success",
          "result" => 200
      }
  8. Exit the management CLI, and stop JBoss EAP the instance by pressing Ctrl+C in the terminal window.

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish web-configuring

Revision: ad248-7.4-18a9db2