47 Using Secured Production Mode

In a WebLogic Server domain, the domain mode determines the default values to apply to the security configuration of the domain. Secured production mode applies the strictest default values to the security configuration of your domain.

The domain modes, in order from least to most secure default values, are:

  • Development mode
  • Production mode
  • Secured production mode

When you enable secured production mode, WebLogic Server automatically sets some security configurations to more secure values. However, there are certain security configurations that require additional configuration.

The domain mode only specifies the default values of a domain's security configuration. You can still modify individual configurations to override the default values. Overriding default values can help you fine tune your configuration to meet functional and security requirements, but overriding secured production mode default values should be done with caution, as it may result in a less secure environment.

If your domain does not meet the security criteria of a domain mode, WebLogic Server will flag any insecure values and report them as security warnings. For more information on security validation warnings, see Review Potential Security Issues in . You may also experience behavioral issues when trying to manage your domain.

For information on the default values in each domain mode, see Understand How Domain Mode Affects the Default Security Configuration in .

Although secured production mode can be a powerful tool for securing your domain, it is limited by the complexity and sheer variety of WebLogic Server environments. To ensure your domain is well protected, you should also review the recommendations outlined in Configuring Security for a WebLogic Domain and in https://docs.oracle.com/pls/topic/lookup?ctx=en/middleware/fusion-middleware/weblogic-server/14.1.2/secmg&id=LOCKD-GUID-3243B8E2-6723-4589-B3E3-78187CE06883 and then apply them as appropriate to your environment.

Changes to the Domain Mode

The domain mode is specified as part of the initial domain configuration process. Although it is possible to change the domain mode after a domain is created, interactions between an existing domain configuration and the configurations that are applied by the new domain mode can lead to unexpected outcomes.

The domain mode only controls default values, therefore any configurations that you have set explicitly will persist after a change in domain mode and supersede the values that would otherwise be used. Additionally, if the default value of a configuration in the new domain mode matches the existing, explicit value, it will remove the explicit configuration (and its value) from the domain configuration. Then, if you decide to revert to your previous domain mode, the explicit configuration will remain absent.

Before you change the domain mode to secured production mode, make sure that you carefully review your domain configuration file, config.xml, and compare its existing values to the MBean attributes that are determined by domain mode. See Secure Values for MBean Attributes in . To change the domain mode after domain creation, see Changing the Domain Mode.

When is Secured Production Mode Enabled?

As of WebLogic 14.1.2.0.0, when you set the domain mode to production mode, it enables secured production mode by default. In previous releases, when you enabled production mode, secured production mode was disabled by default and you had to enable it explicitly.

If you upgrade from WebLogic Server 14.1.1.0.0 and earlier, the behavior of your domain mode will not change. For example, when a domain in production mode is upgraded from 14.1.1.0.0 to 14.1.2.0.0 or later, it will remain in production mode with secured production mode disabled. However, if you upgrade your non-production mode domain to 14.1.2.0.0 or later, and then change the domain mode to production mode, it will enable secured production mode by default.

Note:

You can still use production mode with secured production mode disabled, but you must explicitly disable secured production mode. See Change the Domain Mode in .

The domain configuration file, config.xml, does not explicitly state that secured production mode is enabled because secured production mode enabled is now the default state of production mode.

Table 47-1 Domain Mode in the Domain Configuration File (config.xml)

WebLogic Server Release Secured Production Mode is Enabled Secured Production Mode is Disabled
14.1.2.0.0 and later 
<production-mode-
enabled>true</production-mode-enabled>
 
<production-mode-
enabled>true</production-mode-enabled>
<secure-mode>
  <secure-mode-enabled>false</secure-
mode-enabled>
</secure-mode>
14.1.1.0.0 and earlier 
<production-mode-
enabled>true</production-mode-enabled>
<secure-mode>
  <secure-mode-enabled>true</secure-
mode-enabled>
</secure-mode>
 
<production-mode-
enabled>true</production-mode-enabled>

Changing the Domain Mode

You can change the domain mode on an existing domain.

Changes to the domain mode require a full domain restart - a rolling restart is not sufficient. Oracle recommends that you use offline tools (such as WLST Offline) to modify the domain mode. If you modify the domain mode on running domains, using tools such as WebLogic Remote Console, you must still shut down all of the servers in the domain and then restart them, one server at a time.

When changing the domain mode of an existing domain, consider saving the existing config.xml file so you can compare it with the new config.xml file after the domain mode change and assess which settings were changed. See Changes to the Domain Mode for an explanation of the potential effects of making domain mode changes on an existing domain.

  • If using WLST Offline:
    1. Shut down the domain.
    2. Invoke WLST Offline. See Invoking WLST in .
    3. Run the WLST Offline script that changes your current domain mode to your target domain mode.
      Current Domain Mode Target Domain Mode WLST Offline Script

      Development

      Production

      Note: Secured Production Mode is enabled by default. 

      readDomain('DOMAIN_NAME')
cmo.setProductionModeEnabled(true)
updateDomain()

      Development

      Production (with Secured Production Mode explicitly disabled)

      		 
      readDomain('DOMAIN_NAME')
cmo.setProductionModeEnabled(true)
cd('/SecurityConfiguration/%s' %(cmo.getName()))
create('NO_NAME','SecureMode')
cd('SecureMode/NO_NAME')
set('SecureModeEnabled','false')
updateDomain()

      Production (with Secured Production Mode disabled)

      Secured Production

      		 
      readDomain('DOMAIN_NAME')
cd('/SecurityConfiguration/%s/SecureMode/NO_NAME_0' %(cmo.getName()))
set('SecureModeEnabled',true)
updateDomain()

      Production

      Development

      		 
      readDomain('DOMAIN_NAME')
cmo.setProductionModeEnabled(false)
cmo.getSecurityConfiguration().getSecureMode().setSecureModeEnabled(false)
updateDomain()

      Secured Production

      Production (with Secured Production Mode explicitly disabled)

      		 
      readDomain('DOMAIN_NAME')
cd('/SecurityConfiguration/%s' %(cmo.getName()))
create('NO_NAME','SecureMode')
cd('SecureMode/NO_NAME')
set('SecureModeEnabled','false')
updateDomain()

      Secured Production

      Development

      		 
      readDomain('DOMAIN_NAME')
cmo.setProductionModeEnabled(false)
updateDomain()
    4. Start your domain.
  • If using WebLogic Remote Console, see Change the Domain Mode in .

Changes to the domain mode can affect the default URL of the Administration Server. When SSL/TLS and the administration port are enabled (by default, both are enabled in secured production mode), the default URL is https://hostname:9002 or t3s://hostname:9002. Take note of the protocol and the port number. When SSL/TLS and the administration port are disabled (by default, both are disabled in development mode), the default URL is http://hostname:7001 or t3://hostname:7001.

When you enable secured production mode, WebLogic Server expects certain security configurations to be configured. If they are not configured properly, it will flag settings it deems insecure and possibly block traffic on ports or addresses that were previously available in less secure domain modes.

Overriding the Domain Mode (Single Server Domains Only)

It is possible to override the current domain mode of your domain for the duration of its server life cycle. After you restart the server, it will return to its normal domain mode.

You should only perform this task on single server domains in development or test environments.

Note:

When you override the domain mode at the command line, you will not see the effective domain mode in the config.xml file or the WebLogic Remote Console Edit Tree perspective. Instead, you can use WLST or the Configuration View Tree perspective in WebLogic Remote Console to see the effective state of the domain. See Verifying Attribute Values That Are Set on the Command Line in .

If you want to override the current domain mode of your domain, then run the Administration Server start script and include a system property that determines the effective domain mode. See Table 47-2 for the system properties and their usage.

For example, to try out production mode, run:

startWebLogic.sh -Dweblogic.ProductionModeEnabled=true

You can also set environment variables to achieve the same outcome. For example:

export DOMAIN_PRODUCTION_MODE="true"
startWebLogic.sh

Table 47-2 Overriding the domain mode at the command line

Current Domain Mode Target Domain Mode System Property Environment Variable

Development

Production

Note: Secured Production Mode is enabled by default.

weblogic.ProductionModeEnabled=true DOMAIN_PRODUCTION_MODE="true"

Development

Production (with Secured Production Mode disabled)

 Include both system properties:
  • weblogic.ProductionModeEnabled=true
  • weblogic.securemode.SecureModeEnabled=false
 Set both environment variables:
  • DOMAIN_PRODUCTION_MODE="true"
  • SECURE_PRODUCTION_MODE="false"

Production (with Secured Production Mode disabled)

Secured Production

 weblogic.securemode.SecureModeEnabled=true SECURE_PRODUCTION_MODE="true"

Production

Development

 weblogic.ProductionModeEnabled=false DOMAIN_PRODUCTION_MODE="false"

Secured Production

Production (with Secured Production Mode disabled)

 weblogic.securemode.SecureModeEnabled=false SECURE_PRODUCTION_MODE="false"

Secured Production

Development

 weblogic.ProductionModeEnabled=false DOMAIN_PRODUCTION_MODE="false"

Connecting to the Administration Server using WebLogic Remote Console

Depending on your existing security settings, you may need to perform additional configuration before you can manage a domain with secured production mode enabled.

  1. Choose one of the options for starting an Administration Server as described in Starting and Stopping Servers in .

    You may want to create a boot identity file to store user credentials for starting and stopping an instance of WebLogic Server. See Creating a Boot Identity File for an Administration Server in . If you choose to create a boot identity file, then make sure to set appropriate permissions on the boot.properties file and its containing folder, DOMAIN_HOME/servers/AdminServer/security/. We recommend setting chmod 600 on boot.properties and chmod 740 for DOMAIN_HOME/servers/AdminServer/security.

  2. Connect to the domain using WebLogic Remote Console as described in Connect to an Administration Server in .

    The default address of your Administration Server is now https://hostname:9002 . Note the s in https and the port number.

    In secured production mode, the non-SSL/TLS listen port (typically 7001) is disabled by default and traffic is routed over the SSL/TLS ports. If you want to configure listen ports, see Specify Listen Ports in .

  3. Configure custom keystores as described in Configure Keystores in .

    In production environments, you should configure custom keystores for identity and trust. See Obtaining and Storing Certificates for Production Environments. If you want to use the demo certificates provided by WebLogic Server instead, review the topics under Secured Production Mode in Development Environments.

  4. Make sure that SSL/TLS is configured properly, as described in Set Up TLS in .
  5. Enable host name verification, as described in Enable Host Name Verification in .
  6. Optional: If you use Oracle Platform Security Services (OPSS) but you want to configure your domain with custom certificates, see Replacing Demonstration CA Signed Certificates in instead.
  7. Save and commit your changes.
  8. Restart the Administration Server.

Starting Managed Servers using WebLogic Remote Console

If you use WebLogic Remote Console to start Managed Servers, you must configure Node Manager to register the properties for your custom keystore.

  1. Ensure Node Manager is configured properly to work with WebLogic Remote Console, as described in Start Managed Servers in .
  2. Update the nodemanager.properties file with the following attributes and their values:
    • CustomIdentityAlias
    • CustomIdentityKeyStoreFileName
    • CustomIdentityPrivateKeyPassPhrase
    • CustomIdentityKeyStorePassPhrase
    • KeyStores

    See Node Manager Properties in .

  3. Optional: If multiple server instances run on the same computer in the domain and the domain-wide administration port is enabled, then you must perform one of the following:
    • Host the server instances on a multi-homed machine and assign each server instance a unique listen address
    • Override the domain-wide port on all but one of the servers instances on the machine. On the Environment: Servers: myServer page for each Managed Server, enter a unique port value in the Local Administration Port Override field.
  4. Save and commit your changes.
  5. Start the Managed Server.

Connecting to the Administration Server using WLST

You must perform additional configuration before you can use the WebLogic Scripting Tool to connect to a domain with secured production mode enabled.

  1. Start the Administration Server.

    You may want to create a boot identity file to store user credentials for starting and stopping an instance of WebLogic Server. See Creating a Boot Identity File for an Administration Server in . If you choose to create a boot identity file, then make sure to set appropriate permissions on the boot.properties file and its containing folder, DOMAIN_HOME/servers/AdminServer/security/. We recommend setting chmod 600 on boot.properties and chmod 740 for DOMAIN_HOME/servers/AdminServer/security.

  2. Update the WLST_PROPERTIES environment variable to configure keystores:
    export WLST_PROPERTIES="-Dweblogic.security.TrustKeyStore=CustomTrust -Dweblogic.security.CustomTrustKeyStoreFileName=trustKeystoreFile -Dweblogic.security.CustomTrustKeyStorePassPhrase=trustKeyStorePassword"
  3. Connect to the domain using the WLST as described in Invoking WLST in .

    Note:

    The default address of an Administration Server in secured production mode is t3s://hostname:9002. Note the s in t3s and the port number.

Starting Managed Servers using a Start Script

You can start Managed Servers using a start script.

  1. Create a boot identity file for each Managed Server. See Creating Boot Identity Files for Managed Servers in .
    Make sure to set appropriate permissions on the file and its containing folder. We recommend setting chmod 600 on the boot.properties file and chmod 740 for the folder, DOMAIN_HOME/servers/managedServerName/security/. If a boot.properties file is not available, then you must include a username and password when starting servers from the command line.
  2. Specify the keystore values for the Managed Server by adding the following arguments to the JAVA_OPTIONS environment variable.
    • -Dweblogic.security.SSL.trustedCAKeyStore
    • -Dweblogic.security.SSL.trustedCAKeyStorePassPhrase

    For example:

    export JAVA_OPTIONS="-Dweblogic.security.SSL.trustedCAKeyStore=trustKeystoreFile -Dweblogic.security.SSL.trustedCAKeyStorePassPhrase=trustKeyStorePassword"
  3. Run the startManagedWebLogic script as described in Starting Managed Servers with a Startup Script in .

    For example:

    startManagedWebLogic.sh managedServerName https://adminHostname:adminPort

About SAML 2.0 General Services

The general SAML 2.0 services you configure include the following:

  • Whether you wish to enable the replicated cache

    Enabling the replicated cache is required if you are configuring SAML 2.0 services on two or more WebLogic Server instances in a domain, such as in a cluster. The replicated cache enables server instances to share and be synchronized with the data that is managed by the SAML 2.0 security providers; that is, either or both the SAML 2.0 Identity Assertion provider and the SAML 2.0 Credential Mapping provider.

    The RDBMS security store is required by the SAML 2.0 security providers in production environments so that the data they manage can be synchronized across all the WebLogic Server instances that share that data. (Use LDAP as the security store with the SAML 2.0 security providers only in development environments.)

    Therefore, prior to configuring SAML 2.0 services, the preferred approach is first to create a domain that is configured to use the RDBMS security store. See Managing the RDBMS Security Store.

  • Information about the local site

    The site information you enter is primarily for the benefit of the business partners in the SAML federation with whom you share it. Site information includes details about the local contact person who is your partners' point of contact, your organization name, and your organization's URL.

  • Published site URL

    This URL specifies the base URL that is used to construct endpoint URLs for the various SAML 2.0 services. The published site URL should specify the host name and port at which the server is visible externally, which might not be the same at which the server is accessed locally. For example, if SAML 2.0 services are configured in a cluster, the host name and port may correspond to the load balancer or proxy server that distributes client requests to the Managed Servers in that cluster.

    The published site URL should be appended with /saml2. For example:

    https://www.avitek.com:7001/avitek-domain/aviserver/saml2

  • Entity ID

    The entity ID is a human-readable string that uniquely distinguishes your site from the other partner sites in your federation. When your partners need to generate or consume an assertion, the SAML 2.0 services use the entity ID as part of the process of identifying the partner that corresponds with that assertion.

  • Whether recipient check is enabled

    If enabled, the recipient of the authentication request or response must match the URL in the HTTP Request.

  • Whether TLS/SSL client authentication is required for invocations on the Artifact Resolution Service. If enabled, SAML artifacts are encrypted when transmitted to partners.

  • Transport Layer Security keystore alias and passphrase, the values used for securing outgoing communications with partners.

  • Whether Basic authentication client authentication is required when your partners invoke the HTTPS bindings of the local site.

    If you enable this setting, you also specify the client username and password to be used. These credentials are then included in the published metadata file that you share with your federated partners.

  • Whether requests for SAML artifacts received from your partners must be signed.

  • Configuration settings for the SAML artifact cache.

  • Keystore alias and passphrase for the key to be used when signing documents sent to your federated partners, such as authentication requests or responses.

For information about the steps for configuring SAML 2.0 general services, see Configure SAML 2.0 general services in the .

Secured Production Mode in Development Environments

If you want to assess the features of secured production mode but do not want to expend the effort to set up custom keystores, it is possible to configure WebLogic Server to use secured production mode with the demonstration keystores included with WebLogic Server.

For information on the demonstration keystores, see Using Keystores and Certificates in a Development Environment. If you want to use the OPSS Keystore Service, see also Configuring Oracle OPSS Keystore Service.

Note:

The following procedures are suitable for testing and development purposes only. Do not use demo keystores in a true production environment.

Using Secured Production Mode with Demonstration Keystores

If you plan to use the demo keystores in a domain that has secured production mode enabled, then you may need to perform additional configuration before you can start your domain.

Note:

The following procedures are suitable for testing and development purposes only. Do not use demo keystores in a true production environment.

For production environments, refer to Connecting to the Administration Server using WebLogic Remote Console or Connecting to the Administration Server using WLST instead.

  1. Set the domain mode to secured production mode using one of the following methods:

    • Create a new domain and select secured production mode as the domain mode when prompted.

      Creating a new domain allows you to configure many of the settings that are necessary for secured production mode in a single procedure and reduces the likelihood of conflicting configurations.

      See Creating a WebLogic Domain in .

    • Modify an existing domain to use secured production mode.

      See Changing the Domain Mode.

  2. Choose one of the options for starting an Administration Server as described in Starting and Stopping Servers in .

    You may want to create a boot identity file to store user credentials for starting and stopping an instance of WebLogic Server. See Creating a Boot Identity File for an Administration Server in . If you choose to create a boot identity file, then make sure to set appropriate permissions on the boot.properties file and its containing folder, DOMAIN_HOME/servers/AdminServer/security/. We recommend setting chmod 600 on boot.properties and chmod 740 for DOMAIN_HOME/servers/AdminServer/security.

  3. Connect to the domain using WebLogic Remote Console as described in Connect to an Administration Server in .

    The default address of your Administration Server is now https://hostname:9002. Note the s in https and the port number.

    In secured production mode, the non-SSL/TLS listen port (typically 7001) is disabled by default and traffic is routed over the SSL/TLS ports. If you want to configure listen ports, see Specify Listen Ports in .

  4. Make sure that WebLogic Server is not using the demo keystores provided by the Oracle Platform Security Services (OPSS) Keystore Service (KSS).
    1. In WebLogic Remote Console, in the Edit Tree, go to Environment, then Domain.
    2. On the Security tab, click Show Advanced Fields.
    3. Turn off the Use KSS for Demo option.
    4. Click Save.
  5. Make sure that SSL/TLS is configured properly, as described in Set Up TLS in .
  6. Save and commit your changes and then restart the Administration Server.
  7. If your domain includes Managed Servers, and you plan to use WebLogic Remote Console to start them, perform these steps too:
    1. Ensure Node Manager is configured properly to work with WebLogic Remote Console, as described in Start Managed Servers in .
    2. Add UseKSSForDemo=False to the nodemanager.properties file.
    3. Optional: If multiple server instances run on the same computer in the domain and the domain-wide administration port is enabled, then you must perform one of the following:
      • Host the server instances on a multi-homed machine and assign each server instance a unique listen address
      • Override the domain-wide port on all but one of the servers instances on the machine. On the Environment: Servers: myServer page for each managed server, enter a unique port value in the Local Administration Port Override field.
    4. Save and commit your changes.
    5. Start the Managed Server.
Using WLST on Domains using Demo Keystores

When using WLST, you must perform additional configuration to support the use of the insecure demo keystores in domains with secured production mode enabled.

  1. Start the Administration Server.

    You may want to create a boot identity file to store user credentials for starting and stopping an instance of WebLogic Server. See Creating a Boot Identity File for an Administration Server in . If you choose to create a boot identity file, then make sure to set appropriate permissions on the boot.properties file and its containing folder, DOMAIN_HOME/servers/AdminServer/security/. We recommend setting chmod 600 on boot.properties and chmod 740 for DOMAIN_HOME/servers/AdminServer/security.

  2. Update the WLST_PROPERTIES environment variable to configure keystores:
    export WLST_PROPERTIES="-Dweblogic.RootDirectory=DOMAIN_HOME -Dweblogic.security.TrustKeyStore=DemoTrust"

    If you receive a host name verification error, and you cannot specify the host name in the URL to match the certificate, then you can add -Dweblogic.security.SSL.ignoreHostnameVerification=true to the WLST_PROPERTIES environment variable. This will bypass the host name verification.

  3. Connect to the domain using the WLST as described in Invoking WLST in .

    Note:

    The default address of an Administration Server in secured production mode is t3s://hostname:9002. Note the s in t3s and the port number.

Starting Managed Servers using Demo Keystores using a Start Script

If your domain is using demo keystores, you can start Managed Servers using a start script.

  1. Create a boot identity file for each Managed Server. See Creating Boot Identity Files for Managed Servers in .
    Make sure to set appropriate permissions on the file and its containing folder. We recommend setting chmod 600 on the boot.properties file and chmod 740 for the folder, DOMAIN_HOME/servers/managedServerName/security/. If a boot.properties file is not available, then you must include a username and password when starting servers from the command line.
  2. Run the startManagedWebLogic script as described in Starting Managed Servers with a Startup Script in .

    For example:

    startManagedWebLogic.sh managedServerName https://adminHostname:adminPort
Stopping Servers with Demo Keystores
  • To shut down a server instance from WebLogic Remote Console, see Stop a Server in .
  • To shut down a server instance with a script, see Shutting Down Servers with a Stop Script in .

    Note:

    • If you have not added arguments for your keystores to the JAVA_OPTIONS environment variable, then you must include them when stopping the server.

    • If you do not have a boot.properties file configured, then you will need to include the username and password at the command line.

    • If you want to use HTTPS instead of T3s as the protocol in the domain URL , you must enable tunnelling and default internal servlets. Set ServerMBean.TunnelingEnabled to true and ServerMBean.DefaultInternalServletsDisabled to false.

    For example:

    export JAVA_OPTIONS="-Dweblogic.security.TrustKeyStore=DemoTrust"
stopManagedWebLogic.sh managedServerName t3s://adminHostname:adminPort [wlsUsername wlsPassword]
# To stop the Administration Server
export ADMIN_URL="t3s://adminHostname:adminPort" 
stopWebLogic.sh [wlsUsername wlsPassword]

Using Secured Production Mode with Demonstration Keystores with KSS

If you plan to use the insecure demo keystores provided through the Keystore Service(KSS) in a domain that has secured production mode enabled, then you may need to perform additional configuration before you can start your domain.

The Oracle Platform Security Service (OPSS) Keystore Service (KSS) provides a central management and storage of keys and certificates for all servers in a domain. See Configuring Oracle OPSS Keystore Service.

The OPSS KSS is only available with the JRF template and is not available to the default WebLogic Server configuration. Some of the following settings are already configured by the JRF template by default. If you have not modified those default values, you may be able to skip certain steps, such as configuring SSL/TLS or explicitly enabling KSS.

Note:

The following procedures are suitable for testing and development purposes only. Do not use demo keystores in a true production environment.

For production environments, refer to Connecting to the Administration Server using WebLogic Remote Console or Connecting to the Administration Server using WLST instead.

  1. Set the domain mode to secured production mode using one of the following methods:

    • Create a new domain and select secured production mode as the domain mode when prompted.

      Creating a new domain allows you to configure many of the settings that are necessary for secured production mode in a single procedure and reduces the likelihood of conflicting configurations.

      See Creating a WebLogic Domain in .

    • Modify an existing domain to use secured production mode.

      See Changing the Domain Mode.

  2. Choose one of the options for starting an Administration Server as described in Starting and Stopping Servers in .

    You may want to create a boot identity file to store user credentials for starting and stopping an instance of WebLogic Server. See Creating a Boot Identity File for an Administration Server in . If you choose to create a boot identity file, then make sure to set appropriate permissions on the boot.properties file and its containing folder, DOMAIN_HOME/servers/AdminServer/security/. We recommend setting chmod 600 on boot.properties and chmod 740 for DOMAIN_HOME/servers/AdminServer/security.

  3. Connect to the domain using WebLogic Remote Console as described in Connect to an Administration Server in .

    The default address of your Administration Server is now https://hostname:9002 . Note the s in https and the port number.

    In secured production mode, the non-SSL/TLS listen port (typically 7001) is disabled by default and traffic is routed over the SSL/TLS ports. If you want to configure listen ports, see Specify Listen Ports in .

  4. Make sure WebLogic Server is using the demo keystores provided by KSS.
    1. In WebLogic Remote Console, in the Edit Tree, go to Environment, then Domain.
    2. On the Security tab, click Show Advanced Fields.
    3. Turn on the Use KSS for Demo option.
    4. Click Save.
  5. Configure SSL/TLS as described in Set Up TLS in .
  6. Enable host name verification, as described in Enable Host Name Verification in .
  7. Save and commit your changes and then restart the Administration Server.
  8. If your domain includes Managed Servers, and you plan to use WebLogic Remote Console to start them, perform these steps too:
    1. Ensure Node Manager is configured properly to work with WebLogic Remote Console, as described in Start Managed Servers in .
    2. Add UseKSSForDemo=true to the nodemanager.properties file.
    3. Add startup arguments for your keystores for the Managed Server, as described in Configure Startup Arguments for a Managed Server in .

      Add -Dweblogic.ssl.AcceptKSSDemoCertsEnabled=true

    4. If multiple server instances run on the same computer in the domain and the domain-wide administration port is enabled, then you must perform one of the following:
      • Host the server instances on a multi-homed machine and assign each server instance a unique listen address
      • Override the domain-wide port on all but one of the servers instances on the machine. On the Environment: Servers: myServer page for each managed server, enter a unique port value in the Local Administration Port Override field.
    5. Save and commit your changes.
    6. Start the Managed Server.
Using WLST on Domains using Demo Keystores with KSS

When using WLST, you must perform additional configuration to support the use of the insecure demo keystores in domains with secured production mode enabled.

  1. Start the Administration Server.

    You may want to create a boot identity file to store user credentials for starting and stopping an instance of WebLogic Server. See Creating a Boot Identity File for an Administration Server in . If you choose to create a boot identity file, then make sure to set appropriate permissions on the boot.properties file and its containing folder, DOMAIN_HOME/servers/AdminServer/security/. We recommend setting chmod 600 on boot.properties and chmod 740 for DOMAIN_HOME/servers/AdminServer/security.

  2. Update the WLST_PROPERTIES environment variable to configure keystores:
    export WLST_PROPERTIES="-Dweblogic.security.SSL.trustedCAKeyStore=WL_HOME/server/lib/DemoTrust.jks -Dweblogic.ssl.AcceptKSSDemoCertsEnabled=true"
  3. Connect to the domain using the WLST as described in Invoking WLST in .

    Note:

    The default address of an Administration Server in secured production mode is t3s://hostname:9002. Note the s in t3s and the port number.

Starting Managed Servers using Demo Keystores with KSS using a Start Script

If your domain is using demo keystores with KSS, you can start Managed Servers using a start script.

  1. Create a boot identity file for each Managed Server. See Creating Boot Identity Files for Managed Servers in .
    Make sure to set appropriate permissions on the file and its containing folder. We recommend setting chmod 600 on the boot.properties file and chmod 740 for the folder, DOMAIN_HOME/servers/managedServerName/security/. If a boot.properties file is not available, then you must include a username and password when starting servers from the command line.
  2. Run the startManagedWebLogic script, adding -Dweblogic.ssl.AcceptKSSDemoCertsEnabled=true. The Managed Server start script is described in Starting Managed Servers with a Startup Script in .

    For example:

    startManagedWebLogic.sh managedServerName https://adminHostname:adminPort -Dweblogic.ssl.AcceptKSSDemoCertsEnabled=true
Stopping Servers with Demo Keystores with KSS
  • To shut down a server instance from WebLogic Remote Console, see Stop a Server in .
  • To shut down a server instance with a script, see Shutting Down Servers with a Stop Script in .

    Note:

    • If you have not added arguments for your keystores to the JAVA_OPTIONS environment variable, then you must include them when stopping the server.

    • If you do not have a boot.properties file configured, then you will need to include the username and password at the command line.

    • If you want to use HTTPS instead of T3s as the protocol in the domain URL , you must enable tunnelling and default internal servlets. Set ServerMBean.TunnelingEnabled to true and ServerMBean.DefaultInternalServletsDisabled to false.

    For example:

    export JAVA_OPTIONS="-
Dweblogic.security.SSL.trustedCAKeyStore=WL_HOME/server/lib/DemoTrust.jks -
Dweblogic.ssl.AcceptKSSDemoCertsEnabled=true"
# To stop a Managed Server
./stopManagedWebLogic.sh managedServerName t3s://adminHostname:adminPort [wlsUsername 
wlsPassword]
# To stop the Administration Server
export ADMIN_URL="t3s://adminHostname:adminPort"
./stopWebLogic.sh [wlsUsername wlsPassword]

Using Secured Production Mode without SSL/TLS

By default, when domains in secured production mode start, they use the default SSL/TLS and Administration Channel. If your domain or its start mechanism is not configured properly, you will not be able to connect. However, you can modify the domain to disregard the SSL/TLS requirements.

  1. In WebLogic Remote Console, in the Edit Tree, go to Environment, then Domain.
  2. Turn on the Listen Port Enabled option.
  3. Turn off the Enable Administration Port option.
  4. Turn off the SSL Enabled option.
  5. Click Save.
  6. If your domain contains clusters, then go to Environment, then Clusters. On each cluster, make the following change:
    1. On the Replication tab, turn off Secure Replication Enabled.
    2. Click Save.
  7. Commit your changes.
  8. Restart your Administration Server and all of your Managed Servers.

You can also use WLST Offline to disable the SSL/TLS requirements. See Example: Disabling TLS/SSL on a Domain in Secured Production Mode in .