Showing posts with label webseal keystore. Show all posts
Showing posts with label webseal keystore. Show all posts

Saturday, January 12, 2013

Tivoli Access Manager Certificate Management

This is the best Technote I found from IBM on TAM Certificate management. Keeping a copy here in case the original note gets deleted. http://www-01.ibm.com/support/docview.wss?uid=swg21516849

What needs to be considered in a TAM environment regarding certificate expiration?

All Tivoli Access Manager (TAM) components rely on SSL. At a minimum the components use SSL to communicate with each other. They can also use SSL to communicate with other client applications, registry servers, etc. The keystores used in a TAM environment are usually either CMS key database format (kdb) or a Java keystore (jks). When using a kdb file, as long as you're using a .sth file to stash the password of your kdb file, you can use the "/opt/PolicyDirector/sbin/dispkdb -f <kdb file>" command to view the contents of a kdb file. This will show you the expiration date of the keystore password (if you see 1969 then it means password is not set to expire) as well the certificate information such as the names, labels, date created, and expiration dates. This allows you to easily see when a certificate will expire.Most people do use the sth file, but if you are not using it and have the kdb password configured in your config file (webseal, ivmgr, etc) then you will need to use the gsk7ikm, gsk7cmd, or gsk7capicmd command to open the kdb file with your password and check the expiration dates that way.With WebSEAL, there is one kdb file which you will need to monitor for sure, which is the following (by default, from the webseald-<instance>.conf)
webseal-cert-keyfile = /var/pdweb/www-default/certs/pdsrv.kdbThis is where you store your own certificates, so you need to manage those.Also, if you're using SSL to your LDAP server, you should monitor the kdb file specified in the [ldap] "ssl-keyfile" attribute of your webseald-default.conf, ivacld.conf, ivmgrd.conf, etc.Also on each of the TAM components you will find another kdb file defined in the [ssl] "ssl-keyfile" attribute (for example "default-webseald.kdb"). This is the keystore used to talk to the TAM components. You do not need to worry much about these since they are mostly self-managing, and their passwords are randomly generated at configuration time (meaning that nobody knows what the password is). By default, they will refresh themselves before the certificates expire automatically. However, these updated certificates cannot be used until the process is restarted. To avoid problems, the process must be restarted before the certificate in memory expires.
Basically, when one of the components is configured, such as webseal, the Policy Server will create a certificate for it to use. The lifetime of this certificate is controlled by the [ssl] "ssl-cert-life" attribute in the ivmgrd.conf file (by default 365 days). When webseal sees that the certificate is past it's half-life (6 months by default) then it will ask the policy server to generate a new one for it. However webseal needs to be re-started to start using this new certificate, before the old one expires. As such, it's recommended to re-start the processes at least twice for every "ssl-cert-life"...or every 6 months by default.If your processes are not restarted regularly, you can change the ssl certificate lifetime to something longer (2yrs, 5yrs, 10yrs, etc) so that you don't need to re-start the processes later on.- To change the Policy Server's certificate and certificate lifetime to say 5 yrs (1826 days) you can run the following command on the Policy Server system..../opt/PolicyDirector/sbin/mgrsslcfg -chgcert -l 1865and then re-start the policy server (pd_start restart)- In order to get a new certificate with a new certificate lifetime on the WebSEALs, pdacld, etc, you would need to refresh the certificate for EACH instance.../opt/PolicyDirector/sbin/svrsslcfg -chgcert -f cfg_file [-A admin_id] [-P admin_pwd]-f cfg_file Configuration file path and name. This is a requiredparameter and should be your webseald-<instance>.conf, ivacld.conf, ivmgrd.conf, etc.-P admin_pwd The Tivoli Access Manager Administrator password. If thisparameter is not specified you will be prompted for thepassword.-A admin_id The Tivoli Access Manager administrator name. If notspecified, this parameter defaults to "sec_master"and then -restart the processes.Other than this, you will also need to keep an eye on your LDAP server's certificates for expiration. For Tivoli Directory Server (TDS) this kdb file would be configured in your LDAP instance's ibmslapd.conf under the ibm-slapdSslKeyDatabase attribute.Lastly, if you need to look at jks file for certificates (used if you have a java application using TAM, WAS, etc) you can view the contents of the jks with the following command...keytool -list -v -keystore <jksfilename> -storetype JCEKShit enter for passwordIn the properties file created by the SvrSslCfg command, if you have "certrefresh=true" then this certificate will update itself once the application is re-started after the halfway point of the certificate's life (ssl-cert-life in ivmgrd.conf).

Monitoring these certificates is the responsibility of the administrators. Your solution could be as simple as putting a note on your calendar a month before a certificate is to expire, or you could decide to implement automated processes to query the kdb files regularly and notify you when a certificate will expire....it's up to each administrator to determine what is suitable for them.

Thursday, March 15, 2012

Create a new webseal key database file (webseald.kdb) when corrupted.

How to create a NEW keydatabase for webSEAL instance.

Sometimes by mistake if other instance's certificate is copied over another.
In that case, we can follow the similar steps but the only difference we need to delete all the certs from "/var/pdweb/keytab-<instance>/" location and then perform steps directly on "/var/pdweb/keytab-<instance>/" path (i.e. no need to create a temp directory and replace the certificate).
 It sometimes gets corrupted during the auto refresh of the certificate.

Most common error we see in such cases is as below:

1) 
HPDBA0230E. The certificate label or DN is invalid

OR

2)

HPDCF0061E The function, GSKKM_GetKeyItemByLabel(), returned the error 
code: 0x00000075. 
HPDCF0117E An error occurred in the "IKeyMan" API. Configuration 
failed. 
SSL configuration failed.

Steps to create webSEAL.kdb file when its corupted with above errors:

Before starting with the steps make sure the java path is configured. If not you may export it like below:

export PATH=/opt/ibm/ldap/V6.1/java/bin/:/usr/local/ibm/gsk7/bin/:$PATH

1) Make a temp dir and change to it
mkdir /var/pdweb/keytab-<instance>/temp
cd /var/pdweb/keytab-<instance>/temp

2) Create a mostly empty kdb
gsk7cmd -keydb -create -db replaceicert-webseald.kdb -pw passw0rd -stash -type cms -expire 7200

3)  Add Policy Director CA certificate.

# Note if the /var/PolicyDirector/keytab/pdcacert.b64 doesn't exist you need to get it from the policy server first.

gsk7cmd -cert -add -db replaceicert-webseald.kdb -pw passw0rd -file /var/PolicyDirector/keytab/pdcacert.b64 -label "Policy Director CA"

4) Remove the other CAs
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Entrust.net Global Secure Server Certification Authority"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Entrust.net Global Client Certification Authority"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Entrust.net Client Certification Authority"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Entrust.net Certification Authority (2048)"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Entrust.net Secure Server Certification Authority"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 3 Secure Server CA"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 3 Public Primary Certification Authority"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 2 Public Primary Certification Authority"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 1 Public Primary Certification Authority"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 4 Public Primary Certification Authority - G2"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 3 Public Primary Certification Authority - G2"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 2 Public Primary Certification Authority - G2"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 1 Public Primary Certification Authority - G2"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 4 Public Primary Certification Authority - G3"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 3 Public Primary Certification Authority - G3"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 2 Public Primary Certification Authority - G3"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "VeriSign Class 1 Public Primary Certification Authority - G3"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Thawte Personal Premium CA"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Thawte Personal Freemail CA"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Thawte Personal Basic CA"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Thawte Premium Server CA"
gsk7cmd -cert -delete -db replaceicert-webseald.kdb -pw passw0rd -label "Thawte Server CA"

5) Create a self signed cert with the correct subject
gsk7cmd -cert -create -db replaceicert-webseald.kdb -pw passw0rd -dn "CN=<instance>-webseald-<hostname>,OU=Default,O=Access Manager,C=US" -label "PD Server"

6) Copy the new keystore and sth file over the existing for the non-working instance.

Leave the temp dir
cd ..
cp /var/pdweb/keytab-<instance>/temp/replaceicert-webseald.kdb /var/pdweb/keytab-<instance>/<instance>-webseald.kdb
cp /var/pdweb/keytab-<instance>/temp/replaceicert-webseald.sth /var/pdweb/keytab-<instance>/<instance>-webseald.sth

7) Correct the permissions
chmod 600 /var/pdweb/keytab-<instance>/<instance>-webseald.kdb
chmod 600 /var/pdweb/keytab-<instance>/<instance>-webseald.sth
chown ivmgr:ivmgr /var/pdweb/keytab-<instance>/<instance>-webseald.kdb
chown ivmgr:ivmgr /var/pdweb/keytab-<instance>/<instance>-webseald.sth

8) Change the password and request a new cert from the Policy Server
svrsslcfg -chgpwd -f /opt/pdweb/etc/webseald-<instance>.conf
svrsslcfg -chgcert -f /opt/pdweb/etc/webseald-<instance>.conf

9) Verify the key is correct
/opt/PolicyDirector/sbin/dispkdb -f /var/pdweb/keytab-<instance>/<instance>-webseald.kdb

10) Start the WebSEAL server.
pdweb start <instance>

11) If everything works remove the temp dir and the temp key
rm -r /var/pdweb/keytab-<instance>/temp