Appendix A. Certificate Profile Input and Output Reference

Profile inputs and outputs define the expected input parameters in the certificate request and the output format of the enrollment result. Like many other components in Red Hat Certificate System, profile inputs and outputs are implemented as JAVA plug-ins to offer customization and flexibility. This appendix provides reference for the default input and output plug-ins.

A.1. Input Reference

An input puts certain fields on the enrollment page associated with a particular certificate profile. The inputs set for a certificate profile are used to generate the enrollment page dynamically with the appropriate fields; these input fields collect necessary information for the profile to generate the final certificate.

A.1.1. Certificate Request Input

The Certificate Request input is used for enrollments in which a certificate request is pasted into the enrollment form. It allows the request format to be set from a drop-down list and provides an input field to paste the request.
This input puts the following fields in the enrollment form:
  • Certificate Request Type. This drop-down menu lets the user specify the certificate request type. The choices are PKCS #10 or CRMF. Certificate Management Messages over Cryptographic Message Syntax (CMC) enrollment is supported with both PKCS #10 and CRMF.
  • Certificate Request. This is the text area in which to paste the request.

Example A.1. 

caAdminCert.cfg:input.i1.class_id=certReqInputImpl

A.1.2. CMC Certificate Request Input

The CMC Certificate Request input is used for enrollments using a Certificate Message over CMS (CMC) certificate request is submitted in the request form. The request type must be either PKCS #10 or CRMF, and the only field is the Certificate Request text area in which to paste the request.

Example A.2. 

caCMCUserCert.cfg:input.i1.class_id=cmcCertReqInputImpl

A.1.3. Dual Key Generation Input

The Dual Key Generation input is for enrollments in which dual key pairs will be generated, and thus two certificates issued, one for signing and one for encryption.
This input puts the following fields into the enrollment form:
  • Key Generation Request Type. This field is a read-only field displaying crmf as the request type.
  • Key Generation Request. This field sets the selection for the key size in the key generation request for both encryption and signing certificates.

Example A.3. 

caDualCert.cfg:input.i1.class_id=dualKeyGenInputImpl

A.1.4. File-Signing Input

The File-Signing input sets the fields to sign a file to show it has not been tampered with.
This input creates the following fields:
  • Key Generation Request Type. This field is a read-only field displaying crmf as the request type.
  • Key Generation Request. This input adds a drop-down menu to select the key size to use in the key generation request.
  • URL Of File Being Signed. This gives the location of the file which is to be signed.
  • Text Being Signed. This gives the filename.

Example A.4. 

caAgentFileSigning.cfg:input.i2.class_id=fileSigningInputImpl

A.1.5. Image Input

The Image input sets the field to sign an image file. The only field which this input creates is Image URL, which gives the location of the image which is to be signed.

A.1.6. Key Generation Input

The Key Generation input is used for enrollments in which a single key pair will be generated, generally user-based certificate enrollments.
This input puts the following fields into the enrollment form:
  • Key Generation Request Type. This field is a read-only field displaying crmf as the request type.
  • Key Generation Request. This input adds a drop-down menu to select the key size to use in the key generation request.

Example A.5. 

caDualCert.cfg:input.i1.class_id=keyGenInputImpl

A.1.7. nsHKeyCertRequest (Token Key) Input

The Token Key input is used to enroll keys for hardware tokens for agents to use later for certificate-based authentication.
This input puts the following fields into the enrollment form:
  • Token Key CUID. This field gives the CUID (contextually unique user ID) for the token device.
  • Token Key User Public Key. This field must contain the token user's public key.

Example A.6. 

caTempTokenDeviceKeyEnrollment.cfg:input.i1.class_id=nsHKeyCertReqInputImpl

A.1.8. nsNKeyCertRequest (Token User Key) Input

The Token User Key input is used to enroll keys for the user of a hardware token, for agents to use the token later for certificate-based authentication. This input puts the following fields into the enrollment form:
  • Token Key User UID. This field gives the UID for the LDAP entry of the user of the token device.
  • Token Key User Public Key. This field must contain the token user's public key.

Example A.7. 

caTempTokenUserEncryptionKeyEnrollment.cfg:input.i1.class_id=nsNKeyCertReqInputImpl

A.1.9. Serial Number Renewal Input

The Serial Number Renewal Input is used to set the serial number of an existing certificate so that the CA can pull the original certificate entry and use the information to regenerate the certificate. The input inserts a Serial Number field into the enrollment form.
This is the only input that needs to be used with a renewal form; all the other information is supplied by the certificate entry.

Example A.8. 

caTokenUserEncryptionKeyRenewal.cfg:input.i1.class_id=serialNumRenewInputImpl

A.1.10. Subject DN Input

The Subject DN input allows the user to input the specific DN to set as the certificate subject name, and the input inserts a single Subject Name field into the enrollment form.

Example A.9. 

caAdminCert.cfg:input.i3.class_id=subjectDNInputImpl

A.1.11. Subject Name Input

The Subject Name input is used for enrollment when DN parameters need to be collected from the user. The parameters are used to formulate the subject name in the certificate. This input puts the following fields into the enrollment form:
  • UID (the LDAP directory user ID)
  • Email
  • Common Name (the name of the user)
  • Organizational Unit (the organizational unit (ou) to which the user belongs)
  • Organization (the organization name)
  • Country (the country where the user is located)

Example A.10. 

caDualCert.cfg:input.i2.class_id=subjectNameInputImpl

A.1.12. Submitter Information Input

The Submitter Information input collects the certificate requester's information such as name, email, and phone.
This input puts the following fields into the enrollment form:
  • Requester Name
  • Requester Email
  • Requester Phone

Example A.11. 

caAdminCert.cfg:input.i2.class_id=submitterInfoInputImpl

A.1.13. Generic Input

The Generic Input allows admins to specify any number of input fields to be used with extension plug-ins that handle patterns. For example, the ccm and GUID parameters are used in the patterned Subject Alternative Name Extension Default plug-in:

Example A.12. 

input.i3.class_id=genericInputImpl
input.i3.params.gi_display_name0=ccm
input.i3.params.gi_param_enable0=true
input.i3.params.gi_param_name0=ccm
input.i3.params.gi_display_name1=GUID
input.i3.params.gi_param_enable1=true
input.i3.params.gi_param_name1=GUID
input.i3.params.gi_num=2
…
policyset.set1.p6.default.class_id=subjectAltNameExtDefaultImpl
policyset.set1.p6.default.name=Subject Alternative Name Extension Default
policyset.set1.p6.default.params.subjAltExtGNEnable_0=true
policyset.set1.p6.default.params.subjAltExtGNEnable_1=true
policyset.set1.p6.default.params.subjAltExtPattern_0=$request.ccm$
policyset.set1.p6.default.params.subjAltExtType_0=DNSName
policyset.set1.p6.default.params.subjAltExtPattern_1=(Any)1.3.6.1.4.1.311.25.1,0410$request.GUID$
policyset.set1.p6.default.params.subjAltExtType_1=OtherName
policyset.set1.p6.default.params.subjAltNameExtCritical=false
policyset.set1.p6.default.params.subjAltNameNumGNs=2

A.1.14.  Subject Alternative Name Extension Input

The Subject Alternative Name Extension Input is used along with the Subject Alternative Name Extension Default plug-in. It allows admins to enable the numbered parameters in URI with the pattern req_san_pattern_# into the input and therefore the SubjectAltNameExt extension. For example, URI containing:
...&req_san_pattern_0=host0.Example.com&req_san_pattern_1=host1.Example.com
injects host0.Example.com and host1.Example.com into the SubjectAltNameExt extension from the profile below.

Example A.13. 

input.i3.class_id=subjectAltNameExtInputImpl
input.i3.name=subjectAltNameExtInputImpl
policyset.serverCertSet.9.constraint.class_id=noConstraintImpl
policyset.serverCertSet.9.constraint.name=No Constraint
policyset.serverCertSet.9.default.class_id=subjectAltNameExtDefaultImpl
policyset.serverCertSet.9.default.name=Subject Alternative Name Extension Default
policyset.serverCertSet.9.default.params.subjAltExtGNEnable_0=true
policyset.serverCertSet.9.default.params.subjAltExtPattern_0=$request.req_san_pattern_0$
policyset.serverCertSet.9.default.params.subjAltExtType_0=DNSName
policyset.serverCertSet.9.default.params.subjAltExtGNEnable_1=true
policyset.serverCertSet.9.default.params.subjAltExtPattern_1=$request.req_san_pattern_1$
policyset.serverCertSet.9.default.params.subjAltExtType_1=DNSName
policyset.serverCertSet.9.default.params.subjAltExtGNEnable_2=false
policyset.serverCertSet.9.default.params.subjAltExtPattern_2=$request.req_san_pattern_2$
policyset.serverCertSet.9.default.params.subjAltExtType_2=DNSName
policyset.serverCertSet.9.default.params.subjAltNameExtCritical=false
policyset.serverCertSet.9.default.params.subjAltNameNumGNs=3