A private key is used for encryption and should be kept private. If someone has access to the private key they can impersonate you.
A public key is the opposite of the private key. It is used for decrypting data encrypted with the private key. The public key can (and should) be generally available.
Certificates are used in TLS for authentication and encryption, and can be used for identification. They include a public key.
A Certificate Authority(CA) certificate is used to validate other certificates. It involves doing a checksum of a certificate, and encrypting it with the CA private key – a process known as signing the certificate
To validate a certificate, the recipient needs a copy of the CA which was used to sign the original certificate. It can the decrypt the encrypted checksum, and compare it with the certificates checksum.
If you create a Certificate Authority certificate you will need to distribute this to all machines that might communicate with your server(possibly thousands of machines), and installed into the keystore on those machines. This can be a big task. Most system have one site wide CA certificate which is distributed to all machines. You might have a second CA to limit access to a system. This CA is used to sign the server certificates.
Creating certificates
As part of creating a certificate you create the private/public keys. There are different algorithms for these keys. Some are stronger than others (it takes more time and CPU to break them) Keys with elliptic curve algorithms are generally stronger than using RSA techniques, and there other techniques resistant to Quantum Computing.
You have to use a server certificate with RSA and keysize 2048.
I found that authentication with JWT (Java Web Tokens) only worked with RSA keys and not Elliptic Curves. This is because of encryption with JWT.
Key stores
You should use keyrings rather than .pem files, as they are more secure. .pem files can be copied, and anyone with authority can copy them. You have to give explicit permission to be allowed to access a keyring. Certificate and the private keys within a keyring can be stored in cryptographic hardware, and the private keys are never exposed in clear text.
Many systems uses a keystore for storing the private key used by the server, and a trust store for the Certificate Authority keys needed to validate any client certificate sent to the server. This can, but is not recommended, be the same as the keystore.
The keystore will need the server key. You can specify which key should be used.
- the Certificate Authority keys needed to validate the server key.
- the server userid needs access to the keyring. If the private key belongs to the server’s userid, then the server’s userid needs read access to the keyring. If the private key belongs to a different userid, the server’s userid needs update access to the keyring. See here for more information.
The trust store needs all the CA certificates which may be needed to verify a client certificate.
The client machine will have one or more certificates. A copy of the CA used to create these needs to be installed in the trust store on the server.
I understand that if you add a certificate to the trust store, you need to restart Zowe for it to be picked up, so try to get a list of all the CAs you will need before you start.
Validating certificates
The trust store needs the certificates to validate any client certificates sent to the server. This will usually just be Certificate Authority certificates.
Zowe works with z/OSMF. They communicate with certificates. The z/OSMF trust store keyring needs the CA of the Zowe server certificate, and the Zowe trust store keyring needs the CA of the z/OSMF server key. If they are not set up properly you can get messages “LoadBalancer does not contain an instance for the service zaas”.
If you have a site wide CA, which is the same for both of the server keys, then you do not need to do any more work, as both trust store keyrings will already have the CA. If Zowe and z/OSMF have different CA certificates, the CA certificates need to be connected to the other keyrings.
Subject Alternative Name
The Subject Alternative Name within a certificate provides the IP addresses, or IP Names of the server. A client can check this address with the IP address of the session, and terminate the session if they do not match. This is considered best practice. This check can be disabled in Zowe by using verifyCertificates NOSTRICT in the zowe.yaml file.
RACF allows one name or address when the certificate is defined, for example ALTNAME(IP(127.0.0.1))
On my z/OS system the command TSO NETSTAT HOME gives three addresses 127.0.0.1 and 10.1.1.2 and 10.1.2.6.
You can configure your sysplex, so all systems in the sysplex have the same IP address, and traffic gets routed internally to the correct system. Without this, if you start a server on a different LPAR it will have a different IP address, and so the validation will fail.
On my system, the zOSMF certificate did not have an ALTNAME specified, and so failed the Zowe checks. I had to set the Zowe option verifyCertificates NOSTRICT for it to work, until I fixed the certificate.
If the z/OSMF certificate has an ALTNAME(IP…) specified, use the IP address value when you configure zOSMF for example
zOSMF:
host: 127.0.0.1
port: 10443
applId: IZUDFLT
Mapping certificates
If you are using client certificate to authenticate rather than a userid and password, then you’ll need to map certificates to userids, for example with the RACDCERT MAP command. You can specify which CA the certificates were signed with, and fields from the subject Distinguished Name. The question of which is better: using userid and password, or client certificate to logon has no easy answer
- It is easy for a hacker to get a password (lost handbag, yellow sticky stuck to the screen, a couple of pints down the pub) It is easy to change a password once is is compromised.
- It is harder for a hacker to get a certificate – but it is harder to change and re-issue a certificate. You have to get the updated certificate down to the client’s machine. It could be stolen if a hacker has access to the machine.
- Using Biometric data to logon is the ultimate limit in this area. Hackers could steal it – but there is no way of changing it if it is compromised!
Decisions
You need to decide
- Are you going to have a CA just for Zowe? or reuse the site CA.
- If you are going to have a Zowe specific CA – how are you going to distribute it to all the client machines.
- You’ll need to ensure Zowe and z/OSMF have the other’s CA certificates in their trust store.
- Are you going to use Subject Alternative Name ALTNAME(IP(10.1.1.2))
- What value of verifyCertificates STRICT|NOSTRICT are you going to specify in the zowe.yaml file.
- Are you going to authenticate using certificates. You will need to set up mapping from certificate to userid. RACDCERT MAP
- If you will be using JWT, and so need an RSA key in the server certificate
ColinPaice 