Sample SSL make* script certificate/key usage across XCOM partners
Article ID: 227732
Updated On:
Products
Issue/Introduction
Require assistance with the generation of new SSL certificates to allow for the secure transfer of data files from a Production XCOM AS/400 (IBM i) server to a partner Red Hat server. Planning to use the XCOM make* scripts/certificates, but need advice on how this needs to be done across the 2 servers.
Environment
Release : 11.0
Component : CA XCOM Data Transport for AS/400 i5/OS
Resolution
1. This is a Production environment and the sample makeca/server/client scripts provided are intended to be used to only confirm that the correct functioning of XCOM SSL/TLS can be verified, in particular with a loopback transfer, which validates both, the initiate/client and receive/server sides on just one server.
In a Production environment, the root (also called the Certificate Authority, CA) private key must not be shared, otherwise it’s a bit like "leaving the house keys in front of the door".
For an XCOM SSL transfer with certificate verifications to work, the certificates must have the same root certificate, a condition that is fulfilled for a loopback transfer. So, to generate a valid client/server certificate on a different server, and use the XCOM supplied make* facilities, that private key would need to be copied from one server to the other. If all partner XCOM servers are within the same internal network/organisation, then that might be acceptable from a security standpoint, otherwise, as per the above, it would be like "leaving the house keys in front of the door".
So the correct process is to decide who holds the root certificate private key. This could be one of the company’s security departments or an external CA (Certificate Authority) like Verisign. That entity would run makeca and keep the root private key secure, typically not giving it out to either of the servers. On those servers, a Certificate Signing Request (CSR) would be generated and sent to the entity, which ran makeca. With the CSR, that entity would generate client/server keys. More information on this subject can be found on the web.
2. If the security implications as detailed above are accepted and it is still decided to use the XCOM make* scripts then these are the required steps:
a. Run makeca on both local and partner servers.
This step may be considered as being redundant for the partner because the cassl.pem & casslkey.pem files created are being overwritten in step #b. However, this step creates work files e.g. index.txt and if not run the later makeclient/makeserver commands in step #c will fail with:
The file index.txt doesn't exist...
You must generate the CA cert first, exiting...
b. Copy the ssl/certs/cassl.pem and ssl/private/casslkey.pem files from local to the same locations on the partner, replacing the existing ssl/certs/cassl.pem and ssl/private/casslkey.pem files.
c. Run makeclient and makeserver on both servers.
Additional Information
XCOM™ Data Transport® for AS/400 11.0 > Administrating > Generating TLS/SSL Certificates
Replace SSL certificates used by CA XCOM that will expire
Regenerating CA XCOM SSL Certificates on a Machine that already has sample SSL Certificates
Install external CA (Certificate Authority) issued certificates for CA XCOM
Feedback
