La valoración de la prueba personal en particular

1.

You will need to contact your certificate provider prior to the expiry date of the certificate to request the certificate renewal. Check with your certificate provider for instructions. Give yourself plenty of time to renew your certificate before it expires. One to 2 weeks prior to the certificate expiration is probably good. You normally do not need to go through the full Certificate Signing Request that you did when you first created the certificate as most certificate providers will renew your certificate without an additionsl CSR (Certificate Signing Request).

2.

Next, you will need to FTP the renewed certificate you received to your iSeries. Refer to section 2.1.5.1, steps 5 m through o for instructions to FTP the file you received from your certificate provider up to the IFS on your system. After FTPing the certificate to your system, continue with step 3.

3. Go to the Tasks page (Figure 3-11) via the iSeries HTTP Administration server using the URL: http://your_server_name.com:2001

•

Supply the user ID and password (must have IOSYSCFG, *ALLOBJ, *SECADM authority).

•

Select Digital Certificate Manager.

•

Click on Select a Certificate Store.

Figure 3-11 Digital Certificate Manager page

4.

Enter the Certificate store password as shown in figure 3-12 and click Continue.

Figure 3-12 Certificate Store and Password page

On the Current Certificate Store screen, Click on Manage Certificates to expand the selection and then click on the Renew certificate link.

Figure 3-13 Current Certificate Store page

5.

Choose the certificate that you wish to renew and then click the Renew button as shown in Figure 3-14.

Figure 3-14 Renew Certificate page

6.

Choose VeriSign or other Internet Certificate Authority (CA) as shown in Figure 3-15 and click Continue.

Figure 3-15 Select a Certificate Authority page

7.

Choose No – Import the renewed signed certificate from an existing file and click Continue.

Figure 3-16 Renew Certificate page

8.

Enter the path to the Import File that you FTPed up to the system in step 2 as shown in Figure 3-17. When done, click Continue.

Figure 3-17 Import Server or Client Certificate page

9. You will see the Certificate Renewed Successfully page as shown in Figure 3-18. Here you will select the application/s that you want to assign this renewed certificate to.

Figure 3-18 Certificate Renewed Successfully page

10. Scroll down and check all applications that you wish to assign this certificate to and click Continue when finished.

Figure 3-19 Certificate Renewed Successfully page

Figure 3-20 Application Status page

11.

When you have finished, you will see the page displayed above in Figure 3-20.

12.

You may need to cycle the application/s using the renewed certificate. Test the application and ensure that if functions properly.

Additional material

Certificate store structure and locations

Certificate Authority, server and user certificates and related information are stored in different directories on the AS/400 system. DCM provides a default store location for you.

Certificate Authority store location

DCM uses a fixed store location for the local CA. You cannot change its location. After you create a local CA you will see the following files in a specific directory. These directories must be

protected from unauthorized access. The directory and files for the CA objects are:

/QIBM/UserData/ICSS/Cert/CertAuth Directory

CA.TXT CA certificate and public key

DEFAULT.KDB CA certificate and CA private key DEFAULT.POL CA policy file

DEFAULT.STH Stashed password for accessing the local CA KDB.

/QIBM/UserData/ICSS/Cert/Download/CertAuth

Directory containing the CA certificate available for distribution to clients CA.CACRT CA certificate in binary format

System certificate store location

You can select two types of locations to store a certificate. OS/400 server applications, such as HTTP and Telnet, can only use certificates stored in the *SYSTEM certificate store. Another selection is OTHER, which enables you to store certificates in any directory on the AS/400 Integrated File System (IFS).

The directory and file structure is as follows:

*SYSTEM (default store location) /QIBM/UserData/ICSS/Cert/Server

Directory

OTHER

You can specify another directory such as /your_directory_name to store certificates. Customer applications that are written to use SSL_Init (instead of the newer SSL_Init_App) can make more use of this. System administrators can also make use of this certificate store for certain kinds of backups or testing before moving into their production environment. Some functions, such as exporting certificates from certificate stores created while the system was on a previous release, may also make use of this. Again do not use this if you want to use OS/400 secure applications.

Cleaning up DCM

Here are the locations to cleanup in order to start over with DCM (NOTE: We'll want to cleanup all files in these locations):

These files can be deleted allowing you to start from scratch. Prior to deleting the *System store you should verify that the store does not contain certificates that have been purchased or are currently in use. There is no way to recover files thathave not been backed up after performing this operation.

Only remove *STMF files, Do NOT remove the folders

/QIBM/UserData/ICSS/Cert/Server/ --> This location holds the *SYSTEM store /QIBM/UserData/ICSS/Cert/CertAuth/ --> This location holds the Local CA store /QIBM/UserData/ICSS/Cert/Download/CertAuth/CertAuth --> This locations holds a file that gets created when a CA is created (so that you can't create it again).

Once all the files are cleared from these locations, get out of DCM and go back into it.

You should now have the option to create a Local CA (which will in turn create a

*SYSTEM store and a server/client cert in the store).

Also, from command line on the iSeries issue this command to clean up Cache:

CALL QSOMAINT PARM('10' '3')

Migrating to New Hardware

Recovery . . . : Remove "sslmode on" from your configuration file or install AC1, AC2 or AC3 and try to start the server again.

To correct the error, on an iSeries command line type the following:

CALL QCAP3/QYAC3INAT

Local CA Certificate Parameters

– Key size. You may select 512, 768, 1024, or 2048. It is true that the larger the key size the more secure the encryption level is, but a larger key size also creates more overhead on the system and the network.

– Password: This will be used to access the Local Certificate Authority certificate store. You will need to know this password in the future so follow whatever process you have in place to document passwords of this nature.

– Certificate Authority (CA) name: This is the name that will be displayed as the issuer of server certificates.

– Organization unit: This is an optional field. It may be used for accounting type purposes.

– Organization name: This is the name of the person or group that is responsible for operating and maintaining policy for this Certificate Authority.

– Locality or city: This parameter is not required. We supplied the value Atlanta.

– State or province: Note that this parameter requires at least 3 letters. It is best to spell out the state or province name completely. If you ever decide to change to a well know issuer of certificates the full name will be required when requesting certificates.

– Country or region: We supplied the value US.

– Validity period of Certificate Authority: Sets the length of time, in days, that the Certificate Authority certificate is valid. Certificates that are issued by this CA will also expire on or before this time period is reached.

Server Certificate Parameters

– Key size. As with the Certificate authority you may select 512, 768, 1024, or 2048. But keep in mind that the larger key size, although more secure, creates more overhead.

– Certificate label is just the name the certificate will be referred to as, in our case we called it iSeriesftp. There are no implications other than you want to make the name descriptive enough that its purpose is easily recognizable.

– Certificate store password is used to secure the certificate store. You need to follow your security guidelines for choosing the password.

– Common name parameter should be a meaningful identifier. If you plan to use the certificate for browser access, this becomes one of the more important fields on this screen. In this case, the best way to complete this field is to use the fully qualified host and domain name that is listed in the Change TCP/IP Domain (CHGTCPDMN) screen. When you make a secure connection (from a browser) and the Common name does not match the configured fully qualified domain name there is a warning that is displayed to the user.

Although the warning does not stop the connection it is a nuisance that can be avoided.

– The Organization unit parameter is not a required field. We used IT Dept again, in keeping with the scenario.

– The Organization name should reflect the name of the group of users that will take advantage of the certificate.

– Locality or city does not need to be supplied, but we used the location of the server.

– The State or province field is a required parameter and must contain at least three characters. We suggest you spell out your location completely.

– Country or region must be filled in with a two character abbreviation of your country or region.

Note: The remaining fields on this screen are used to further secure a Virtual Private Network (VPN) connection. Much like the process we are completing now when VPN is used SSL is configured to provide client certificates as an added level of security.

Public Certificates versus Private Certificates

Once you decide to use certificates, you need to choose the type of certificate implementation that best suits your security needs. The choices that you have for obtaining your certificates include:

• Purchasing your certificates from a public Internet Certificate Authority (CA).

• Operating your own Local CA to issue private certificates for your users and applications.

• Using a combination of certificates from public Internet CAs and your own Local CA.

Which of these implementation choices you make depends on a number of factors, one of the most important being the environment in which the certificates are used. Here's some information to help you better determine which implementation choice is right for your business and security needs.

Using public certificates

Public Internet CAs issue certificates to anyone who pays the necessary fee. However, an Internet CA still requires some proof of identity before it issues a certificate. This level of proof varies, though, depending on the identification policy of the CA. You need to evaluate whether the stringency of the identification policy of the CA suits your security needs before deciding to obtain certificates from the CA or to trust the certificates that it issues. As Public Key Infrastructure for X.509 (PKIX) standards have evolved, some public CAs now provide much more stringent identification standards for issuing certificates. While the process for obtaining certificates from such PKIX CAs is more involved, the certificates the CA issues provide better assurance for securing access to applications by specific users. Digital Certificate Manager (DCM) allows you to use and manage certificates from PKIX CAs that use these new certificate standards.

You must also consider the cost associated with using a public CA to issue certificates. If you need certificates for a limited number of server or client applications and users, cost may not be an important factor for you. However, cost can be particularly important if you have a large number of private users that need public certificates for client authentication. In this case, you need to also consider the administrative and programming effort needed to configure server applications to accept only a specific subset of certificates that a public CA issues.

Using certificates from a public CA may save you time and resources because many server, client, and user applications are configured to recognize most of the well-known public CAs.

Also, other companies and users may recognize and trust certificates that a well-known public CA

Using private certificates

If you create your own Local CA, you can issue certificates to systems and users within a more limited scope, such as within your company or organization. Creating and maintaining your own Local CA allows you to issue certificates only to those users who are trusted members of your group. This provides better security because you can control who has certificates, and therefore who has access to your resources, more stringently. A potential disadvantage of maintaining your own Local CA is the amount of time and resources that you must invest. However, Digital Certificate Manager (DCM) makes this process easier for you.

When you use a Local CA to issue certificates to users for client authentication, you need to decide where you want to store the user certificates. When users obtain their certificates from the Local CA through DCM their certificates are stored with a user profile by default. However, you can configure DCM to work with Enterprise Identity Mapping (EIM) so that their certificates are stored in a Lightweight Directory Access Protocol (LDAP) location instead. If you prefer not to have user certificates associated or stored with a user profile in any manner, you can use APIs to programmatically issue certificates to non-iSeries users.

Troubleshooting

Troubleshooting ADMIN Server Problems

If the *ADMIN server fails to start, you will need to determine the reason why and take corrective action.

1.

On an iSeries command line, type WRKSPLF QTMHHTTP. This will display spooled files that belong to user QTMHHTTP (this is the user that is responsible for starting the *ADMIN server. Look at the last spooled file belonging to QTMHHTTP and it should tell you why the

*ADMIN server failed to start.

2. Edit the ADMIN custom config file that resides in the IFS

a.

On the iSeries run the command WRKLNK and navigate to directory /QIBM/UserData/HTTPA/admin/conf/

b.

Edit the file admin-cust.conf and look for any invalid directives, if you can not determine the cause of the error, comment out all of the lines in the custom config as shown in the following example using the # character.

#---# The following directives should be added to

# /QIBM/UserData/HTTPA/admin/conf/admin-cust.conf

# and uncommented in order to enable SSL for ADMIN.

Restart the *ADMIN server and ensure that it starts correctly.

Troubleshooting - Problem Determination for FTP

If you detect a problem when using FTP, use the following flow chart to identify the cause after using the flow chart for general TCP/IP problems. The cause lists that follow list steps to help you identify the cause of the problem.

FTP Problem Analysis

Cause List A

1.

Is there is a long delay between connecting to the iSeries^(TM) FTP server and receiving a prompt for a user id? If so, check the configuration of the domain name server on your iSeries. The FTP server performs a DNS query as soon as a new connection is received. DNS problems may cause the server to hang for several

3. Check to see if the remote logon requires a password if a password was requested. Some systems request a password, but the connection can fail because it is not required.

4. Set up a password on the remote system if required. You may have to restart if you change the security information on the system.

5. Check your user ID and password by attempting to sign on to your remote system. If you are unable to do so, contact the system owner to verify that your user ID and password are correct.

Cause List B

1. Make sure binary mode is in effect if you are transferring binary files.

2. Check to be sure the mapping tables on both the client and server systems are compatible. You need only do this if you are using your own mapping tables.

3. Check to see that the correct CCSID has been specified for the transfer. If not, use the TYPE or LTYPE subcommand to set the correct CCSID value before the transfer is performed.

4. Create a file on the system that you are planning to store data into. Set the proper record length, number of members, and number of increments. Try the data transfer again and verify that it was successful.

5. Make sure that you are authorized to use the file and the file members.

6. Check to see if the transfer file contains packed decimal or zoned decimal data.

7. If you are transferring a Save file, verify that the appropriate method was used.

Cause List C

1. Check file size limits on the remote system.

2. Check to see if the FTP server timer ended. The iSeries server time-out value can be set using the QUOTE TIME command.

3. Use the NETSTAT command to verify that the *LOOPBACK interface is active.

Then re-create the problem doing FTP LOOPBACK (iSeries-to-iSeries internally).

• If the problem cannot be recreated, it is probably a remote system problem.

• If you can re-create the problem, do the following:

The trace is a spooled file in the default output queue of the system associated with the FTP server job.

f. Send in that spooled file.

g. If the problem was on the iSeries FTP client, a trace can be obtained using the DEBUG 100 client subcommand.

h. When running the FTP client interactively, use the F6 (Print) key to create a spool file that contains a history of the FTP client subcommands entered, and the associated FTP server replies. When the FTP client is run in batch unattended mode, then this history of subcommands and server replies is written to the specified OUTPUT file. For more details, see "FTP as Batch Job".

Documentation and Links

Several good publications exist in downloadable PDF format at the following site:

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp

Good publications to get here include:

Digital Certificate Manager – V5R3 book on the basics of DCM

Redbook SG24-5659-00 - AS/400 Internet Security: Developing a Digital Certificate Infrastructure Redbook SG24-6168-00 - iSeries Wired Network Security OS/400 V5R1 DCM and Cryptographic

Enhancements (highly recommend this Redbook-most of it is current in V5R3 and V5R4)

http://www.rsasecurity.com/rsalabs/faq/3-1-5.html

RSA article on how large a key should be used in the RSA cryptosystem. iSeries DCM utilizes RSA cryptography in its key stores.

In document Los límites a la revisión de la valoración de la prueba por el tribunal de segunda instancia penal (página 45-62)