(even if you just take the default). Do I assume that the expiration date is ignored for the Co:Z implementation since normal ssh keys don't expire. Co:Z is just using RACF facilities to store the public/private key pair that will be used for the ssh client. Is this correct or am I missing something?SAF/RACF Keyring support question regarding cert expiration
-
DClassic53
- Posts: 39
- Joined: Wed Feb 11, 2009 10:23 am
SAF/RACF Keyring support question regarding cert expiration
When the cert is generated by RACDCERT, the result is a cert with an expiration date (even if you just take the default). Do I assume that the expiration date is ignored for the Co:Z implementation since normal ssh keys don't expire. Co:Z is just using RACF facilities to store the public/private key pair that will be used for the ssh client. Is this correct or am I missing something?
(even if you just take the default). Do I assume that the expiration date is ignored for the Co:Z implementation since normal ssh keys don't expire. Co:Z is just using RACF facilities to store the public/private key pair that will be used for the ssh client. Is this correct or am I missing something?David
You are correct. The standard SSH protocol does not actually support X.509 certificates. With Co:Z, we allow you to use the certificate's private key to sign an authentication request in a way compatible with SSH RSA keys.
FWIW: We use the System SSL api "gsk_sign_data()" to use the private key to sign the login request. The key is never removed from RACF (or ICSF).
FWIW: We use the System SSL api "gsk_sign_data()" to use the private key to sign the login request. The key is never removed from RACF (or ICSF).