Creating a self-signed server or client certificate

If your organization does not use a certificate authority (within the organization or outside the organization), a self-signed certificate can be generated for use by the program acting as an SSL server or client. In addition, since root CA certificates are also self-signed certificates that are permitted to be used to sign other certificates (certificate requests), these procedures can also be used to create a root CA certificate. See Marking a certificate (and private key) as the default certificate.

Programs acting as SSL servers (i.e. acting as the server side of the SSL handshake protocol) must have a certificate to use during the handshake protocol. A program acting as an SSL client requires a certificate when the SSL server requests client authentication as part of the SSL handshake.

Note: This is not suggested for production environments and should only be used to facilitate test environments before production. Self-signed certificates do not imply any level of security or authenticity of the certificate because, as their name implies, they are signed by the same key that is contained in the certificate. However, certificates that are signed by a certificate authority indicate that, at least at the time of signature, the certificate authority approved the information contained in the certificate.

Note: gskkyman supports the creation of X.509 Version 3 certificates.

When creating a self-signed certificate to be used to identify a server or client, from the Key Management Menu or Token Management Menu, enter 6. You are prompted for a number of items to define the certificate, including the intended use of the certificate, the key algorithm and key size, and possibly the digest algorithm for the certificate signature.

Figure 1. Key Management Menu

                                                                   
       Key Management Menu                                         
                                                                   
       Database: /home/sufwl1/ssl_cmd/mykey.kdb
       Expiration Date: 2025/12/02  10:11:12    
                                                                   
   1 - Manage keys and certificates                                
   2 - Manage certificates                                         
   3 - Manage certificate requests                                 
   4 - Create new certificate request
   5 - Receive requested certificate or a
       renewal certificate 
   6 - Create a self-signed certificate                            
   7 - Import a certificate                                        
   8 - Import a certificate and a private key                      
   9 - Show the default key                                        
  10 - Store database password                                     
  11 - Show database record length                                 
                                                                   
   0 - Exit program                                                
                                                                   
Enter option number (press ENTER to return to
previous menu): 6 <enter>     
 ===>

Figure 2. Token Management Menu

                                                                   
       Token Management Menu                                         
                                                                   
       Token: TOKEN1               

       Manufacturer:  z/OS PKCS11 API
       Model:  HCR7780
       Flags:  0x00000509 (INITIALIZED,PROT AUTH
               PATH,USER PIN INIT,RNG)
                                                                          
   1 - Manage keys and certificates  
   2 - Manage certificates    
   3 - Manage certificate requests    
   4 - Create new certificate request  
   5 - Receive requested certificate or a renewal 
       certificate                 
   6 - Create a self-signed certificate    
   7 - Import a certificate          
   8 - Import a certificate and a private key   
   9 - Show the default key   
  10 - Delete token         
                            
   0 - Exit program       
                                                                     
Enter option number (press ENTER to return to
previous menu): 6 <enter>

Certificates that are intended to be used directly by a server or client are considered to be end user certificates. Certificates intended to be used to sign other certificates are considered to be CA certificates. RSA key certificates are the most common. DSA key certificates represent certificates that follow the FIPS-186 government standard. ECC key certificates represent certificates that use Elliptic Curve Cryptography. The larger the key size, the more secure the generated key will be. Note that CPU usage increases as the key size increases.

If an RSA-based certificate is selected, you will be prompted to select the key size and the digest type for the signature algorithm. See Figure 3 for an example of selecting the key size and digest type.

If a 1024-bit DSA certificate is selected, SHA-1 will be used for the signature algorithm. If a 2048-bit DSA certificate is selected, you will be prompted to select the digest type for the signature algorithm from a list of SHA-based digest types.

If an ECC certificate is selected, you will be prompted to select the ECC key type and curve type. The suggested digest for the key size of the ECC key will be used for the signature algorithm, as specified in Table 1. See Creating a signed ECC certificate and key for more information.

Once the certificate type and signature algorithm is determined, you will be prompted to enter:

a label to uniquely identify the key and certificate within the key database
the individual fields within the subject name
certificate expiration. The valid expiration range is 1 to 9999 days. The default value is 365 days.
the subject alternate names (optional)

Figure 3 shows the creation of a self-signed certificate to be used as a server or client certificate in a key database file or z/OS® PKCS #11 token.

Figure 3. Creating a Self-Signed Certificate

      Certificate Usage
 
   1 - CA certificate
   2 - User or server certificate 
 
Select certificate usage (press ENTER to return to menu): 2 <enter>

       Certificate Key Algorithm

   1 - Certificate with an RSA key
   2 - Certificate with a DSA key 
   3 - Certificate with an ECC key

Select certificate key algorithm (press ENTER to return to menu): 1 <enter>

       RSA Key Size
 
   1 - 1024-bit key
   2 - 2048-bit key
   3 - 4096-bit key 
 
Select RSA key size (press ENTER to return to menu): 1 <enter>

       Signature Digest Type

   1 - SHA-1                                                          
   2 - SHA-224                                                        
   3 - SHA-256                                                        
   4 - SHA-384                                                        
   5 - SHA-512                                                        

Select digest type (press ENTER to return to menu): 1 <enter>                                                
Enter label (press ENTER to return to menu): Server Cert <enter>                                
Enter subject name for certificate                                              
  Common name (required): My Server Certificate <enter>                                      
  Organizational unit (optional): ID <enter>                                            
  Organization (required): IBM <enter>                                                 
  City/Locality (optional): Endicott <enter>                                            
  State/Province (optional): NY <enter>                                                 
  Country/Region (2 characters - required): US <enter>                                 
Enter number of days certificate will be valid (default 365): 244 <enter>

Enter 1 to specify subject alternate names or 0 to continue: 0 <enter>             
                                                                                
Please wait .....                                                               
                                                                                
Certificate created.
                       
Press ENTER to continue.                                                        
 ===>

Once the certificate is created, the next step is to determine whether the certificate should be marked as the database's or z/OS PKCS #11 tokens default certificate. Setting the certificate as the default certificate allows the certificate to be used by the SSL APIs without having to specify its label. For more information about setting the default certificate, see Marking a certificate (and private key) as the default certificate.

In order for the SSL handshake to successfully validate the use of the self-signed certificates, the partner application needs to know about the signer of the certificate. For self-signed certificates, this means that the self-signed certificate must be imported into the partner's database or z/OS PKCS #11 token. For more information about importing certificates, see Importing a certificate from a file as a trusted CA certificate.