RACDCERT ADD (Add certificate)

Purpose

Use the RACDCERT ADD command to define a digital certificate using a certificate or certificate package contained in the specified data set.

Each user ID can be associated with more than one digital certificate but they must be added individually. The specified data set should contain only one digital certificate. The command reads the certificate from the data set, updates the user's profile, and creates the DIGTCERT profile.

If the data set contains a PKCS#7 or PKCS#12 package, the data set can contain more than one certificate and the processing will be as described in PKCS #7 and PKCS #12 processing details.

See UTF-8 and BMP character restrictions for information about how UTF-8 and BMP characters in certificate names and labels are processed by RACDCERT functions.

Details about DIGTCERT profile names

The name of a DIGTCERT profile is derived from the certificate's serial number and the issuer's distinguished name (IDN). Any character in either value that would not be valid in a RACF profile name, such as a blank, is replaced with the ¢ character (X'4A').

The maximum length of a DIGTCERT profile name is 246 characters. The format of the profile name is based on the combined length of the certificate's serial number and the issuer's distinguished name (IDN), including the period.

When the combined length of the value of serial-number.issuer's-distinguished-name is 246 characters or less, the name of the DIGTCERT profile uses the following format:
serial-number.issuer's-distinguished-name
When the combined length of the value of serial-number.issuer's-distinguished-name exceeds 246 characters, the name of the DIGTCERT profile uses the following format, where the certificate-hash value is a hexadecimal representation of the certificate in a hashed form:
serial-number.<first-portion-of-IDN><certificate-hash><last-portion-of-IDN>

When a DIGTCERT profile name contains a certificate hash value, each occurrence of the equal sign (=) delimiter is replaced with a colon (:).

For examples of DIGTCERT profile names, see DIGTCERT profile names in z/OS Security Server RACF Security Administrator's Guide.

Processing details

Re-adding a certificate:
If the certificate being added already exists in the RACF® database, RACF will accept the certificate and refresh its stored information if all of the following conditions are true:
  • The certificate is being added to the same user ID, SITE, or CERTAUTH as before.
  • The label specified for the certificate matches the old value or no label is specified.
  • The certificate being added has the same public key as the existing certificate.
Otherwise, an informational message is issued, and the certificate is not re-added.
Renewing a certificate:
The RACDCERT ADD function also supports certificate replacement, for cases of certificate renewal and fulfillment by an external certificate authority. When a certificate is replaced, all existing information, including key ring associations, are updated to reflect the new certificate. In addition, a new certificate label can be specified.
The certificate in the RACF database is replaced if the following conditions are true.
  • If the existing certificate has a private key associated with it:
    • The certificate is being added to the same user ID, SITE, or CERTAUTH as before.
    • The certificate being added is not a duplicate. (You are not re-adding the certificate.)
    • The certificate being added is not expired.
    • The certificate being added has the same public key as the existing certificate.
  • If the existing certificate does not have a private key associated with it:
    • The certificate is being added to the same user ID, SITE, or CERTAUTH as before.
    • The certificate being added is not a duplicate. (You are not re-adding the certificate.)
    • The certificate being added is not expired.
    • The certificate being added has a later expiration date than that of the existing certificate.
    • The certificate being added has the same subject's distinguished name, issuer's distinguished name, and public key as the existing certificate.
Adding a certificate with an existing key in the PKDS:
  • If the certificate you are adding has an existing public or private key in the PKDS, and the key is already associated with this certificate, the following rules apply:
    • If the public key already exists in the PKDS and you add its matching private key certificate, you must specify the PKDS keyword. This upgrades the PKDS entry to include the new RSA or ECC private key.
    • The PKDS label of the existing public or private key is not changed when you respecify the label with the PKDS keyword.
    • If the private key already exists in the PKDS as an RSA Modulus-Exponent (ME) key token, specifying PKDS does not convert the key to an RSA Chinese Remainder Theorem (CRT) key token.
    • If the private key already exists in the PKDS as a CRT key token, specifying ICSF does not convert the key to an ME key token.
  • If the certificate you are adding has an existing public or private key in the PKDS but the key is not already associated with this (or another) RACF certificate, RACF associates the key with this certificate when all of the following conditions are true:
    • You specify the PKDS label of the existing key using the PKDS keyword.
    • The existing key is either an RSA or ECC private key (an ICSF internal key token) or an RSA or ECC public key.
Supported certificate package formats:
The certificate package must be in one of the following formats:
  1. A single BER encoded X.509 certificate.
  2. A single Base64 encoded X.509 certificate.
  3. A Privacy Enhanced Mail (PEM) encoded X.509 certificate. If the input is in this format, only the Originator Certificate is used.
  4. One or more X.509 certificates contained within a PKCS #7 DER encoding package.
  5. One or more X.509 certificates and private keys contained within a PKCS #12 DER encoding package. If the input is in this format, all certificates are processed but only the first user private key is used. PKCS #12 is also known as Private Information Exchange (PFX). The obsolete PFX V0.02 standard is not supported.
Details about adding new certificates:
The following are additional details regarding RACDCERT's certificate processing:
  1. All fields as defined for X.509 version 1 certificates must be present and must have a length greater than zero (non-null).
  2. X.509 certificates with version numbers greater than 3 are not supported.
  3. Noncritical extensions are ignored. Critical extensions that are supported include:
    • keyUsage - { 2 5 29 15 }
    • basicConstraints - { 2 5 29 19 }
    • subjectAltname - { 2 5 29 17 }
    • issuerAltName - { 2 5 29 18 }
    • certificatePolicies - { 2 5 29 32 }
    • policyMappings - { 2 5 29 33 }
    • policyConstraints - { 2 5 29 36 }
    • nameConstraints - { 2 5 29 30 }
    • extKeyUsage - { 2 5 29 37 }
    • hostIdMapping - { 1 3 18 0 2 18 1 }
    • subjectKeyIdentifier - { 2 5 29 14 }
    • authorityKeyIdentifier - { 2 5 29 35 }
  4. Subject and issuer names can contain only the following string types:
    • UTF8 - TAG 12
    • PRINTABLESTRING - TAG 19
    • T61STRING - TAG 20
    • IA5STRING - TAG 22
    • VISIBLESTRING - TAG 26
    • GENERALSTRING - TAG 27
    • BMPString - TAG 30
  5. Because certificates can be encoded differently, be aware when transporting the different certificate encodings to and from z/OS systems. Both the BER encoded X.509 and PKCS #7 formats are binary formats and must be transported in their exact binary format. For example, binary formats, such as BER and X.509, cannot have any ASCII to EBCDIC translation performed on them, therefore, they must be transported in their exact binary format. In contrast, text formats, such as PEM and Base64, must be transported as text. When transporting for an ASCII system, the ASCII to EBCDIC translation must be performed for the PEM format and Base64 format certificate.
PKCS #12 format details:
PKCS #12 certificate packages can be processed. These certificates are encrypted with a password when received and must be decrypted with the same password before being added to the RACF database. For additional information, see the PASSWORD ('pkcs12-password') keyword.

When adding a certificate package that contains a private key, if ICSF is being used to store private keys and no label is specified for the ICSF key, ADD generates a default label in the format IRR.DIGTCERT.certificate-owner.cvtsname.ebcdic-stck-value, where certificate-owner is the owning user ID, cvtsname is the system name, as taken from the CVT, and ebcdic-stck-value is an EBCDIC version of the current store-clock value. See "PKCS #7 and PKCS #12 processing details" for information on how the multiple certificates are processed.

PKCS #7 and PKCS #12 processing details:
The ADD function of RACDCERT can accept PKCS #7 and PKCS #12 certificate packages. For PKCS #7, if there is more than one certificate in the package, the set consisting of the second through last certificate is the hierarchy of CAs. For PKCS #12, every certificate in the package other than the first one that has a 'local key ID' that matches the first private key in the package, is considered to be a CA certificate. If the command issuer is authorized to add CERTAUTH certificates, the CA certificates will be sorted to determine the hierarchy chain. The resulting set is then added to the CERTAUTH category in the hierarchy order (highest CA down to lowest CA). Thus each certificate in the package may be verified using its previously added parent. If the command issuer is not authorized to add CERTAUTH certificates, an informational message will be issued. In either case, processing will then continue with the first certificate in the package (the end-entity certificate).

Rules: For each CERTAUTH certificate in the PKCS #7 or PKCS #12 package, the following rules apply in determining trust status. The rules are listed in priority order. For rules that conflict, the first matching rule wins.

  1. If the certificate is already defined to RACF with status HIGHTRUST, the certificate retains its HIGHTRUST status.
  2. The trust status specified by the command issuer will apply to the upper CA certificate. This primes the chain with a trust value which may be inherited down. (See the next rule.) The HIGHTRUST keyword is ignored if the target user ID on the ADD is not CERTAUTH (irrcerta).
  3. For all lower CA certificates in the package and for the upper CA certificate when no trust status is specified, the trust status is determined dynamically as follows:
    1. If NOTRUST is specified by the command issuer, the certificate is added with status NOTRUST.
    2. If the certificate has one or more of the following inconsistencies, the certificate is added with NOTRUST status:
      1. The certificate is expired.
      2. The certificate has an incorrect date range relative to the issuing CA certificate. (The validity period is not completely contained within the validity period of the issuing CA certificate).
      3. The issuer of the certificate is missing from the package and is not already installed under CERTAUTH.
      4. The certificate has an unknown signature algorithm to RACF. The supported signature algorithms are: SHA1RSA, SHA224RSA, SHA256RSA, SHA384RSA, SHA512RSA, SHA1ECDSA, SHA224ECDSA, SHA256ECDSA, SHA384ECDSA, SHA512ECDSA, SHA1DSA, SHA256DSA, SHA224DSA, MD2RSA and MD5RSA.
    3. If no inconsistencies are detected, the certificate is added and inherits the trust status of its parent. If the certificate's parent has not previously been added (either as a part of this package or otherwise), the certificate is added with TRUST status if it is self-signed, NOTRUST status if it is not self-signed. If the self-signed certificate has already been added, its trust status is not changed.
  4. HIGHTRUST will be inherited from the parent as per the previous rule only if the target user ID on the ADD is CERTAUTH (irrcerta) and HIGHTRUST was specified on the command. In all other cases, HIGHTRUST reverts to TRUST when inheriting from the parent.
  5. The LABEL value will not be used. The label will be generated.
The authority required to add the CERTAUTH certificates from a PKCS #7 or PKCS #12 package is the same authority required to add CERTAUTH certificates directly, either CONTROL authority to IRR.DIGTCERT.ADD in the FACILITY class or RACF SPECIAL.
Note: PKCS #7 and PKCS #12 add error processing that has no backout support. If a terminating error is encountered during processing, any CERTAUTH certificates previously added are not removed. Unless otherwise stated in the error message description, any error messages issued are relative to the certificate where the error occurred. This may be the end-entity certificate or one of the CERTAUTH certificates.

Issuing options

The following table identifies the eligible options for issuing the RACDCERT ADD command:
As a RACF TSO command? As a RACF operator command? With command direction? With automatic command direction? From the RACF parameter library?
Yes No No. (See rules.) No. (See rules.) No
Rules: The following rules apply when issuing this command.
  • The RACDCERT command cannot be directed to a remote system using the AT or ONLYAT keyword.
  • The updates made to the RACF database by RACDCERT are eligible for propagation with automatic direction of application updates based on the RRSFDATA profiles AUTODIRECT.target-node.DIGTCERT.APPL and AUTODIRECT.target-node.DIGTRING.APPL, where target-node is the remote node to which the update is to be propagated.

Authorization required

To issue the RACDCERT ADD command, you must have the following authorizations:
  • The SPECIAL attribute, or
  • Sufficient authority to the IRR.DIGTCERT.ADD resource in the FACILITY class, as shown in Table 1, or
  • Sufficient authority to the appropriate resources in the RDATALIB class, as shown in Table 2, if Granular Authority Checking has been enabled by defining the IRR.RACDCERT.GRANULAR resource in the RDATALIB class.
  • READ access to the data set that contains the certificate you are adding.
When your installation controls access to ICSF services and the CSFSERV class is active, additional access to resources in the CSFSERV class might be required as follows:
  • When specifying PKDS you must have READ access to the CSFIQF, CSFPKI, CSFPKRC, and CSFPKRW resources.
  • If the certificate you are adding has an ECC key, you must also have the following access authorities:
    • When you specify PKDS, you must have READ access to the CSFDSV and CSFOWH resources.
    • When you omit PKDS, you must have READ access to the CSF1PKV, CSF1TRC, CSF1TRD, and CSFOWH resources.

    For details about the CSFSERV resources, see z/OS Cryptographic Services ICSF Administrator's Guide.

Table 1. Authority required for the RACDCERT ADD function under the FACILITY class
Access level Purpose
READ Add a certificate to your own user ID.
UPDATE Add a certificate for another user ID.
CONTROL Add a SITE or CERTAUTH certificate.
Table 2. Authority required for the RACDCERT ADD function under the RDATALIB class when IRR.RACDCERT.GRANULAR is defined
READ access to the resource based on cert owner and cert label * Purpose
IRR.DIGTCERT.<cert owner>.<cert label>.UPD.ADD Add a certificate under <cert owner> with specified <cert label>
IRR.DIGTCERT.<cert owner>.LABEL*.UPD.ADD Add a certificate under <cert owner> with no label specified
IRR.DIGTCERT.<cert owner>.<cert label>.UPD.ADD,
and
IRR.DIGTCERT.CERTIFAUTH.LABEL*.UPD.ADD
Add a certificate chain under <cert owner> with specified <cert label>
IRR.DIGTCERT.<cert owner>.LABEL*.UPD.ADD,
and
IRR.DIGTCERT.CERTIFAUTH.LABEL*.UPD.ADD
Add a certificate chain under <cert owner> with no label specified
IRR.DIGTCERT.<cert owner>.<friendly name>.UPD.ADD,
and
IRR.DIGTCERT.CERTIFAUTH.LABEL*.UPD.ADD
Add a certificate chain under <cert owner> with the <friendly name> label from the PKCS#12 package
* 'cert owner' is the RACF user ID, or CERTIFAUTH (for CERTAUTH), or SITECERTIF (for SITE)

Activating your changes

If the DIGTCERT or DIGTRING class is RACLISTed, refresh the classes to activate your changes.

Example:
SETROPTS RACLIST(DIGTCERT, DIGTRING) REFRESH

Related commands

Syntax

For the key to the symbols used in the command syntax diagrams, see Syntax of RACF commands and operands. The complete syntax of the RACDCERT ADD command is:

If you specify more than one RACDCERT function, only the last specified function is processed. Extraneous keywords that are not related to the function being performed are ignored.

If you do not specify a RACDCERT function, LIST is the default function.

For information on issuing this command as a RACF TSO command, refer to RACF TSO commands.

Parameters

ADD(data-set-name)
Specifies the data set containing one digital certificate or certificate package. You must specify a cataloged data set, and it may not be a PDS or a PDS member. The record format (RECFM) expected by RACDCERT is variable-byte (VB). When you specify the ADD function, RACDCERT dynamically allocates and opens the specified data set, and reads the certificate from it as binary data.

If the certificate package you are adding has an associated ECC private key, the ICSF subsystem must be operational and configured for PKCS #11 operations.

To add certificate with an RSA key that is longer than 1024 bits and is to be stored in the RACF database, the CP Assist for Cryptographic Function (CPACF) must be enabled.

Restriction: When ICSF is operating in FIPS mode, you cannot add a certificate that has a Brainpool ECC key.

ID(certificate-owner) | SITE | CERTAUTH
Specifies that the new certificate is either a user certificate associated with the specified user ID, a site certificate, or a certificate-authority certificate. If you do not specify ID, SITE, or CERTAUTH, the default is ID, and certificate-owner defaults to the user ID of the command issuer. If more than one keyword is specified, the last specified keyword is processed and the others are ignored by TSO command parse processing.

If the new certificate has an ECC private key and keyAgreement is the only key usage, the certificate cannot be used for signing. Therefore, you cannot add it as a CERTAUTH certificate.

TRUST | NOTRUST | HIGHTRUST
Specifies whether the status of the certificate being added is trusted, not trusted, or highly trusted. Whether a certificate is not trusted or trusted depends on whether or not the certificate is valid and whether the private key has been compromised or not.
Because highly trusted certificates are by definition trusted certificates, any certificate usage that was enabled by marking the certificate trusted will also be enabled by marking the certificate highly trusted. However, only certificate-authority certificates can be highly trusted. The trust status is stored in the UACC field of the certificate profile:
  • X'00' indicates the status is trusted
  • X'80' indicates the status is not trusted
  • X'C0' indicates the status is highly trusted

When a certificate is trusted, it can be used by RACF for its intended purpose (map to a user ID, or treat as a trusted certificate authority or trusted site).

For a personal certificate, TRUST indicates that the certificate can be used to authenticate a user ID.

For a certificate-authority certificate, a trusted certificate is one that can be used to authenticate a user's certificate by indicating that the entity identified in the certificate (for example, the certificate authority) can issue certificates that this system honors. This implies that a user can gain access to the system based on the information contained in the certificate if the user's certificate was signed by a trusted certificate authority.

For site certificates, a trusted certificate is one indicating that the entity identified in the certificate (for example, the site) can gain access to the system based on information contained within the certificate. Because the authority that issued the certificate might not be defined to the system as a certificate authority, this certificate information might not be able to be authenticated.

TRUST should only be specified if the command issuer knows:
  • This is a valid certificate for this user, site, or certificate authority.
  • The private key related to this certificate has not been compromised.
If no trust value is specified on the command, the following processing will take place to determine the trust status:
  • If the certificate's signature can be verified, the certificate has not expired, and the certificate's validity date range is within the validity date range of the certifying authority's certificate, the trust status is set to the trust status of the certifying authority's certificate. For self-signed certificates the certificate being added is set to TRUST by default. If the self-signed certificate has already been added, its trust status is not changed.
  • If the certificate has expired, has an incorrect validity date range, or cannot be verified because it either has an unknown encryption algorithm or RACF cannot locate its certifying authority's certificate, the status is set to NOTRUST by default.
  • If the trust status is to be set from the status of the certifying certificate and the certifying certificate is highly trusted, the status will be trusted.

If the certificate's signature is incorrect, the certificate is not added.

The TRUST keyword is unrelated to the TRUSTED attribute as defined for started procedures.

WITHLABEL('label-name')
Specifies the label to be associated with the certificate. Up to 32 characters can be specified. The label-name can contain blanks and mixed-case characters.

This label is used as a handle instead of the serial number and issuer's distinguished name. It can be used to store a descriptive text.

If the value specified in WITHLABEL already exists, RACDCERT returns a message indicating that the label has already been used. The certificate is not added.

If the user did not specify WITHLABEL, and the data set being processed is PKCS #12, RACF generates the label based on the certificate's friendly name, which is extracted from the PKCS #12 package and truncated to 32 characters if required.

If WITHLABEL is not specified, or extracted from the PKCS #12 package, RACDCERT generates a label for the certificate. The generated label is of the form LABELnnnnnnnn, where nnnnnnnn is the first integer value, starting at 00000001 that generates a unique label name.

The label-name is stripped of leading and trailing blanks. If a single quotation mark is intended to be part of the label-name, use two single quotation marks together for each single quotation mark within the string, and enclose the entire string within single quotation marks.

PASSWORD('pkcs12-password')
Specifies the password that is associated with the PKCS #12 certificate package. This keyword is required if the data set is PKCS #12 and it must not be specified if the data set is not PKCS #12.
Note: The password specified will be visible on the screen, so care should be taken to prevent it from being viewed when entered. Because PKCS #12 passwords do not follow the normal TSO/E rules for password content, they cannot be suppressed as they normally would be.

The 'pkcs12-password' can be up to 255 characters in length, is case-sensitive, and can contain blanks.

PKDS | PCICC | ICSF
Specifies that RACF should attempt to store the RSA or ECC public or private key associated with this certificate in the ICSF PKA key data set (PKDS). This applies when the key is introduced to RACF by issuing the ADD function, and when an existing certificate profile is replaced by issuing the ADD function.

The default action for a new key is for RACF to store it as a software key in the RACF database, not in the ICSF PKDS. The default action for an existing key is to leave it unchanged.

These keywords cannot be specified when the key already exists as a secure key in the ICSF token key data set (TKDS).

Guidelines for choosing PKDS, PCICC, or ICSF: The PCICC and ICSF keywords are deprecated. IBM discourages the use of these parameters.
  • The PKDS keyword supports both ECC and RSA private keys. For RSA keys, PKDS is equivalent to PCICC and stores the key as an RSA Chinese Remainder Theorem (CRT) key token. RACDCERT LIST will display this key with key type RSA along with a PKDS label.
  • The ICSF keyword supports only RSA keys and stores the key as an RSA Modulus-Exponent (ME) key token. RACDCERT LIST will display this key with key type RSA Mod-Exp along with a PKDS label.

For details about specifying or allowing RACF to generate the PKDS label, see PKDS label considerations.

For the hardware requirements for storing or accessing a key in the ICSF PKA key data set (PKDS), see Hardware requirements.

PKDS[(pkds-label | * )]
Specifies that RACF should attempt to store the public or private key associated in the ICSF PKDS as follows, based on key type.
  • For an RSA key:
    When you specify a PKDS label or an asterisk (*):
    • If the certificate has a private key, the private key is converted using a PCI-class cryptographic coprocessor to an RSA Chinese Remainder Theorem (CRT) key token. The resulting private key is stored in the ICSF PKDS.
    • If the certificate has no private key, the public key is stored as an RSA Modulus-Exponent (ME) key token.

    If the data set contains only a certificate, you must specify a pkds-label value or an asterisk (*). Otherwise, the PKDS keyword is ignored and no PKDS entry is created. The public key is stored in the ICSF PKDS as an RSA Modulus-Exponent (ME) key token with the specified label.

    If the certificate has no private key and you specify PKDS without a PKDS label and without an asterisk (*), the PKDS keyword is ignored and no PKDS entry is created.

    If the data set contains a PKCS #12 package, the private key is stored in the ICSF PKDS an RSA Chinese Remainder Theorem (CRT) key token with either a system-generated label, a label specified by pkds-label, or a label copied from the certificate label.

    Note: If you want to store the RSA private key in the PKDS as an RSA Modulus-Exponent (ME) key token, specify ICSF instead of this keyword.

  • For an ECC key:

    If the data set contains only a certificate, you must specify a pkds-label value or an asterisk (*). Otherwise, the PKDS keyword is ignored and no PKDS entry is created. The public key is stored in the ICSF PKDS with the specified label.

    If the certificate has no private key and you specify PKDS without a PKDS label and without an asterisk (*), the PKDS keyword is ignored and no PKDS entry is created.

    If the data set contains a PKCS #12 package, the private key is stored in the ICSF PKDS with either a system-generated label, a label specified by pkds-label, or a label copied from the certificate label.

  • For a DSA key: The PKDS keyword is ignored.
PCICC[(pkds-label | * )]

This parameter is deprecated. IBM recommends that you use RSA(PKDS[pkds-label | *)]) instead of PCICC[(pkds-label | *)].

It specifies the same option as the PKDS keyword for an RSA key. See the PKDS keyword of the RACDCERT ADD function for details.
ICSF[(pkds-label | * )]

This parameter is deprecated. IBM discourages the use of this parameter, as it is only applicable to RSA keys that are limited to 1024 bits.

It specifies that the public or private key is to be converted to an RSA Modulus-Exponent (ME) key token. The resulting key is stored in the ICSF PKDS.

If the certificate has no private key and you specify ICSF without a PKDS label and without an asterisk (*), the ICSF keyword is ignored and no PKDS entry is created.

Examples

Example Activity label Description
1 Operation User RACFADM with SPECIAL authority requests the addition of a digital certificate for user NETB0Y. User RACFADM has placed the digital certificate in data set 'RACFADM.NETB0Y.CERT' and wants the status of the certificate to be trusted.
Known User RACFADM has SPECIAL authority. RACFADM has placed the digital certificate in data set 'RACFADM.NETB0Y.CERT'.
Command
RACDCERT ADD('RACFADM.NETB0Y.CERT') 
   ID(NETB0Y)
   TRUST WITHLABEL('Savings Account')
Output IRRD199I Certificate with label ‘Savings Account’ is added for ’NETB0Y’
2 Operation User WENTING exports her new certificate using the RACDCERT EXPORT command and sends it to her business partner Yun. When he receives it, Yun adds it to his company's RACF data base as a SITE certificate using the RACDCERT ADD command and calls it WenTing.
Known The exported certificate does not contain the private key so the data set Wen Ting transmits to Yun need not be protected in any way.
Commands Wen Ting's RACDCERT EXPORT command:
RACDCERT EXPORT(LABEL('Wen Ting''s certificate')) DSN(FOR.YUN.CRT)
Yun's RACDCERT ADD command:
RACDCERT SITE ADD(WENTING.CRT) WITHLABEL('WenTing') ICSF(*)
Output IRRD199I Certificate with label 'WenTing' is added for SITE.
3 Operation User RACFADM wants to add a certificate for user NETB0Y and protect the ECC private key by storing it in the ICSF PKDS. User RACFADM has placed the digital certificate in data set 'RACFADM.NETB0Y.ECC.CERT' and wants the status of the certificate to be trusted.
Known User RACFADM has SPECIAL authority and sufficient access to the appropriate resources in the CSFSERV class. The system contains an operational ICSF subsystem and Crypto Express3 coprocessor (CEX3C).
Command
RACDCERT ADD('RACFADM.NETB0Y.ECC.CERT') 
   ID(NETB0Y)
   TRUST WITHLABEL('Savings Account ECC PKDS')
   PKDS(ECC4NETB0Y)
Output IRRD199I Certificate with label ‘Savings Account ECC PKDS’ is added for ‘NETB0Y’