TLS Certificate Security
ActiveBatch provides both non-encrypted and TLS encrypted communications between the Job Scheduler and its Execution Agents. This section will instruct you as to how to configure and then use the TLS level security. By default, TLS encryption is disabled.
Default Job Scheduler TLS Setting
To enable a default for the Job Scheduler to either not-use/conditionally-use or must-use TLS encryption concerning communications between the Job Scheduler and its Execution Agents the following Registry key and value-name should be created.
HKLM\Software\ASCI\ActiveBatch\V140\JobSched\Services\ExecutionAgent
TlsUse(DWORD): 0
Possible values are: zero (0) TLS disabled. One (1) TLS used when possible. Two (2) TLS must be used. A value of zero (0) is the default and means that no encryption will be performed when the ActiveBatch services communicate. A value of one (1) means that TLS will be negotiated first when attempting to communicate. If TLS cannot be established then the default failover will use no TLS encryption. Finally, a value of two (2) indicates that TLS encryption must be used. If TLS encrypted communications cannot be achieved, no communications channel will be initiated.
Note: A value of zero (0) simply means that you have control over whether a particular communications session between the Job Scheduler and an Execution Machine can be encrypted or not.
Windows Execution Agent Certificate
Note: This section is only applicable if you want to enforce Certification Validation for the purposes of machine identity OR the machine is non-Windows based. For Windows system, if you solely want to use TLS to encrypt all communications you do not need to create any certificates. By default, ActiveBatch will create its own self-signed certificates for that use.
You can optionally indicate that the Execution Agent’s identity is to be verified by ensuring that a certificate must be present and validation enforced. The Registry Keys in this section would be created on the Execution Machine. The following Registry Key and value-name is used to establish a certificate for an Execution Agent.
HKEY_LOCAL_MACHINE\SOFTWARE\ASCI\ActiveBatch\V140\ExecAgent\ServerCertificate (reg_sz) = .
To create a Certificate you would use the Certificates snap-in and Request a New Certificate. The certificate would be issued using the FQDN of the Job Scheduler machine (i.e. computer.domain.com means “computer” for host name and “domain.com” for the domain). The Certificate must be stored under the Windows LocalMachine certificate store.
By default, no certificate trust is enabled. To enable a certificate trust, create the following Registry Key and Value-name:
HKEY_LOCAL_MACHINE\SOFTWARE\ASCI\ActiveBatch\V140\JobSched\Services\ExecutionAgent
ServerCertificate(REG_SZ): ValidationMode=ChainTrust
You would then connect to the Execution Agent using the FQDN of the Agent machine in the “Machine” property.
To enable TLS at the Execution Agent level, create the following Registry Key and value-name:
HKLM\Software\ASCI\ActiveBatch\V140\ExecAgent
TlsUse(DWORD): 0
Job Scheduler Certificate
Note: This section is only applicable if you want to enforce Certification Validation for the purposes of machine identity. If you solely want to use TLS to encrypt all communications you do not need to create any certificates. By default, ActiveBatch will create its own self-signed certificates for that use.
You can optionally indicate that the Job Scheduler’s identity is to be confirmed and certificate validation enforced. The Registry Keys in this section would be created on the Job Scheduler Machine. The following Registry Key and value-name is used to establish a certificate for the Job Scheduler.
HKEY_LOCAL_MACHINE\SOFTWARE\ASCI\ActiveBatch\V140\JobSched\Services\ExecutionAgent\ClientCertificate (reg_sz) = .
To create a Certificate you would use the Certificates snap-in and Request a New Certificate. The certificate would be issued using the FQDN of the Job Scheduler machine (i.e. computer.domain.com means “computer” for host name and “domain.com” for the domain). The Certificate must be stored under the Windows LocalMachine certificate store.
By default, no certificate trust is enabled. To enable a certificate trust, create the following Registry Key and Value-name:
HKEY_LOCAL_MACHINE\SOFTWARE\ASCI\ActiveBatch\V140\ExecAgent\ClientCertificate(REG_SZ): ValidationMode=ChainTrust
The above Registry value indicates the certificate chain is validated. If you are self-signing the certificate you would not create this Registry entry since the ValidationMode is “None” by default.
Non-Windows Execution Agent
For non-Windows Execution Agents your also need to enable TLS encryption as well as provide a certificate.
The configuration file (‘abatemgr.conf’) entry “UseTLS” would need to be created. This entry contains four (4) possible values:
0 – Indicates that TLS is disabled.
1 – Indicates that TLS is optional.
2 – Indicates that TLS is required.
3 – Indicates that TLS is required and that Certificate Validation is enforced.
Non-Windows Execution Agent Certificate
The sole purpose of creating an Execution Agent certificate is validation of the machine’s identity. You do not need to create any TLS certificates for the purposes of encryption. ActiveBatch will create its own self-signed certificates for that usage. To create a certificate on a UNIX/Linux system, OpenSSL is used.
OpenSSL provides tools for creating public/private keys and self-signed certificates. The following command creates a private key of size 4096 bits named $HOST.key, with a password as ABAB:
openssl genrsa -passout pass:ABAB -des3 -out $HOST.key 4096
The following will create a certificate to be signed by the certificate authority (CA):
openssl req -passin pass:ABAB -new -key $HOST.key -out $HOST.csr -config /BuildEnvironment/CA/config.$HOST
The config.$HOST file contains the following entries about the machine to be passed to the certificate. It is provided in the command above to prevent interactive questions:
[ req ]
|
default_bits |
= 1024 |
|
default_keyfile |
= keyfile.pem |
|
distinguished_name |
= req_distinguished_name |
|
attributes |
= req_attributes |
|
prompt |
= no |
|
output_password |
= mypass |
[req_attributes ]
|
challengePassword |
= A challenge password |
[ req_distinguished_name ]
|
C |
= US |
|
ST |
= NJ |
|
L |
= Morristown |
|
O |
= ASCI |
|
OU |
= Engineering |
|
emailAddress |
= user@advsyscon.com |
|
CN |
= liszt@advsyscon.com |
The last line (CN) is different for all machines and should be provided / modified while creating the certificate. If the command above is successful, $HOST.csr file will be created. This file will be used to create the actual certificate signed by the CA.
Signing the Certificate
All certificates require a CA to sign them (except for self-signed).
Before signing the certificate, a certificate request has to be created on the requeisting machine as follows:
openssl req -new -nodes -out $HOST-req.pem -keyout $HOST-key.pem -days 365 -config /CA/config.$HOST
The “-days” argument shows the validation period of the certificate. By default it is 1 year. This command creates $HOST-req.pem file, which should be used for signing the certificate, as follows:
openssl ca -out $HOST-cert.pem -passin pass:ABAB -days 365 -batch -config /CA/openssl.cnf -infiles $HOST-req.pem
This command will create $HOST-cert.pem file, which is the actual signed certificate. Both $HOST-cert.pem and $HOST-key.pem (created in the previous step) will be needed by the UNIX EAs.
If you want to use these certificates on Windows machines, you can create pkcs12 files as follows:
openssl pkcs12 -export -in $HOST-cert.pem -inkey $HOST-key.pem -certfile /CA/UNIX-CA.crt -name HOST.advsyscon.com -out $HOST-cert.p12
The script for the entire process is: [Note: Some word wrapping may have occurred.]
#!/bin/bash
HOST=`hostname`
# First create a private key and a certificate for the host
openssl genrsa -passout pass:ABAB -des3 -out $HOST.key 4096
cp /CA/config.bak /CA/config.$HOST
echo "CN = $HOST" >> /CA/config.$HOST
openssl req -passin pass:ABAB -new -key $HOST.key -out $HOST.csr -config /CA/config.$HOST
# Then create a signing request for the certificate
openssl req -new -nodes -out $HOST-req.pem -keyout $HOST-key.pem -days 365 -config /CA/config.$HOST
rm -f /CA/index.txt
touch /CA/index.txt
# Let the CA sign the certificate
openssl ca -out $HOST-cert.pem -passin pass:ABAB -days 365 -batch -config /CA/openssl.cnf -infiles $HOST-req.pem
#Finally create the PLCS12 file
openssl pkcs12 -export -in $HOST-cert.pem -inkey $HOST-key.pem -certfile /CA/UNIX-CA.crt -name $HOST.advsyscon.com -out $HOST-cert.p12
mv $HOST-cert.p12 /CA/pkcs12/.
mv $HOST-key.pem /CA/TLSFiles/.
mv $HOST-cert.pem /CA/TLSFiles/.
The following entries have to created within the abatemgr.conf file for certificate location.
TlsKeyFile=<full path to the *-key.pem file>
TlsCertificateFile=< full path to the *-cert.pem file>