2.3.6 Encryption of JP1/AJS3 communications with SSL

Messages communicated between JP1/AJS3 hosts can be encrypted with SSL. Encrypting messages helps prevent information being intercepted and compromised. Note, however, that some types of communications, such as communications with the destination agents of a flexible job, cannot be encrypted. Use other means to ensure the security of communications.

This subsection gives an overview of SSL and the general procedure for setting up SSL.

Organization of this subsection

(1) Basic terminology for SSL communications
(2) Overview of JP1/AJS3 SSL communications
(3) Server certificate and root certificate in manager/agent system configurations
(4) The general procedure for setting server certificates and root certificates in a manager/agent system configuration
(5) Server certificates and root certificates on a Web Console server
(6) The general procedure for setting a server certificate and a root certificate in an environment that includes a Web Console server
(7) Cautionary notes on SSL communications

(1) Basic terminology for SSL communications

The following table describes basic terminology for SSL communications.

Table 2‒28: Basic terminology for SSL communication
No.	Terms	Description
1	SSL (Secure Sockets Layer)	A protocol for sending and receiving encrypted information over the network. By implementing certificate authentication and key exchange between a client and a server, you can encrypt communications.
2	TLS (Transport Layer Security)	A protocol that includes improvements to SSL. The protocol name was changed to TLS with SSL 3.0 being the last version named SSL. In this manual, the term SSL includes TLS.
3	OpenSSL	An SSL library developed and provided as open source that supports SSL or TLS.
4	CA (Certificate Authority)	A certificate authority (CA) that issues certificates required for using SSL. There are two types of CAs: Root CA A root CA self-certifies the validity of itself. Intermediate CA An intermediate CA certifies the validity of itself by certification provided by a higher-level CA other than a root CA.
5	CSR (Certificate Signing Request)	A certificate signing request (CSR) required for the issuance of a server certificate. A CSR contains information such as a public key, and the organization name and location of the requester. A CSR is submitted to a CA, which then signs the CSR and issues a server certificate.
6	Server certificate	Electronic information that certifies the validity of the requester organization of a CSR.
7	Root certificate	A certificate issued by a root CA to certify its own validity. A root certificate is used to verify the validity of the CA that issued a server certificate.
8	Intermediate certificate	A certificate issued by an intermediate CA to certify its own validity. An intermediate certificate in combination with a root certificate certifies the validity of the CA that issued a server certificate.
9	CN (Common Name)	A piece of information registered in a server certificate, which refers to a domain name (host name) of the server to which the server certificate is applied.
10	SAN (Subject Alternative Names)	A piece of information registered in a server certificate, which indicates information that is used as an alternative name for the CN. Because a SAN can have multiple values, specifying a SAN enables SSL communications with multiple connection destinations by using a single server certificate.
11	Wildcard certificate	A type of server certificate with an asterisk (``) specified in the host name part of a CN or SAN. This enables SSL communications with different connection destinations with different host names on the same domain by using a single server certificate. The use of a wildcard certificate is allowed for JP1/AJS3 SSL communication. Note that an asterisk (``) can be used only at the beginning of a CN or SAN (in the host name part). You cannot use an asterisk (``) in any other part. In addition, you cannot use a regular expression such as `a` to mean "a host name starting with `a`". For example, if a CN is set to `*.example.com`, such a single server certificate supports multiple host names as follows: aaa.example.com bbb.example.com

To Page Top

(2) Overview of JP1/AJS3 SSL communications

The messages communicated between each component of JP1/AJS3 can be encrypted by using SSL communications. This functionality is called the communication encryption function. The communication encryption function can be enabled or disabled for each component. In JP1/AJS3 - Manager, JP1/AJS3 - Agent, JP1/AJS3 - View, and JP1/AJS3 - Web Console, the communication encryption function must either be enabled or disabled on both components that communicate with each other. Note that you can specify INETD for the environment setting parameter AJS3SSL to disable the communication encryption function for communications between JP1/AJS3 - Manager and JP1/AJS3 - Agent. In that case, the communications are disabled even if the communication encryption function is enabled for communications between JP1/AJS3 - View and JP1/AJS3 - Manager.

The following describes the communication encryption function for each component.

JP1/AJS3 - Manager

If you enable the communication encryption function in JP1/AJS3 - Manager, communications between another instance of JP1/AJS3 - Manager, JP1/AJS3 - Agent, JP1/AJS3 - View, and JP1/AJS3 - Web Console are encrypted.

To enable the communication encryption function in JP1/AJS3 - Manager, you must specify settings in JP1/Base. If the communication encryption function is enabled, messages sent from JP1/AJS3 - Manager are encrypted by OpenSSL on JP1/Base.

For details about JP1/Base SSL communications, see the description of the communication encryption function in the JP1/Base User's Guide.

JP1/AJS3 - Agent

The communication encryption function in JP1/AJS3 - Agent can be used to encrypt communications between JP1/AJS3 - Manager.

To enable the communication encryption function in JP1/AJS3 - Agent, setting must be made in JP1/Base. If the communication encryption function is enabled, messages sent from JP1/AJS3 - Agent are encrypted by OpenSSL on JP1/Base.

For details on JP1/Base SSL communication, see a description on the communication encryption function in the JP1/Base User's Guide.

JP1/AJS3 - View

The communication encryption function in JP1/AJS3 - View can be used to encrypt communications with JP1/AJS3 - Manager.

To enable the communication encryption function in JP1/AJS3 - View, you must edit the file that specifies the names of the hosts that use non-encrypted communications (nosslhost.conf) on JP1/AJS3 - View and enable the communication encryption function.

JP1/AJS3 - Web Console

The communication encryption function in JP1/AJS3 - Web Console can be used to encrypt the following communications:

Communications between JP1/AJS3 - Web Console and JP1/AJS3 - Manager

To encrypt communications between JP1/AJS3 - Web Console and JP1/AJS3 - Manager, edit the file that specifies the names of the hosts that use non-encrypted communications (nosslhost.conf) on JP1/AJS3 - Web Console and enable the communication encryption function.
Communications between a web browser and JP1/AJS3 - Web Console

To encrypt communication between a web browser and JP1/AJS3 - Web Console, a server certificate and a private key are required.

You must also enable SSL communications on client programs such as Web GUI and user applications using a web browser or other settings.

Note that the following communications are excluded from the JP1/AJS3 communication encryption function. Use other means to ensure the security of communications.

Communications with a destination agent for a flexible job
Communications between JP1/AJS3 - Print Option Manager and JP1/AJS3 - Print Option
Communications between the execution agent of an HTTP connection job and the HTTP connection destination (web-based business system)
Communications between the execution agent of an email sending job for which Outlook is not used and an SMTP or POP3 server
Communications between JP1/AJS3 - Manager and a linked product that does not support the communication encryption function

Examples of other means to ensure the security of communications:

Using VPN
Enabling HTTPS communications in the settings for an HTTP connection job

The following communications are also excluded from the JP1/AJS3 communication encryption function, but are not at risk of interception.

Local host communications within JP1/AJS3 - Manager or JP1/AJS3 - Agent, which uses a port that is not used for communications with other hosts.

The following figure shows the communications that can be covered by the communication encryption function.

Figure 2‒27: Communications covered by the communication encryption function

Cautionary notes

If SSL communications are enabled on one component and disabled on the other component, those components cannot communicate each other. Either enable or disable SSL communication on both components that communicate with each other.
The only encryption protocol supported by the JP1/AJS3 communication encryption function is TLS version 1.2. No other protocol or version is supported.
If you enable the communication encryption function of a JP1/AJS3 product, remember that the product becomes unable to link with versions of JP1/AJS3 products or with other products that do not support the communication encryption function. To link with such products, disable the communication encryption function.

To Page Top

(3) Server certificate and root certificate in manager/agent system configurations

To encrypt a message transferred between a manager host and an agent host with SSL, a server certificate is required for the server-side host, and a root certificate is required for the client-side host.

In manager/agent system configurations, the side that sends a processing request is called a client, and the destination of the request is called a server. In other words, from a manager host's perspective, the local host that sends a job execution request is the client, and the destination agent host is the server. Conversely, from an agent's host perspective, the local host that sends job execution results is the client, and the destination manager host is the server. Therefore, a manager and an agent each require a server certificate and a root certificate.

Because a manager host also communicates with the local host, a root certificate that corresponds to its own server certificate is also required.

The following figure shows how server certificates and root certificates are placed in a manager/agent system configuration.

Figure 2‒28: Placement of server certificates and root certificates in a manager/agent system configuration

The following describes a combination of certificates to be issued by the same CA. The numbers in the figure correspond to the numbers in the following list.

For the manager host, the agent host is the server and the manager host itself is the client. Therefore, server certificate A is required on the agent host and root certificate A is required on the manager host.
For the agent host, the manager host is the server and the agent host itself is the client. Therefore, root certificate M is required on the agent host and server certificate M is required on the manager host.
The manager host also communicates with the local host, so root certificate M, which corresponds to its own server certificate M, is required. However, if server certificate A and server certificate M are issued by the same CA, root certificate M and root certificate A will be the same. In such a case, it is not necessary to obtain root certificate M separately and place it on the manager host.
For the JP1/AJS3 - View host, the manager host is the server, and the JP1/AJS3 - View host is the client. Therefore, root certificate M, which corresponds to the manager host's server certificate M, is required.

As above, in a manager/agent system configuration, all the manager hosts and agent hosts require server certificates and root certificates, and JP1/AJS3 - View hosts require root certificates.

To Page Top

(4) The general procedure for setting server certificates and root certificates in a manager/agent system configuration

Request issuance of a server certificate and a root certificate to a CA. The following figure shows the general procedure for obtaining and setting the server certificates and root certificates.

Figure 2‒29: The general procedure for obtaining and setting a server certificate and a root certificate

If there are multiple manager hosts and agent hosts, perform this procedure on all combinations of manager hosts and agent hosts that communicate with each other. If there are multiple JP1/AJS3 - View hosts, perform the client host procedure on all the JP1/AJS3 - View hosts.

For details about settings, see 21.4.2 SSL communication setup procedure (in a manager/agent configuration) in the JP1/Automatic Job Management System 3 Configuration Guide.

To Page Top

(5) Server certificates and root certificates on a Web Console server

When a Web Console server is used, communications for the following hosts must be encrypted besides encrypting the communications between the manager hosts, agent hosts, and JP1/AJS3 - View hosts.

Communications between the Web Console server and manager hosts
Communications between a web browser and the Web Console server

How a certificate is obtained and placed on each host depends on whether the Web Console server and the manager host are installed on different hosts or on the same host.

(a) When the Web Console server and the manager host are installed on different hosts

The manager host and the agent host require a server certificate and a root certificate. The server certificate is obtained by using OpenSSL on JP1/Base.

The Web Console server requires a root certificate to verify the server certificate on the manager host. The Web Console server also requires a server certificate to connect with a client such as a web browser using SSL communications. The server certificate is obtained by using JP1/AJS3 - Web Console functionality.

The following figure shows the placement of server certificates and root certificates when the Web Console server and the manager host are installed on different hosts.

Figure 2‒30: Placement of server certificates and root certificates when the Web Console server and the manager host are installed on different hosts

The manager host and agent host require a combination of server certificates and root certificates similar to the one in a manager/agent system configuration (1 to 3 in the figure). The Web Console server that communicates with the manager host requires root certificate M to verify the manager host's server certificate M (4 in the figure).

For the Web Console server to communicate with the client host with SSL, the Web Console server requires the server certificate W (5 in the figure).

If the same CA issues the server certificates of the hosts, root certificate A and root certificate M will be the same file. It is not necessary to obtain these certificates separately or place them in the manager host separately.

(b) When the Web Console server and the manager host are installed on the same host

The manager host and the Web Console server share a server certificate. The server certificate is obtained by using either JP1/Base or JP1/AJS3 - Web Console.

Cautionary note: When JP1/AJS3 - Web Console and JP1/AJS3 - Manager are installed on the same server (machine) but on a different host, a server certificate cannot be shared. See (a) When the Web Console server and the manager host are installed on different hosts and obtain a server certificate for each host.

■ When using JP1/Base to obtain a server certificate

Use JP1/Base OpenSSL to obtain a server certificate and copy it to a folder of JP1/AJS3 - Web Console.

The following figure shows the placement of server certificates and root certificates when the Web Console server and the manager host are installed on the same host and JP1/Base is used to obtain a server certificate.

Figure 2‒31: When the Web Console server and the manager host are installed on the same host (using JP1/Base)

The manager host and agent host require a combination of server certificates and root certificates similar to the one in a manager/agent system configuration (1 to 3 in the figure). JP1/AJS3 - Web Console that communicates with the manager host requires the root certificate M to verify the manager host's root certificate M (4 in the figure).

For JP1/AJS3 - Web Console to communicate with a client host with SSL, JP1/AJS3 - Web Console requires a server certificate. Copy the server certificate M in the folder of JP1/AJS3 - Web Console (5 in the figure). For SSL communications with the client host, the copied server certificate M is used (6 in the figure).

■ When using JP1/AJS3 - Web Console to obtain a server certificate

Use JP1/AJS3 - Web Console functionality to create a CSR. Use the CSR to obtain a server certificate, store the certificate in a folder of JP1/AJS3 - Web Console, and specify the path to the server certificate in the JP1/Base common definition information.

The following figure shows the placement of server certificates and root certificates when the Web Console server and the manager host are installed on the same host and JP1/AJS3 - Web Console is used to obtain a server certificate.

Figure 2‒32: When the Web Console server and the manager host are installed on the same host (using JP1/AJS3 - Web Console)

For JP1/AJS3 - Web Console to communicate with a client host with SSL, JP1/AJS3 - Web Console requires a server certificate. Use JP1/AJS3 - Web Console functionality to obtain the server certificate W, and place it in a folder of JP1/AJS3 - Web Console. For SSL communication between JP1/AJS3 - Web Console and the client host, the server certificate W is used (1 in the figure).

Specify the path to server certificate W in the JP1/Base common definition information (2 in the figure). Store root certificate W, which corresponds to server certificate W, in JP1/Base and in the agent host (2 and 3 in the figure). Also store the root certificate W in JP1/AJS3 - Web Console that communicates with the manager host (4 in the figure). As in a manager/agent system configuration, the agent host requires the server certificate A and the manager host (JP1/Base) requires the root certificate A (5 in the figure).

To Page Top

(6) The general procedure for setting a server certificate and a root certificate in an environment that includes a Web Console server

Basically, the general procedure for setting the server certificates and root certificates in an environment that includes a Web Console server is the same as (4) The general procedure for setting server certificates and root certificates in a manager/agent system configuration. However, how a CSR and a private key is created and how and where the obtained server certificate is placed depends on the system configuration of the Web Console server and manager host.

For details, see 21.4.1 JP1/AJS3 system configuration and SSL communication setup procedure in the JP1/Automatic Job Management System 3 Configuration Guide.

To Page Top

(7) Cautionary notes on SSL communications

The following provides cautionary notes on SSL communications.

(a) Cautionary notes on certificates

If verification of a server certificate fails, the communications processing stops causing an error.
A server certificate or a root certificate has an expiration date. Manage the certificates in the proper method and complete the replacement procedure before they expire. The expiration of a certificate is judged by the system time. It is not related to a local date and time of the scheduler service. The following shows the communications behavior if the certificate has expired:
- For the communication between JP1/AJS3 - Manager and JP1/AJS3 - Agent, encryption is performed even if the certificate has expired. No job executions fail. However, a warning message is output once per day. This warning message is not output for queueless jobs.
- For the communication between JP1/AJS3 - View and JP1/AJS3 - Manager, if the certificate has expired, you cannot log in from JP1/AJS3 - View to JP1/AJS3 - Manager.
- For the communication between JP1/AJS3 - Web Console and JP1/AJS3 - Manager, if the certificate has expired, you cannot log in from the Web GUI to JP1/AJS3 - Manager. However, for the communication between the web browser and JP1/AJS3 - Web Console, the Web GUI can be displayed in the web browser even if the certificate has expired.

(b) Cautionary notes on setting a CN and SAN

The following provides cautionary notes on setting a CN or SAN.

The JP1/AJS3 communication encryption function checks both CN and SAN to prevent server spoofing. However, CN and SAN are not checked for communications in a single host. In addition, the CN is not checked if a SAN is specified. Therefore, specify the same value for the SAN and CN if a SAN is specified.
Specify a host name for the CN or SAN. Do not specify an IP address.
If a wildcard certificate is used, an asterisk (*) can be used only at the beginning of the CN or SAN (host name part). You cannot use an asterisk (*) in any other part. In addition, you cannot use a regular expression such as a* to mean "a host name starting with a". For example, *.example.com can be set as CN or SAN, but a*.example.com or test.*.com cannot.
If you use an alias host name to specify a host, specify the name as the SAN.
If you use a short name for a host name, specify both the short name and the FQDN as the SAN. If you do not specify both names, job execution might end in error.
If host is specified for the environment setting parameter ResolveAgentInfo, when the manager host communicates with the agent host, it communicates with the real host as well as the execution target host saved as the execution agent information. Therefore, also specify the real host name of the agent host in the SAN.
If you perform a definition pre-check or queueless job in a logical host environment, specify the physical host name and all the logical host names on the physical host for the SAN in the server certificate on the physical host.

The definition pre-check function and a queueless job service are processed by a process on a physical host. If the process is requested from a logical host, the server certificate of the physical host is sent to the client. This is why the physical host name and logical host name must be specified for the SAN in the server certificate on the physical host.

(c) Cautionary notes when the SSL enabled/disabled state differs between the physical host and the logical host

The following provides cautionary notes when the SSL enabled/disabled state differs between the physical host and the logical host.

■ If the manager host or authentication server is installed as a logical host

The SSL communication enabled/disabled status of the manager host and authentication server must match between both hosts. If the SSL communication enabled/disabled status does not match between the manager host and the authentication server, you cannot log in to JP1/AJS3 - Manager from JP1/AJS3 - View or Web GUI.

The following describes an example when the manager host or authentication server is installed as a logical host.

Figure 2‒33: Example when the manager host or authentication server is installed as a logical host

This figure assumes that JP1/AJS3 - Manager and JP1/Base is installed on all the physical hosts and logical hosts.

Because SSL communications are enabled on hostA, hostB can be set as the authentication server for hostA. hostA-L and hostB-L, on which SSL communications are disabled, cannot be set as the authentication server.

On the other hand, because SSL communications are disabled on hostA-L, hostB-L can be set as the authentication server for hostA-L. hostA and hostB, on which SSL communications are disabled, cannot be set as the authentication server.

■ If the definition pre-check function is used

If the definition pre-check function is used, SSL communications are enabled or disabled as per the settings on the physical host. Therefore, the SSL communication enabled/disabled status must match on the physical hosts for the pre-check requester host and execution destination host.

The following describes an example when the definition pre-check function is used.

Figure 2‒34: Example when the definition pre-check function is used

In this figure, the hostA or hostC is a pre-check requester host, and hostB or hostD is a pre-check execution destination host.

The SSL communication settings for the physical hosts, hostA and hostB, are the same. Therefore, for example, when hostA-L requests a pre-check to hostB, the pre-check function performs successfully even though the SSL communication for the requester host does not match. Similarly, when hostA requests a pre-check to hostA-L, the pre-check function performs successfully.

On the other hand, the SSL communication settings for the physical host, hostC and hostD, are not the same. Therefore, for example, when hostC-L requests a pre-check to hostD, the pre-check function ends in error even though the SSL communication setting for the requester host matches.

■ If a queueless job is executed

If a queueless job is executed, SSL communications are enabled or disabled on the queueless job execution requester as specified on both the logical host and the physical host. On the other hand, the SSL communication settings on the execution destination queueless agent follows the settings on the physical host regardless of whether it is a logical host or physical host. If the SSL communication settings differ between the execution requester and the execution destination, a queueless job cannot perform successfully. Specify the same SSL communication enabled/disabled status for the execution requester and the execution destination.

The following describes an example when a queueless job can be executed.

Figure 2‒35: Example when a queueless job can be executed

In this figure, the queueless job execution requester is a physical host, hostA. SSL communication on the execution requester is enabled, in accordance to hostA. At this time, the queueless job execution destination has the same SSL communication setting with the execution requester. The queueless job execution destination can be any of hostA (local host), hostA-L, hostB, or hostB-L because SSL communications are enabled on their physical hosts (hostA and hostB). Therefore, a queueless job can be executed.

On the other hand, the following figure shows an example when a queueless job cannot be executed.

Figure 2‒36: Example when a queueless job cannot be executed

In this figure, the queueless job execution requester is a logical host, hostA-L. SSL communication on the execution requester is disabled, in accordance with hostA-L. However, whether the queueless job execution destination is any of hostA (local host), hostA-L, hostB, or hostB-L, SSL communication settings differ between the execution requester and the execution destination. This is because SSL communications are enabled on their physical hosts (hostA and hostB). Therefore, a queueless job continues to be in a wait status and is not executed. If you want to end a queueless job in a wait status, change the status of the queueless job.

To Page Top