I spent some time trying to figure out how to fix the following error message on my new OpenSuSE 11.4 PC
error: 14090086 SSL Routines
SSL3_GET_SERVER_CERTIFICATE certificate verify failed (self signed certificate in certificate chain)
The fix was to let the LDAP Client know that it could trust the server cert I created when setting up the LDAP Server.
in other words, trust the Certificate Authority (CA) that created the server certs.
Like most people getting started my linux box is the certificate authority, it is the LDAP Server and it is the LDAP client.
So I created a CA Cert and a Server Cert using the options in YaST launched when setting up the LDAP Server
To fix the error, add the certificate for the CA to the list of trusted CA’s used by the client.
In YaST2 click on Network Services, LDAP Client, Advanced Configuration
You can do 1 of 2 things
Add /etc/ssl/certs to the Certificate Directory field or
Add /etc/ssl/certs/YaST-CA.pem to the CA Certificate File field
adding REQCert = never to /etc/ldap.conf and /etc/openldap/ldap.conf did not get the job done.
also tls_cacertdir /etc/ssl/certs
and tls_cacert /etc/ssl/certs/YaST-CA.pem
in the same 2 files did not get the job done either
therefore I think that /etc/ldap.conf and /etc/openldap/ldap.conf are not used by the YaST LDAP Client. Or there must be another file(s) containing client settings in addition to these 2.
To set up this trust, the clients must trust the root of the server’s certificate. This means, clients have to possess the certificate of the certification authority that issued the server certificate in their Trusted Root Certification Authorities store. You can observe this store via the Certificates snap-in.
The process is mandatory if you are using a certificate not issued by a third part vendor.
Important
To install the server root certificate, do the following on the client.
To install the root Certificate on the client
Open the Certificates snap-in console. If you have not previously added in the Certificates snap-in console, you can achieve this by doing the following:
• Click Start, select Run, type mmc, and then tap OK.
• On the File menu, choose Add/Remove Snap-in.
• In the Add or Remove Snap-ins dialog box, in the Available snap-ins file, choose Certificates, and then click Add.
• In the Certificates snap-in dialog box, select Computer account, and at that time click Next.
• In the Select Computer dialog box, click Local computer: (the computer this console is running on), followed by selecting Finish.
• In the Add or Remove snap-ins dialog box, click OK.
In the Certificates snap-in console, in the console tree, double click to show more items on Certificates (Local Computer), repeat previous step with Trusted Root Certification Authorities, right-click Certificates, and focus on All Tasks, followed by selecting Import.
Once you get to the Welcome to the Certificate Import Wizard page, select Next.
On the File to Import page, in the File name box, indicate the title of the server root certificate, then select Next.
On the Password page, if you created a pass phrase for the private key linked with the certificate previously, enter the pass phrase.
On the Certificates Store page, allow the default selection (Place all certificates in the following store – Trusted Root Certification Authorities), followed by choosing Next.
On the Completing the Certificate Import Wizard page, verify that the certificate settings appear as followed:
• Certificate Store Selected by User: Trusted Root Certification Authorities
• Content: Certificate
• File Name: FilePath<Root_Certificate_Name.cer>, where <Root_Certificate_Name> is the name of the server root certificate.
Select Finish.
Once the certificate upload has successfully concluded, a confirmation message will show up proving the import was successful. Select OK.
With Certificates chosen in the console hierarchy, in the detail panel, confirm that the root certificate of the server has become visible in the file of certificates on the client.
This process can be modified on client computers to use website certificates, remote desktop certificates, and Exchange certificates.
The initial post is in the wrong area. @ jke12345 , if you had looked where you were posting, you would have seen words in LARGE LETTERS at the top of the page asking one NOT to post in this area.
In 30 minutes to an hour, I am going to move this thread to network area . I need to wait that long so that this warning post gets out across the NNTP gateway. For web users I will leave a link to the new area for 1 week.
I ask that both web and NNTP users do NOT reply to this thread until AFTER it has been moved to ‘network area’. I will advise NNTP users when it has been moved. Look for a reply from me, to the original jke12345 post (and I will also reply to bkinc’s excellent response), in the ‘network’ NNTP area, after the thread has been moved.
This thread has been moved from being inappropriately in the HOW-TO/FAQ area to our NETWORK area. Both NNTP and WEB based users are now invited to reply to jke12345’s post. I have quoted the entire post so that NNTP users have a ‘hook’ in which to reply. I have also quoted bkinc’s post so that web based users can read that response.
Thankyou for your patience during the thread move.
your comment reminds me of a lot of the web sites I visit for banks and paying corporate taxes.
They put all this “STUFF” in the initial pages or at the top of their web pages that no one reads becauser there is all this “STUFF” at the top of their web pages all the time.
It’s easy to become immune to the “STUFF” after you visit the pages a few times.
Would be better to block posts to a forum instead of relying on people to read the “STUFF”.