Hi Vince,
Yes, using GDKUTIL CREDENTIALS(ADD), the CREDSNAM DD would point to a
file or data set that has:
{
"credentials-file": "/u/vincere/service.account.json"
}
It will still require the Crypto Express card because it has to save
the Private Key in the PKDS. (The ICSF product owner told me that is the
requirement, thus the failure of the CSNxxxxx call to import the private key.)
The private key is used to sign the JWT used in the authentication with GCP.
Sincerely,
Andrew Wilt
DFSMSdfp CDA (Cloud Data Access) Product Owner
IBM Z Content Solutions | IBM z/OS Cloud Data Access
z/OS DFSMS Community
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Vince Re
Sent: Friday, February 20, 2026 11:33 AM
To: [email protected]
Subject: [EXTERNAL] Re: Help configuring GDKUTIL on system with no crypto
processor
Thank you Andrew for the reply...
I've gotten past the error with the "allow-no-CEX" configuration...I think the
issue was that even though the "config.json" file was EBCDIC, it had a file tag
saying it was ASCII. I deleted and recreated the file from scratch and it seems
to honor the "allow-no-CEX" setting now.
What I'm currently stuck on is how to transform the credentials I get from a
Google service account JSON file to whatever GDKUTIL CREDENTIALS(ADD) requires.
My service account JSON file (*service.account.json") is a straight download
from Google's IAM service, and it looks like this:
{
"type": "service_account",
"project_id": "xxxxx",
"private_key_id": "xxxxx",
"private_key": "-----BEGIN PRIVATE KEY----/nMIIEvgIBADANB...\n-----END
PRIVATE KEY-----\n",
"client_email": "xxxxx",
"client_id": "xxxxx",
"auth_uri":
"https://urldefense.proofpoint.com/v2/url?u=https-3A__accounts.google.com_o_oauth2_auth&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=q6TY9as_1CyE9kdX1uCZthibBQf-ovOeGrDIRnv3F58&m=jHXyMtj46aCjfe_Xa1LNJqErojN0z_VZucx28tm-Uf_51wrWYvjSpIpk1L_SHmYd&s=mWFWZVBQW-F7ucjILXYL_UuJtG5GDULUo0RDgATlCAY&e=
",
"token_uri":
"https://urldefense.proofpoint.com/v2/url?u=https-3A__oauth2.googleapis.com_token&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=q6TY9as_1CyE9kdX1uCZthibBQf-ovOeGrDIRnv3F58&m=jHXyMtj46aCjfe_Xa1LNJqErojN0z_VZucx28tm-Uf_51wrWYvjSpIpk1L_SHmYd&s=e9ZCVjO3DE5n1Z21aWb3JGfA3W8Ciho58rb3e3n0-mE&e=
",
"auth_provider_x509_cert_url":
"https://urldefense.proofpoint.com/v2/url?u=https-3A__www.googleapis.com_oauth2_v1_certs&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=q6TY9as_1CyE9kdX1uCZthibBQf-ovOeGrDIRnv3F58&m=jHXyMtj46aCjfe_Xa1LNJqErojN0z_VZucx28tm-Uf_51wrWYvjSpIpk1L_SHmYd&s=1nDoXU0pR6jwVBnk74VLNisNQcEe5OVIx13-AF7T8nw&e=
",
"client_x509_cert_url":
"https://urldefense.proofpoint.com/v2/url?u=https-3A__www.googleapis.com_robot_v1_metadata_x509_&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=q6TY9as_1CyE9kdX1uCZthibBQf-ovOeGrDIRnv3F58&m=jHXyMtj46aCjfe_Xa1LNJqErojN0z_VZucx28tm-Uf_51wrWYvjSpIpk1L_SHmYd&s=fQDkPNnasVsKmOxZ9oN_QEihyCi4SeQrmx_vf_MKh2o&e=
...",
"universe_domain": "googleapis.com"
}
If I run GDKUTIL CREDENTIALS(ADD) with //CREDSNAM pointing to the file above, I
get an entry in the gskkeyf.json file for the user/provider, but no actual
credentials. In the example you provided in the doc, the GDKUTIL input just
shows a filename, but not the contents of the file or how it was derived from
the Google service account credentials. I wrote a simple GDKKEYAD program in
hopes of maybe getting some more granular debugging information, but I don't
see anything that tells me what you're looking for in the Google service
account JSON file.
By comparison, I have AWS working, and what I see in the S3 entry within the
gskkeyf.json file has what looks like an encrypted "key" and "secretKey". I
have nothing like this for my GCP credentials after running GDKUTIL. It seems
to suggest that you parsed the Google JSON file, didn't find what you're
looking for, then stored an "empty" set of credentials.
If it's any help, I'm on z/OS 3.1 and GDKUTIL is at UJ97023.
Thanks again for your help - happy to try anything you can suggest.
Vince
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
