SSL/TLS Peer Authentication
Overview
The SSL/TLS protocol utilizes X.509 certificates to perform peer authentication. For example, a Universal Command Manager may want to authenticate that it is connected to the correct Universal Broker.
Peer authentication is performed by either one or both of the programs involved in the network session. If a Manager wants to authenticate the Broker to which it connects, the Broker will send its certificate to the Manager for the Manager to authenticate. If the Broker wants to authenticate the Manager, the Manager sends its certificate to the Broker.
Certificate authentication is performed in the following steps:
- Check that the peer certificate is issued by a trusted CA.
- Check that the certificate has not been revoked by the CA.
- Check that the certificate identifies the intended peer.
If a step fails, the network session is terminated immediately.
Certificate Verification
The Universal Agent component must be configured with a list of trusted CA certificates. When a peer certificate is received, the trusted CA certificates are used to verify that the peer certificate is issued by one of the trusted CA's.
The trusted CA certificate list must be properly secured so that only authorized accounts have update access to the list. Should the trusted CA list become compromised, there is a possibility that an untrusted CA certificate was added to the list.
The CA certificate list configuration option is CA_CERTIFICATES. It specifies a PEM-formatted file that contains one or more CA certificates used for verification.
Should a peer certificate not be signed by a trusted CA, the session is immediately terminated.
Certificate Revocation
After a certificate is verified to have come from a trusted CA, the next step is to check if the CA has revoked the certificate. Since a certificate is held by the entity for which it identifies, a CA cannot take a certificate back after it is issued. So if a CA needs to revoke a certificate for some reason, it issues a list of revoked certificates referred to as the Certificate Revocation List (CRL). A program that validates certificates must have access to the latest CRL issued by the CA.
The CERTIFICATE_REVOCATION_LIST configuration option specifies the PEM-formatted file that contains the CRL. This option is available in all Universal Agent components that utilize certificates.
Certificate Identification
After a certificate is validated as being issued by a trusted CA, and has not been revoked by the CA, the next step is to check that it identifies the intended peer.
A Universal Agent Manager validates a Broker certificate by the Broker host name, IP address, or the certificate serial number. The VERIFY_HOST_NAME configuration option is used to specify the host name or IP address that is identified in the Broker certificate. Each certificate signed by a CA must have a unique serial number for that CA. The VERIFY_SERIAL_NUMBER option is used to specify the serial number in the Broker certificate.
If certificate identification fails, the session is immediately terminated.
Universal Brokers work differently than the Managers. A Broker maps a peer certificate to a certificate ID. The certificate map definitions are part of the Universal Access Control List (UACL) definitions. At that point, the certificate ID is used by UACL definitions to control access to Broker and Server services.
Certificate Support
Many certificate authority applications, also known as Public Key Infrastructure (PKI) applications, are available. Universal Agent should be able to utilize any certificate in a PEM-formatted file. PEM (Privacy Enhanced Mail) is a common text file format used for certificates, private keys, and CA lists.
Universal Agent support X.509 version 1 and version 3 certificates.
Although implementing a fully featured PKI infrastructure is beyond the scope of Universal Agent and this documentation, some assistance is provided using the OpenSSL toolkit.
Universal Agent on most of the supported platforms utilize the OpenSSL toolkit for its SSL/TLS and certificate implementation. OpenSSL is delivered on most UNIX distributions and Windows distributions and also is available on the OpenSSL website.
Universal Agent supports z/OS System SSL on the IBM z/OS operating system as well as OpenSSL. System SSL interfaces directly with the RACF security product for certificate access. All certificates, CA and user certificates, and private keys must be stored in the RACF database to use System SSL.
The Universal Agent suite includes an X.509 certificate utility, Universal Certificate, to create certificates for use in the Universal Agent suite.
Sample Set-up for Universal Command Peer Authentication of Universal Broker
Step 1 | Create a Self-Signed CA Request: |
---|---|
Step 2 | Create a CA Certificate: |
Step 3 | Create a Server Certificate Request: |
Step 4 | Create a Server Certificate: |
Step 5 | The following files are generated in Steps 1 - 4:
|
Step 6 | Add Server CERT and PKEY to the target
|
Step 7 | Copy |
Step 8 | Run the following command from the source server to test: |
Step 9 | Use Universal Certificate to print the certificate and verify the certificate serial number: |
Step 10 | Run following command from the source server to test: |
Certificate
Certificate: Data: Version: 3 (0x2) Serial Number: 28:c9:1a:7f:b2:f2:66:49 Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=GA, L=Alpharetta, O=Stonebranch, CN=Stonebranch Validity Not Before: Feb 8 21:08:12 2016 GMT Not After : Feb 6 02:08:12 2026 GMT Subject: C=US, ST=GA, L=Alpharetta, O=Stonebranch, CN=l64agent Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:d9:30:22:5b:b4:62:5c:d9:26:4b:16:02:cc:22: 65:b8:ed:89:2d:6e:94:f8:b4:51:2c:1b:b7:5b:63: 74:ce:c5:05:a6:a9:52:47:f2:56:5e:58:cd:f8:c6: a9:1d:54:a6:52:9f:5c:95:4f:27:db:bd:6f:ba:cc: 23:17:67:aa:3a:12:1b:21:97:32:ce:bf:22:c2:1c: 2d:4b:a5:c4:99:18:38:96:48:06:9b:2b:98:df:74: e3:92:af:86:21:75:ed:77:86:63:af:a2:71:c4:0e: a8:ac:1d:dc:26:65:b0:ed:b0:06:50:4b:da:e4:01: 7a:49:7e:9b:38:1d:c7:2d:57 Exponent: 3 (0x3) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: CA:8D:DB:15:B8:A9:42:EC:51:A2:B7:C3:19:76:F7:15:35:1D:C8:9E X509v3 Authority Key Identifier: DirName:/C=US/ST=GA/L=Alpharetta/O=Stonebranch/CN=Stonebranch serial:79:19:7A:72:ED:D5:1F:7B X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment Signature Algorithm: sha1WithRSAEncryption b0:b3:0d:8c:06:fe:4a:b0:e8:46:fd:8f:d8:64:d1:5e:11:b3: 68:43:34:28:08:4b:e0:62:39:c1:6c:06:76:f3:e5:9d:8c:4e: 15:57:56:d7:bf:92:f3:cf:6a:c8:36:54:28:2d:f9:9f:ad:67: 44:1a:2e:32:ad:8b:8a:a0:86:64:8d:73:a0:60:46:65:f0:62: 1f:02:db:c7:7c:99:db:ad:5b:80:3e:e9:b2:88:19:23:15:e6: 7a:1d:53:e3:51:60:2d:99:0c:20:08:5a:ae:0f:c8:d3:20:a4: 31:91:8b:a7:c2:c8:7a:ab:6c:2d:18:7a:1e:95:4b:c0:3e:5f: f9:cf