LDAP Server: DSEE 6.2 on Solaris 10
LDAP Client: Openldap on RHEL 5.1

Would anyone know how to get the correct client cert files to the client machine? I copied the cacert.pem, cert8.db, key3.db and secmod.db files from the server. I copied the files into /etc/openldap/cacerts directory. So, when I run the /usr/bin/authconfig-gtk tool and get everything configured, I click OK to save the configurations, the message I get back is:

4722:error:0906D06C:PEM routines:PEM_read_bio:no start lineem_lib.c:644:Expecting: TRUSTED CERTIFICATE

From this website http://www.sun.com/bigadmin/features...p_part3.jsp#P3 it has:
-------------------------------------------------------------------------
a. Copy the root CA and subordinate CA certificates in PEM format. If they are in DER format, use the following commands to convert them to PEM format, and then copy them over to the /etc/openldap/cacerts directory.

# openssl x509 -inform DER -outform PEM -in rootca.der -out
rootca.pem
# openssl x509 -inform DER -outform PEM -in subca.der -out
subca.pem
Note: If the root CA certificate does not begin with ...BEGIN TRUSTED CERTIFICATE, the openssl commands might fail on both the certificates or the LDAP library might not use the certificate. In such a case, you need to modify the "trust" properties of the root CA certificate using the following command:

# openssl x509 -trustout -in rootca.cer -out rootca.pem

b. As root, copy the PEM-formatted certificate files to the/etc/openldap/cacerts directory and change their permissions:

# cp rootca.pem /etc/openldap/cacerts
# cp subca.pem /etc/openldap/cacerts
# chmod 644 /etc/openldap/cacerts/*.pem
-------------------------------------------------------------------------

No where did I see a DER formated file for the root CA or subordinate CA certificates. On the server I saw a cacert.pem locate in /CA directory and in /var/ldap directory were cert8.db, key3.db and secmod.db files. I am not sure which certificate files to use. I tried the cacert.pem file but get the error message above. I believe if I get this problem solved, it will fix the other problems. I have followed the instructions from the website above and do not know what else to do. Has anyone ever been successful at authenticating a RHEL 5.1 Openldap client with Sun DSEE 6.2 server? I need some help.

I found out why DSEE server kept asking to change my password each time I kept trying to login. The Linux Openldap client was seeing the password as being expired from the shadowLastChange attribute. So what I did was use the ldapmodify command to modify the shadowLastChange attribute to a more current date. Then I tried to ssh with my account and it worked.

ldapmodify -x -ZZ -H ldap://ldap1.server.com -D "cn=ldapmgr" -w <manager passwd>
dn: uid=username,ou=people,dc=server,dc=com
changetype: modify
replace: shadowLastChange
shadowLastChange: <new value>
<ctrl d>
<ctrl d>

My account worked just fine before I even change the shadowLast Change on the Solaris client. I was informed,

"The reason is DSEE 6.2 and Solaris 10 does not need to use the shadowLastChange, Waring, Max, and Min any longer. It is provided through the global password policies located inside the DSEE server. In order to have a solaris sytem recognize a password expiration, you must deny access for the proxyagent to read the password attribute of the user's in ou=people. This forces Solaris to utilize PAM to honor the built in global password policies.

Changing your global password policy creates a snowball effect that leads you to have to change the encryption method to the passwords from the default SSHA and force you to change the passwords for all existing users."

Would anyone be able to help configure Linux PAM to look at the global password policies on the DSEE server work the same as Solaris client with the DSEE?

I discovered the real reason for why, when running authconfig, one might receive one or more "Expecting: TRUSTED CERTIFICATE" errors. If you've configured the linux box to use LDAP at all, authconfig will automatically "rehash" the certificate directory. (Check the ldap.conf file for TLS_CERT* lines). During the "rehash" operation, for every file in the certificate directory that is not a valid PEM certificate file, you will get that warning/error printed out.

So, in reality, this is not actually an error for authconfig, but it appears to be, and it's damned alarming.

Solution: remove all non-certificate files from that directory.

I had placed a host key file that I was allowing the LDAP user to read in my cacert directory, and then began receiving the error. Renaming that file to start with a '.' eliminated the error from occurring.