Create a signing Certifiacte for ACF2

Products

• ACF2

Issue/Introduction

Need to create a signing certificate in ACF2.

 

How is this done using self-signed and external signer?

Resolution

Signing certificates(CERTAUTH) can be created by either a Local CA or an external CA. Sites that are going to act as their own local CA will need to define that signing (CERTAUTH) certificate.

ACF
SET PROFILE(USER) DIV(CERTDATA)
GENCERT CERTAUTH.SIGNER SUBJSDN(.....) LABEL(MY COMPANY CA)   EXPIRE(12/31/25)

The GENCERT command generates a digital certificate with a public/private key pair and inserts a CERTDATA profile record into the CA ACF2 database. The LABEL is a part of the CERTDATA profile record and not part of the certificate. It can be used to help identify a specific CERTDATA record. Be sure to specify an EXPIRE date when creating a signing (CERTAUTH) when acting as a local CA. The EXPIRE date should be 5-10 years in the future to ensure it will extend beyond the EXPIRE date of any certificates signed by it.

For sites using an external CA, the process is different. First, the GENCERT command is used to generate a self-signed certificate and its CERTDATA record. Next, the GENREQ command is used to generate a certificate request to be sent to the external CA. The GENREQ extracts the subjects distinguished name and the public key from the certificate and puts it in a dataset from which the request is sent to the CA.

ACF
SET PROFILE(USER) DIV(CERTDATA)
GENCERT FTPD.CERT1 SUBJSDN(.....) LABEL(FTPD Certificate)
GENREQ FTPD.CERT1 DSN('CERTREQ.DSN')

The external CA creates a new signed certificate and sends it back. The signed certificate can be loaded (FTP'd) into a dataset and the INSERT command can be used to replace the previously GENCERT self-signed certificate and its CERTDATA record in the INFOSTG database.

ACF
SET PROFILE(USER) DIV(CERTDATA)
INSERT CERTAUTH.VERISIGN DSN('SIGNDCRT.DSN2')    **
INSERT FTPD.CERT1 DSN('SIGNDCRT.DSN1'

This is the only instance where CA ACF2 allows an INSERT command to replace an existing record. CERTDATA profile processing allows this INSERT command to replace the exising self-signed certificate with the CA-signed certificate if the command specifies no LABEL or if it specifies a LABEL that matches the one on the original certificate, for example FTPD Certificate. It will not allow a different LABEL to be specified.

Note: The LABEL field for FTPD.CERT1 does not have to be included on the INSERT if the fully qualified record id is specified.

**When using certificates signed by a CA, the CA's root certificate must be obtained and inserted as a CERTAUTH CERTDATA profile record. If the CA is your own, the GENCERT shown earlier is sufficient. If the CA is external you should be able to get its root certificate from the CA's website, put it in the dataset, and insert it as shown above.

Note: Be careful how the returned certificate is put into the dataset. If the CA is cut and pasted in edit mode, be sure that CAPS OFF is specified so the data is not changed.

Since it is possible to have intermediate CA certificates where there is a chain of CA certificates, each one signing another, each signing CA would have to be defined as a CERTDATA record and each would have to be connected to the KEYRING record.

Important! Be aware that when the certificate in the dataset is in PKCS#12 format, a password must be supplied on the INSERT and CHKCERT commands.