Enabling and configuring cryptographic technology with WebSphere Application Server on Linux for System z hardware

Content

To use cryptographic technology with WebSphere Application Server on Linux for System z hardware, you must meet the minimum software and hardware requirements and complete the following steps:

• Set up Linux on System z hardware
• Configure WebSphere Application Server
• Configure IBM HTTP Server

Prerequisites

Back to top

The following minimum software and hardware requirements exist to use hardware cryptography technology with WebSphere Application Server on Linux for System z hardware:

• SUSE Linux Enterprise Server Version 10 SP 3 or Red Hat Enterprise Linux Version 5.5
• IBM WebSphere Application Server Version 7.0.0.9
• IBM Software Development Kit (SDK) 1.6 SR 7 , which is available as a separate download with WebSphere Application Server Version 7.0.0.9
• OpenCryptoki software files for:
  • openCryptoki-2.2.4-0.12.10.s390.rpm
  • openCryptoki-32bit-2.2.4-0.12.10.s390.rpm
  • openCryptoki-64bit-2.2.4-0.12.10.s390x.rpm
• OpenCryptoki software files for:
  • openCryptoki-2.2.4-22.el5_4.2.s390.rpm
  • openCryptoki-2.2.4-22.el5_4.2.s390x.rpm
• libica software files:
  • libica-1.3.8-0.7.s390x.rpm
  • libica-32bit-1.3.8-0.7.s390x.rpm
• libica software files:
  • libica-1.3.7-8.el5.s390.rpm
  • libica-1.3.7-8.el5.s390x.rpm
• IBM Crypto Express 2 Feature or IBM Crypto Express 3 Feature, which contain two co-processors per card.
• CP Assist for Cryptographic Function
  For more information on the IBM Crypto Express Feature and the CP Assist for Cryptographic Function, see Cryptographic Hardware Use Cases for Web Servers on Linux on IBM System z.
  
  Note: If you are running under z/VM with a shared CEX2C device, the fix for z/VM APAR VM64727 is required.

Set up Linux for System z hardware

Back to top

Before you can configure WebSphere Application Server to support hardware cryptography, you must complete the following steps to set up the Linux for System z hardware. Unless otherwise indicated, the steps in this document are identical for both the SUSE Linux Enterprise Server and Red Hat Enterprise Linux operating systems.

1. Install the OpenCryptoki, and libica software files. These software files are provided by the software vendor for your Linux operating system. Generally, these files are part of the Linux installation image.


2. Enter the following command to load the z90crypt device driver and then verify that it is running:
   • # rcz90crypt start
   • # modprobe z90crypt

   The command results in the following message:

   Loading z90crypt module done


3. Enter the following command to verify that the z90crypt daemon is running:
   
   # rcz90crypt status
   
   The command results in the following message: Checking for module z90crypt: running


4. Enter the following command to verify that the device driver has loaded and a hardware cryptography card is available:
   
   # cat /proc/driver/z90crypt
   The command results in a response that is similar to the following messages:
[root@litrwas4 ~]# cat /proc/driver/z90crypt
zcrypt version: 2.1.1
Cryptographic domain: 15
Total device count: 1
PCICA count: 0
PCICC count: 0
PCIXCC MCL2 count: 0
PCIXCC MCL3 count: 0
CEX2C count: 0
CEX2A count: 1
requestq count: 0
pendingq count: 0
Total open handles: 0
Online devices: 1=PCICA 2=PCICC 3=PCIXCC (MCL2) 4=PCIXCC(MCL3)
5=CEX2C
0060000000000000 0000000000000000 0000000000000000 0000000000000000
   
   In the previous results, the total device count is 1. This value indicates that the cryptographic device is available. Also, the previous results show that the CEX2A count field value is 1. This value indicates that the Cryptographic Express 2 Feature is in the accelerator mode.


5. Enter the following command to start the pkcsslotd daemon:
   • # rcpkcsslotd start
     
     The command results in a response that is similar to the following message:
     
     Starting pkcsslotd daemon:usermod: `root' is primary group name.
   • # /etc/init.d/pkcsslotd start
     
     The command results in a response that is similar to the following message:
     # [ OK ]


6. Enter the following command to verify that the pkcsslotd daemon is running:
   • # rcpkcsslotd status
     
     The command results in the following message:
     
     Checking for service pkcsslotd: running
   • # /etc/init.d/pkcsslotd status
     
     The command results in a response that is similar to the following message:
     
     pkcsslotd (pid 31994) is running...


7. Enter the following command to verify that the hardware cryptography card is available:
   
   # cat /proc/driver/z90crypt
   
   The command results in a response that is similar to the following messages:
   
   zcrypt version: 2.1.0
Cryptographic domain: 0
Total device count: 1
PCICA count: 0
PCICC count: 0
PCIXCC MCL2 count: 0
PCIXCC MCL3 count: 0
CEX2C count: 1
CEX2A count: 0
requestq count: 0
pendingq count: 0
Total open handles: 6
Online devices: 1=PCICA 2=PCICC 3=PCIXCC(MCL2) 4=PCIXCC(MCL3) 5=CEX2C 6=CEX2A
0050000000000000 0000000000000000 0000000000000000 0000000000000000
   
   In the previous results, the total device count value is 1. This value indicates that the cryptographic device is available. Also, the previous results show that the CEX2C count field value is 1. This value indicates that the Cryptographic Express 2 is in the coprocessor mode.
   
   Note: For the Crypto Express 2 card to successfully process cryptographic operations, the certificate must have a Public Key Modulus value that is greater than the signature value. For more information, see Appendix A: Displaying the public key modulus and signature files of a certificate. If the Public Key Modulus value is not greater, the Crypto Express 2 card in the coprocessor mode rejects the cryptographic operation. In some instances, the cryptographic device is disabled, which results in subsequent cryptographic operations being completed by the software. On the SUSE Linux Enterprise Server Version 10 SP 3 operating system, the following message is displayed in the /var/log/messages file:
   
   kernal: zcrypt: convert_type86_ica -> Unknown service rc/rs (PCIXCC/CEX2C): 8/72
   
   When you enter the # cat /proc/driver/z90crypt command, if the CEX2C value is disabled, then the command results in a d value in the Online devices field within the following messages:
   
   zcrypt version 2.1.1
Cryptographic domain: 13
Total device count: 1
PCICA count: 0
PCICC count: 0
PCIXCC MCL2 count: 0
PCIXCC MCL3 count: 0
CEX2C count: 1
CEX2A count: 0
requestq count: 0
pendingq count: 0
Total open handles: 1
Online devices: 1=PCICA 2=PCICC 3=PCIXCC(MCL2) 4=PCIXCC(MCL3) 5=CEX2C 6=CEX2A
0000000000000000 0000000000000d00 0000000000000000 0000000000000000
   
   To re-enable the device, use the vi editor to modify the /proc/driver/z90crypt file and change the d in boldface type within the previous example to e. After making the change and saving the file, the cryptographic device is re-enabled.


8. Verify whether the PKCS#11 cryptographic token is initialized. You must initialize the token before using it. To check the status of the PKCS#11 cryptographic token, enter the following command:
   
   # pkcsconf -t
   
   The command results in a response that is similar to the following messages:
   Label: IBM ICA PKCS #11
Manufacturer: IBM Corp.
Model: IBM ICA
Serial Number: 123
Flags: 0x880045
(RNG|LOGIN_REQUIRED|CLOCK_ON_TOKEN|USER_PIN_TO_BE_CHANGED|
SO_PIN_TO_BE_CHANGED)
Sessions: -1/-1
R/W Sessions: -1/-1
PIN Length: 4-8
Public Memory: 0xFFFFFFFF/0xFFFFFFFF
Private Memory: 0xFFFFFFFF/0xFFFFFFFF
Hardware Version: 1.0
Firmware Version: 1.0
Time: 10:38:35
   
   In the previous example, the label value is set to the default IBM ICA PKCS #11 value. You need to change this value. Also, the SO pin and the USER pin values are not set. Thus, this token is not initialized. If the token is initialized, there is a label value and the Flags value confirms that initialization is complete. For example:
   
   Flags: 0x44D
(RNG|LOGIN_REQUIRED|USER_PIN_INITIALIZED|CLOCK_ON_TOKEN|TOKEN_INITIALIZED)
   
   If the token is not initialized, complete the following steps:
   1. Change the label. To change the label, enter the following command:
      
      # pkcsconf -c 0 -I
      
      The command results in a response that is similar to the following information:
      Enter the SO PIN: ********
Enter a unique token label: WASCrypto
      
      The default SO pin is 87654321
   2. Set new SO and USER pins. To set the SO pin, enter the following command:
      
      # pkcsconf -c 0 -P
      
      The command results in a response that is similar to the following information:
      
      Enter the SO PIN: ********
Enter the new SO PIN: ********
Re-enter the new SO PIN: ********
      
      Enter the default pin in the first line and enter a 4-8 number pin in the second and third lines.
      
      To set the USER pin, enter the following command:
      
      # pkcsconf -c 0 -u
      
      The command results in a response that is similar to the following information:
      
      Enter the SO PIN: ********
Enter the new user PIN: ********
Re-enter the new user PIN: ********
      
      The user pin expires after its initial setting. Thus, you must change the user pin using the following command:
      
      # pkcsconf -c 0 -p
      
      The command results in a response that is similar to the following information:
      
      Enter user PIN: ********
Enter the new user PIN: ********
Re-enter the new user PIN: ********


9. Verify that the CP Assist for Cryptographic Function (CPACF) is enabled. To check the status of this function, run the following icainfo command, which is supplied by the libica package:
   
   # icainfo
   
   The command results in a response that is similar to the following information:
   
   The following CP Assist for Cryptographic Function (CPACF) operations are supported by libica on this system:
SHA-1: yes
SHA-256: yes
SHA-512: yes
DES: yes
TDES-128: yes
TDES-192: yes
AES-128: yes
AES-192: yes
AES-256: yes
PRNG: yes
   
   When the CPACF feature is active on the machine, the command displays a yes response for all of the operations on a z10 machine. Machines that are prior to z10 display a yes response for the operations that are supported by that machine type.

Configure WebSphere Application Server

Back to top

After you configure the Linux for System z hardware for cryptography, you must configure WebSphere Application Server. Ensure that you are using WebSphere Application Server Version 7.0.0.7 with the Java™ SDK cumulative fix before completing the following steps:

1. Backup your WebSphere Application Server configuration and the original files in the /opt/IBM/WebSphere/AppServer/java directory to be able to restore the original configuration later.


2. Download the unlimited jurisdiction policy files and install them in the following directory location:
   /opt/IBM/WebSphere/AppServer/java/jre/lib/security
   Complete the following steps to obtain these policy files from the IBM developerWorks Web site:
   1. Go to the following Web site: http://www.ibm.com/developerworks/java/jdk/security/index.html
   2. Click Java SE 6.
   3. Scroll down and click IBM SDK Policy files.
      The Unrestricted Java Cryptography Extension (JCE) Policy files for the SDK Web site is displayed.
   4. Click Sign in and provide your IBM intranet ID and password or register with IBM to download the files.
   5. Select the appropriate Unrestricted JCE Policy files and then click Continue.
   6. View the license agreement and then click I Agree.
   7. Click Download Now.


3. Add the com.ibm.ws.security.ltpa.forceSoftwareJCEProviderForLTPA custom property with a true value for the deployment manager, the node agent, and each application server. For more information on this custom property, read the Java™ virtual machine custom properties topic in the Version 7.0 Information Center.
   
   The following table shows the paths to follow through the administrative console to set the custom property.
   
   

   Level	Administrative console path
   Deployment manager	Click System Administration > Deployment manager. Under Server Infrastructure, expand Java and process management, and click Process definition. Under Additional properties, click Java virtual machine > Custom properties.
   Node agent	Click System Administration > Node agent > nodeagent_name. Under Server Infrastructure, expand Java and process management, and click Process definition. Under Additional Properties, click Java Virtual Machine > Custom properties.
   Application Server	Click Servers, expand Server Types, and click WebSphere application servers > server_name. Under Server Infrastructure, expand Java and process management, and click Process definition. Under Additional Properties, click Java Virtual Machine > Custom properties.



4. Change the Web server plugin-in Read / Write timeout value to zero (0) for each application server. In the administrative console, complete the following steps:
   1. Click Servers, expand Server Types, and click WebSphere application servers > server_name.
   2. Under Additional Properties, click Web server plug-in properties.
   3. In the Read/Write timeout section, verify that the Use read/write timeout option is enabled and change the Read/Write timeout value to zero (0) seconds.


5. Change the first security provider in the java.security file, which is located in the /opt/IBM/WebSphere/AppServer/java/jre/lib/security directory, as follows:
   
   #security.provider.1=com.ibm.crypto.fips.provider.IBMJCEFIPS
security.provider.1=com.ibm.crypto.pkcs11impl.provider.IBMPKCS11Impl
/opt/z_local/WebSphere/AppServer/hwcrypto.cfg security.provider.2=com.ibm.crypto.provider.IBMJCE
security.provider.3=com.ibm.jsse.IBMJSSEProvider
security.provider.4=com.ibm.jsse2.IBMJSSEProvider2
security.provider.5=com.ibm.security.jgss.IBMJGSSProvider
security.provider.6=com.ibm.security.cert.IBMCertPath
security.provider.7=com.ibm.security.cmskeystore.CMSProvider
security.provider.8=com.ibm.security.jgss.mech.spnego.IBMSPNEGO
security.provider.9=com.ibm.security.sasl.IBMSASL
security.provider.10=com.ibm.xml.crypto.IBMXMLCryptoProvider
security.provider.11=com.ibm.xml.enc.IBMXMLEncProvider
security.provider.12=org.apache.harmony.security.provider.PolicyProvider
   The second security.provider.1 entry shows the differences between the original and new java.security file.


6. Create the hwcrypto.cfg file in the /opt/z_local/WebSphere/AppServer/ directory with the following contents:
   
   #IBM 4764
name = Sample
library=/usr/lib64/opencryptoki/PKCS11_API.so
description=4764 sample config

slotListIndex = 0

disabledMechanisms = {
CKM_MD5
CKM_SHA_1
CKM_MD5_HMAC
CKM_SHA_1_HMAC
CKM_SSL3_MASTER_KEY_DERIVE
CKM_SSL3_KEY_AND_MAC_DERIVE
CKM_SSL3_PRE_MASTER_KEY_GEN
}


7. Change the Secure Sockets Layer (SSL) cell settings to use a higher-strength cipher such as DES, 3DES, or AES128. For example, change the settings to use the SSL_RSA_WITH_3DES_EDE_CBC_SHA 3DES cipher group. Complete the following steps in the administrative console to make these changes:
   1. Click Security > SSL certificate and key management.
   2. Under Configuration settings, click Manage endpoint security configurations > {Inbound | Outbound} > ssl_configuration.
   3. Under Related Items, click SSL configurations > configuration_name.
   4. Under Additional Properties, click Quality of protection (QoP) settings.
   5. In the Cipher suites section, select Custom from the Cipher suite groups and click Update selected ciphers.
   6. Verify that the SSL_RSA_WITH_3DES_EDE_CBC_SHA cipher is listed in the Selected ciphers list.
   7. Click OK and save the changes directly to the master configuration.


8. Optional: If the application server is running under a functional ID, modify the PKCS11 group to include the user. For exam
   ple, if the application server is running under the wasadmin functional ID, run the following command:
   
   usermod -G pkcs11 wasadmin
   
   This command adds the wasadmin user to the pkcs11 group.


9. Restart WebSphere Application Server.


10. Request an application, for example, snoop, and verify that the counters increase when cryptography is used. To verify, run the following command before requesting the snoop application:
    # cat /proc/driver/z90crypt
    The command results in a response that is similar to the following information:
    
    zcrypt version: 2.1.0
Cryptographic domain: 0
Total device count: 1
PCICA count: 0
PCICC count: 0
PCIXCC MCL2 count: 0
PCIXCC MCL3 count: 0
CEX2C count: 1
CEX2A count: 0
requestq count: 0
pendingq count: 0
Total open handles: 6
Online devices: 1=PCICA 2=PCICC 3=PCIXCC(MCL2) 4=PCIXCC(MCL3) 5=CEX2C 6=CEX2A
0050000000000000 0000000000000000 0000000000000000 0000000000000000
Waiting work element counts
0000000000000000 0000000000000000 0000000000000000 0000000000000000
Per-device successfully completed request counts
00000000 00000000 000803DD 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
11. Run the following command after requesting the snoop application:
    
    # cat /proc/driver/z90crypt
    
    The command results in a response that is similar to the following information:
    
    zcrypt version: 2.1.0
Cryptographic domain: 0
Total device count: 1
PCICA count: 0
PCICC count: 0
PCIXCC MCL2 count: 0
PCIXCC MCL3 count: 0
CEX2C count: 1
CEX2A count: 0
requestq count: 0
pendingq count: 0
Total open handles: 8
Online devices: 1=PCICA 2=PCICC 3=PCIXCC(MCL2) 4=PCIXCC(MCL3) 5=CEX2C 6=CEX2A
0050000000000000 0000000000000000 0000000000000000 0000000000000000
Waiting work element counts
00000000 0000000000000000 0000000000000000 0000000000000000
Per-device successfully completed request counts
00000000 00000000 000803EB 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Configure IBM HTTP Server to use hardware cryptography

Back to top

After you configure WebSphere Application Server to enable hardware cryptography, configure the IBM HTTP Server. Complete the following steps:

1. Obtain a personal certificate from a recognized certificate authority. For more information, read about creating a certificate authority request in the Version 7.0 Information Center. For testing purposes, these steps use a self-signed certificate.


2. Under the /opt/IBM/HTTPServer/java/jre/lib/ext/ directory, remove the gskikm.jar file.

   IMPORTANT: Do not perform this step if you are using IBM HTTP Server Version 8.0 or higher.



3. Run iKeyman from the /opt/IBM/HTTPServer/bin directory.


4. Click Key Database File > Open and select CMS Cryptographic Token for the Key database type value.


5. Enter PKCS11_API.so in the File Name field.


6. Enter /user/lib64/opencryptoki in the Location field.


7. Click OK. The cryptographic token information, which was configured with the "Set up the Linux for System z hardware" steps, shows in the Open Cryptographic Token window.
   You must enter the Cryptographic Token Password. This value is the User Pin value that you previously set in the "Set up the Linux for System z hardware" steps.


8. Clear the Open existing secondary key database check box.


9. Click OK. A window opens with the key database information.


10. Click Create > New Self-Signed Certificate.


11. Enter a value in the Key Label, Version, and Key Size fields. Also, optionally, enter a value for the other fields on the Create New Self-Signed Certificate panel.


12. Click OK. The new self-signed certificate is displayed in the list of available personal certificates.
    Note: Use a self-signed certificate for testing purposes only. For production, obtain a certificate from a known certificate authority. The Key database content lists the name of the certificate. This value is also used in the httpd.conf file for a subsequent step.
13. Modify the PKCS11 group to contain the "nobody" user. For this example, the "nobody" user is running the IBM HTTP Server.
    Enter the following commands to modify the group:
    
    # cat /etc/group | grep pkcs11
pkcs11:!:64:root
# usermod -G pkcs11 nobody
# cat /etc/group | grep pkcs11
pkcs11:!:64:root,nobody
14. Stash the user Pin # into a file so that it is available to IBM HTTP Server. Enter the following command:
    
    /opt/IBM/HTTPServer/bin # ./sslstash -c /opt/z_local/HTTPServer/ssl/ihsstash crypto user_pin
    
    This command creates a file called ihsstash in the /opt/z_local/HTTPServer/ssl directory.


15. Update the httpd.conf file to enable the IBM HTTP Server to use the cryptography hardware. The changes are needed in a virtual host stanza that uses HTTPS. For example:
    
    ### Enable SSL

    LoadModule ibm_ssl_module modules/mod_ibm_ssl.so 

    
    Listen 443
    <VirtualHost myhost.com:443>
    .....
    
    ### Enable SSL for Virtual Host
    SSLEnable
    SSLProtocolDisable SSLv2
    SSLCipherSpec 3A
    KeyFile /opt/z_local/HTTPServer/ssl/certificate_name.kdb
    SSLServerCert WASCrypto:ihscert
    SSLStashfile /opt/z_local/HTTPServer/ssl/ihsstash
    SSLPKCSDriver /usr/lib/opencryptoki/PKCS11_API.so
    ############################
    # Symmetric offload
    SSLAttributeSet 417 549
    ############################
    SSLCachePortFileName /opt/z_local/HTTPServer/logs/siddport
    </VirtualHost>
    SSLDisable
    In the previous example:
    
    • WASCrypto is the token label that was assigned during the initialization process for the PKCS#11 cryptographic token.
    
    
    • The SSLAttributeSet 417 549 directive enables the use of the CPACF for the acceleration of encryption and decryption operations with the use of the 3DES cipher.
    
    
    • The 3DES cipher is specified by specifying the SSLCipherSpec 3A directive.
16. Restart IBM HTTP Server and verify that the z90crypt shows one open handle. Enter the following command:
    
    /opt/z_local/HTTPServer/bin # cat /proc/driver/z90crypt
    
    The command results in a response that is similar to the following information:
    
    zcrypt version: 2.1.0
Cryptographic domain: 14
Total device count: 1
PCICA count: 0
PCICC count: 0
PCIXCC MCL2 count: 0
PCIXCC MCL3 count: 0
CEX2C count: 1
CEX2A count: 0
requestq count: 0
pendingq count: 0
Total open handles: 1
Online devices: 1=PCICA 2=PCICC 3=PCIXCC(MCL2) 4=PCIXCC(MCL3) 5=CEX2C 6=CEX2A
0000000005000000 0000000000000000 0000000000000000 0000000000000000
Waiting work element counts
0000000000000000 0000000000000000 0000000000000000 0000000000000000
Per-device successfully completed request counts
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000


17. In a browser, go to http://HTTP_server_host_name and the Per-device successfully completed request counts message displays.
    
    Enter the following command:
    
    /opt/z_local/HTTPServer/conf # cat /proc/driver/z90crypt

The command results in an increase in the open handle count and a change in the Per-device successfully completed request counts information that is similar to the following information:

zcrypt version: 2.1.0
Cryptographic domain: 14
Total device count: 1
PCICA count: 0
PCICC count: 0
PCIXCC MCL2 count: 0
PCIXCC MCL3 count: 0
CEX2C count: 1
CEX2A count: 0
requestq count: 0
pendingq count: 0
Total open handles: 2
Online devices: 1=PCICA 2=PCICC 3=PCIXCC(MCL2) 4=PCIXCC(MCL3) 5=CEX2C 6=CEX2A
0000000005000000 0000000000000000 0000000000000000 0000000000000000
Waiting work element counts
0000000000000000 0000000000000000 0000000000000000 0000000000000000
Per-device successfully completed request counts
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000001 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Appendix A: Displaying the public key modulus and signature files of a certificate

Back to top

Back to Step 6: Set up Linux for System z hardware

1. Extract the certificate and public key to a file in the Privacy Enhanced Mail (PEM) format. To extract the certificate and the public key, you can use the iKeyman Extract function. The contents of the file will look similar to the following example:
   
   -----BEGIN CERTIFICATE----- MIICuzCCAiSgAwIBAgIIEX26UbcVyxgwDQYJKoZIhvcNAQEFBQAwejELMAkGA1UEBhMCVVMxDDAK BgNVBAoTA0lCTTEOMAwGA1UECxMFbGl0cncxDjAMBgNVBAsTBWxpdHJ3MRkwFwYDVQQLExBSb290 IENlcnRpZmljYXRlMSIwIAYDVQQDExlsaXRyd2FzNC5sdGljLnBvay5pYm0uY29tMB4XDTA5MTIw ODE0MTg1MFoXDTEwMTIwODE0MTg1MFowXjELMAkGA1UEBhMCVVMxDDAKBgNVBAoTA0lCTTEOMAwG A1UECxMFbGl0cncxDjAMBgNVBAsTBWxpdHJ3MSEwHwYDVQQDExhhbmR5bG54MS5yYWxlaWdoLmli bS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALrZdarmgRxkb5vlsEF3gvNuwL412ewY 8hnlr6Eu1TD1GyqzB8Y8C+TLSMviIaCb/wMJFLuoskgJxGrwKonwmoTBSIlvzGvxMrYy2GMppbo/ 2rDfJ74zEBZFOjw5zKw0PyTMq4ZS4D8NInOwPTgHN+46t16JUD3e9zz5DVOquqq/AgMBAAGjZjBk ME8GA1UdEQRIMEaBRFByb2ZpbGVVVUlEOmNuPWFuZHlsbngxLnJhbGVpZ2guaWJtLmNvbSxvdT1s aXRydyxvdT1saXRydyxvPUlCTSxjPVVTMBEGA1UdDgQKBAhFJGh4wtRLEjANBgkqhkiG9w0BAQUF AAOBgQB67HwUPxPJnAwRq8QZb8usbofYVZZiA8gV/Yjk6icF+ekAsTd2fb3xAuWQWrpUaz7EOtLh /79SX5ffRMFKKqwlM0FFY6QVVZuSyRZeHtrWEVT3N/2Y4AWa5qJbKeHv8TYSLIm+qe1OQTIuR2rP o7/3yK1lxuEq7pIyeHZJKOe1Sw== -----END CERTIFICATE-----


2. Use the openssl x509 command to display the contents of the PEM-formatted certificate:
   
   # openssl x509 -in badcert.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
11:84:0e:57:d0:36:af:53
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=IBM, OU=zWAS61FP3Dmgr, OU=zWAS61FP3Cell, OU=Root >Certificate, CN=lnx00195.es.ssmb.com Validity Not Before: Dec 29 05:06:05 2009 GMT
Not After : Dec 29 05:06:05 2010 GMT
Subject: C=US, O=IBM, OU=zWAS61FP3LNX00195Node, OU=zWAS61FP3LNX00195Node, CN=andylnx1.raleigh.ibm.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:86:24:b9:f1:7d:84:70:20:e9:d7:0a:63:43:ba:
cf:3b:a9:b2:8b:69:8b:d3:4d:d1:68:47:5c:eb:5b:
24:bf:6c:41:4e:26:43:b0:71:98:29:f2:5c:1d:82:
3b:28:9f:fa:e0:79:07:35:03:9f:47:cc:4d:2c:bc:
87:32:39:d2:55:3f:cf:97:95:02:47:f9:16:8a:e5:
35:4d:49:e4:64:9b:3b:3e:29:6b:75:2b:33:9b:fb:
2d:3c:6c:54:44:93:11:0e:82:cc:11:81:ea:02:df:
a1:78:c7:b8:28:7c:a0:da:d8:35:29:c4:5f:e6:5a:
19:1b:3c:f8:d9:f6:21:08:e9
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
email:ProfileUUID:CN=andylnx1.raleigh.ibm.com,
OU=zWAS61FP3LNX00195Node, OU=zWAS61FP3LNX00195Node, O=IBM, C=US
X509v3 Subject Key Identifier:
44:EF:FC:72:07:82:CF:83
Signature Algorithm: sha1WithRSAEncryption
ad:21:bc:ca:30:74:87:2b:95:82:f7:aa:a0:20:92:27:3e:48:
ca:ce:7c:47:9a:d7:c4:2d:66:a7:5d:f4:c8:69:40:bb:cd:8c:
95:e1:e0:ed:15:82:db:a6:db:19:b3:77:58:ef:58:79:c8:ca:
dc:02:b0:3e:15:ba:7d:03:8a:2c:f0:af:79:40:32:1a:ab:a1:
22:ab:ac:d2:75:4e:98:b5:d4:f3:9f:86:94:1b:ed:2b:d9:45:
3f:e2:e7:fe:89:a7:41:02:7f:c0:8b:99:79:af:5c:4e:2b:28:
fb:b3:22:66:f9:43:cd:c1:4b:47:08:e4:7f:58:d1:02:36:62:
d9:94
   
   Note: In the previous example, the 1024-bit Modulus value, which does not include the leading 00, is less than the 1024-bit Signature value.
   
   In the following example, the Modulus value is greater than the Signature value:
   
   # openssl x509 -in goodcert.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
11:7d:ba:51:b7:15:cb:18
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=IBM, OU=litrw, OU=litrw, OU=Root Certificate,
CN=litrwas4.ltic.pok.ibm.com
Validity
Not Before: Dec 8 14:18:50 2009 GMT
Not After : Dec 8 14:18:50 2010 GMT
Subject: C=US, O=IBM, OU=litrw, OU=litrw, CN=andylnx1.raleigh.ibm.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:ba:d9:75:aa:e6:81:1c:64:6f:9b:e5:b0:41:77:
82:f3:6e:c0:be:35:d9:ec:18:f2:19:e5:af:a1:2e:
d5:30:f5:1b:2a:b3:07:c6:3c:0b:e4:cb:48:cb:e2:
21:a0:9b:ff:03:09:14:bb:a8:b2:48:09:c4:6a:f0:
2a:89:f0:9a:84:c1:48:89:6f:cc:6b:f1:32:b6:32:
d8:63:29:a5:ba:3f:da:b0:df:27:be:33:10:16:45:
3a:3c:39:cc:ac:34:3f:24:cc:ab:86:52:e0:3f:0d:
22:73:b0:3d:38:07:37:ee:3a:b7:5e:89:50:3d:de:
f7:3c:f9:0d:53:aa:ba:aa:bf
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
email:ProfileUUID:cn=andylnx1.raleigh.ibm.com,ou=litrw,ou=litrw,o=IBM,c=US
X509v3 Subject Key Identifier:
45:24:68:78:C2:D4:4B:12
Signature Algorithm: sha1WithRSAEncryption
7a:ec:7c:14:3f:13:c9:9c:0c:11:ab:c4:19:6f:cb:ac:6e:87: d8:55:96:62:03:c8:15:fd:88:e4:ea:27:05:f9:e9:00:b1:37: 76:7d:bd:f1:02:e5:90:5a:ba:54:6b:3e:c4:3a:d2:e1:ff:bf: 52:5f:97:df:44:c1:4a:2a:ac:25:33:41:45:63:a4:15:55:9b: 92:c9:16:5e:1e:da:d6:11:54:f7:37:fd:98:e0:05:9a:e6:a2: 5b:29:e1:ef:f1:36:12:2c:89:be:a9:ed:4e:41:32:2e:47:6a: cf:a3:bf:f7:c8:ad:65:c6:e1:2a:ee:92:32:78:76:49:28:e7: b5:4b