You’ve been asked to install some files. You are not sure of their provenance, or if they have been changed from what the author wrote, and what you have received. How can you check these files?
You have some systems which are meant to be identical how can you easily check this?
One way of doing these activities is to calculate a digital hash of the file, sign the hash value, and use it.
See background for information on public/private keys.
Digitally signing is to take value, encrypt it with your private key and send it out with your certificate. To verify the signature you use the public key from the certificate to decrypt the data. It should match your copy of the value. If it matches you know it came from the certificate owner.
On z/OS you can sign load modules. These are signed at bind time, and, if configured, are checked at execution time.
Packages like openssl, and GPG (Pretty Good Privacy) have the facilities to sign objects.
This blog post covers
Installing packages
On the author’s machine
You have the Certificate Authorities file ca256.pem. This is available to every one. This could have been provided by a commercial Certificate Authority.
You have a public certificate which you will send with your package.
You have a private key matching the public certificate.
On the recipient’s machine
You have the Certificate Authority file ca256.pem.
How you do it
Create the package
You want to package data.file and distribute it. Calculate the digest of the file, and digitaly sign it
openssl dgst -sign cert.key.pem -out data.file.signature data.file
The signature is put into data.file.signature. The signature data is in binary.
Send the following to the recipient
- data.file
- data.file.signature
- your public certificate matching the private key used to sign the data. (colins.cert.pem)
Validate the package
Validate the certificate against the CA.pem
openssl verify -CAfile ca256.pem colins.cert.pem
If this works, you can trust the certificate.
Extract the public key from the certificate
openssl x509 -pubkey -noout -in colins.cert.pem > colins.pubkey
Validate the checksum of the file
This uses the public key extracted above
openssl dgst -verify ./colins.pubkey -signature data.file.signature data.file
z/OS dataset
You can use z/OS dataset, for example
openssl dgst -sign z256.key.pem -out upa.signature "//'USER.Z31B.PARMLIB(AUTORCP)'"
where you need the double quotes and the single quotes.
Package up a package
You could create a shell script to work on a directory. For example
#!/bin/bash
for filename in ./*; do
[ -e "$filename" ] || continue
echo $filename
FILE="$(basename "${filename}")"
openssl dgst -sign z256.key.pem -out signatures/$FILE.signature $filename
done
When I ran this, the signatures directory contained the signatures of the files in the current directory.
Long term validation
You’ve validated that the files you have installed are the correct ones. Has anyone changed them since they’ve been installed?
You can issue the command to calculate the digest(hash) of a file.
openssl dgst index.txt >> dgst.txt
Which says calculate the digest – but do not sign it. The output is
SHA256(index.txt)= 1c6e0089a3ceebddf1f8e475c164162c06d7d58f29cc0b2d4c230e4e7a79cbce
SHA256(aa.txt)= d8b1fb09ac7649b61d13ca9cde72851037a83c0bca60a8545310645bb0b3da7d
You can now periodically reissue the commands, and check the value are the same as they were previously. If the values have changed – the files have changed. You can also extend this (with a small bit of Python or shell code) to include the system name
SYS1 2026/04/22 SHA256(index.txt)= 1c6e0089a3ceebddf1f8e475c...e7a79cbce
SYS2 2026/04/22 SHA256(index.txt)= d8b1fb09ac7649b61d13ca9cd...bb0b3da7d
If those files are meant to be the same on both of the systems, they clearly are not. If you run the digest command weekly you will be able to see approximately when the file was changed. It may be that maintenance was applied to one system, and the other system was overlooked.
ColinPaice 