Appendix E. Certificate import/export interoperability tests

• S/390 V2R10 GSKYMAN->OS/400 DCM V5R1

We exported a certificate signed by a well-known CA as a PKCS12 file.

We moved the file via FTP with binary format. Once imported, the

certificate kept its original label.

• PCOM 4.3 or CA express IKEYMAN->OS/400 DCM V4R5

We exported a certificate signed by a well-known CA as a PKCS12 file.

We moved the file via FTP with binary format. Once imported, the

certificate kept its original label.

• PCOM 4.3 or CA express IKEYMAN->AS/400 DCM V5R1

We exported a certificate signed by a well-known CA as a PKCS12 file.

We moved the file via FTP with binary format. Once imported, the

certificate kept its original label.

• PCOM 5.0 or CA express V5R1 IKEYMAN->AS/400 DCM V4R5

We had to transport the whole key database file (file.kdb) via FTP in binary

format, and then open it with the DCM. We were then able to manage the

certificate and eventually export it to a file and import it into the *SYSTEM

certificate store.

• PCOM 5.0 or CA express V5R1 IKEYMAN->AS/400 DCM V5R1

We exported a certificate signed by a well-known CA as a PKCS12 file

and chose the weak encryption. We moved the file via FTP with binary

format. Once imported, the certificate kept its original label.



E.2 Export interoperability test results

The following list shows the results when we exported certificates from the

OS/400 DCM *SYSTEM certificate store and imported them on another

platform:

• AS/400 DCM V5R1->AIX 4.33 SNAKEYMAN

We had to transport the whole key database file (file.kdb) via FTP in binary

format, and then open it with the SNAKEYMAN. We were then able to

manage the certificate.

• AS/400 DCM V5R1->S/390 V2R1 GSKYMAN

We had to create the certificate without extensions (subject alternative

names) and export it by selecting V4R5 or V4R4 as the target release.

That means that the GSKYMAN V2R1 supports PKCS#12 V1.



448



iSeries Wired Network Security



• AS/400 DCM V5R1->S/390 V2R1 RACDCERT

We had to export the certificate by selecting V5R1 as the target release.

That means that the RACF Digital Certificate V2R1 supports PKCS#12

V3. We were able to import the certificate with the subject alternative

names, but we could not display them.

• AS/400 DCM V5R1->PCOM 4.3 or CA express

We had to export the certificate by selecting V4R5 or V4R4 as the target

release. That meant that its IKEYMAN product supported PKCS#12 V1.

• AS/400 DCM V5R1->PCOM 5.0 or CA V5R1

We had to export the certificate by selecting V4R5 or V4R4 as the target

release. That meant that its IKEYMAN product supported PKCS#12 V1.

The import operation was successfully completed, but we were not able to

display or manage the certificate under the list of personal certificates.



Appendix E. Certificate import/export interoperability tests



449



450



iSeries Wired Network Security



Appendix F. Publishing a CRL to an OS/400 LDAP server

In OS/400 V5R1, the Certificate Revocation List (CRL) support provides

certificate validation by accessing a CRL located on a Certificate Authority’s

Lightweight Directory Access Protocol (LDAP) server. For fast connections

from your iSeries or AS/400 server to the CA’s server, the CRL checking

usually does not have a large impact on performance, for example, during the

SSL handshake. But when using slow connections or when network

congestions occur, the CRL checking via the CA’s LDAP server can introduce

delays. For this reason you may want to replicate the CA’s CRL to a local

LDAP server hosted on the iSeries or AS/400 server. This appendix describes

the necessary steps to set up the LDAP server environment on the iSeries or

AS/400 server. It also contains the required steps to publish a CRL to a local

LDAP server. OS/400 operating system, DCM, and basic LDAP knowledge is

assumed.



F.1 Planning

Before you start with the actual implementation, you need to gather certain

information. First, you need to find out how your CA publishes CRLs. This

varies depending on the CA. Some CAs make the CRLs available for

download on their Web sites. For example, VeriSign CRLs can be

downloaded from http://crl.verisign.com. Some other CAs will allow you to

transfer CRLs using FTP. Once you know how to obtain the CRL, you need to

find out how often the CRL will be updated by the CA. Even if a CRL contains

information when the next CRL will be published, you have no easy access to

this information without writing your own applications. Note that the CRL has

to be in binary format (Distinguished Encoding Rule or DER format).

In the second step you need to find out whether the certificates issued by this

CA contain CRL Distribution Point extensions. CRL Distribution Points define

the search path within the LDAP directory for finding the CRL. If the CA does

not support CRL Distribution Points, the default search path is the certificate

issuer’s distinguished name (DN). To find out what the issuer’s DN is, you can

use the Digital Certificate Manager (DCM) and display, for example, a server

certificate as shown in Figure 332 on page 452.



© Copyright IBM Corp. 2001



451



Figure 332. Issuer’s DN



In this example, the issuer’s DN information in X.509 format would be:

CN=ITSO Raleigh Root CA, OU=iSeries ITSO (T.Barlen), O=IBM, C=US



Later in this appendix, when setting up the LDAP server, you need this

information. Remember, when CRL Distribution Points are used, you have to

use the information that they provide.



F.2 Configuration summary

The following list summarizes the steps required to use a local LDAP server

for CRL checking:

1. Perform the basic configuration of the LDAP server.

2. Add the DN attributes for the CRL directory path to the LDAP directory and

change the attribute settings to allow anonymous access to the CRL data.

3. Obtain the CRL from the CA.

4. Publish the CRL to the local LDAP server.

5. Define a CRL location in DCM.

6. Assign the CRL location to the CA certificate.

7. Change the DCM application definitions to perform CRL checking.

8. Update the CRLs regularly.



F.3 Configuring the LDAP server

The LDAP server configuration is performed by using the Operations

Navigator. In this scenario we used the wizard to perform the basic setup.



452



iSeries Wired Network Security