grealish / pwm

Automatically exported from code.google.com/p/pwm
0 stars 0 forks source link

Error 5017 - problem to establish SSL connection to ldap server (eDirectory) #350

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Error 5017:  ERROR_DIRECTORY_UNAVAILABLE... unable to find valid certification 
path to requested target

Error text:
Directory unavailable. If this error occurs repeatedly please contact your 
helpdesk.{ 5017 ERROR_DIRECTORY_UNAVAILABLE (unable to create connection: 
unable to connect to any configured ldap url, last error: unable to bind to 
ldaps://sles-2.mydomain.de:636 as cn=admin,o=shk reason: CommunicationException 
(sles-2.mydomain.de:636; sun.security.validator.ValidatorException: PKIX path 
building failed: sun.security.provider.certpath.SunCertPathBuilderException: 
unable to find valid certification path to requested target)) }

My Environment:
Computer 1: name: sles-1, os: SLES v.11 SP2 32bit with Apache Tomcat 7.0.37, 
PWM v.1.6.4
Computer 2: name: sles-2, os: SLES v.11 SP2 64bit with OES v.11 SP1 64bit, 
iManager, eDirectory

On sles-1 tomcat is running and configured for using ssl. PWM is successfully 
installed on tomcat 7.0.37.
On sles-2 Novell OES v.11 is installed with eDirectory and iManager.
If PWM on sles-1 is configured in "LDAP Promiscuous SSL"-mode everything works 
fine. I can access eDirectory (running on sles-2) over PWM (running on sles-1) 
to change user accounts a.s.o.
If I change the PWM-configuration to use certificates, the error 5017 (above) 
occurs.

I have already made these steps:

1. Generate a new keystore and private key for tomcat (described in "Tomcat SSL 
Configuration how-to"):
keytool -genkey -alias tomcat -keyalg RSA

2. Create a certificate request file:
keytool -certreq -keyalg RSA -alias tomcat -file <csr-file>

3. Then singned the <csr-file> by CA in iManager on sles-2.

4. Export the self-signed-certificate of the CA (only public key, via iManager 
on sles-2).

5. Import the CA-self-signed-certificate in keystore on sles-1:
keytool -import -trustcacerts -alias root -file <trusted-root-ca-cert>

6. Import the sles-1-certificate signed by the trusted root ca
(see step 3):
keytool -import -alias tomcat -file <sles-1-cert-file>
Additional to these steps I've import the server certificate of the machine 
sles-2 (SSL DNS Certificate) in the keystore on sles-1 tomcat:

7. In iManager export the server certificate "SSL CertificateDNS" for the 
server sles-2 in Base64-format (only public key).

8. Import this server certificate in tomcat keystore on sles-1:
keytool -import -alias sles-2 -file <sles-2-cert-file>

But all these steps are not sufficient to establish a secure ldap-connection 
between pwm on sles-1 and ldap-server (eDirectory) on sles-2.

I've been careful to set the CN-values in all certificates to the right 
DNS-names of the machines.
I'm not sure what are the correct values of the attributes of the created 
certificates (i.e. in step 3, using iManager).
I set the follow values for the key usage: key type=SSL or TLS, key usage=key 
encipherment and digital signing, extended key type=server, extended key 
usage=server authentication.
I do not know if these values are relevant or not for my problem.

With "keytool -list" I can see that all certificates are correct store in the 
keystore-file and the keystore-file is at the right place in the filesystem on 
sles-1.

Nevertheless the error occurs. It seems to be that the certificate chain can 
not resolve by the tomcat server (pwm).
Has anyone an idea? I hope so! I tried so much of combinations of certificate 
types or certificate attributes and formates. But nothing helps!

Regards

Guenther

Original issue reported on code.google.com by tui-...@tenno.com on 28 Mar 2013 at 4:05

GoogleCodeExporter commented 9 years ago
Most likely cause is that your importing certificates to a different keystore 
from the one tomcat/pwm is using.  Make sure the keystore your importing to is 
the same keystore the jvm tomcat is running with.

Alternatively, you can use a one of the nightly pwm builds which has an 
auto-import ldap certificate feature.

Original comment by jrivard on 1 Apr 2013 at 4:44

GoogleCodeExporter commented 9 years ago
Issue 351 has been merged into this issue.

Original comment by jrivard on 2 Apr 2013 at 3:45

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Jrivard, many thanks for your fast answer.

I know the problem about placement of keystore in the filesystem.
I have create the .keystore-file in the roots home directory. Then I have 
copied this file
into the /opt/apache.../webapps directory because this location is configured 
in the
apache tomcat configuration file "server.xml" under the section "connector" for 
the
location of keystorefile in the filesystem.
Additionally I have copied the .keystore file to $JAVA_HOME/lib/security
(but I think, this ist not necessary in my case).

But the .keystore file on that three places do not help to solve the problem.

I have attached the content of my keystore file.
There you can see three entries (aliases): root, tomcat and sles-2.

Root is the CA's self-signed-certificate (importet with keytool and the
parameter -trustcacerts).

Tomcat ist the sles-1-certificate signed by the trusted root CA.
(There you can see the certificate chain with two certificates.)
On the machine sles-1 apache tomcat and pwm is installed and running.

Sles-2 is the machine with the eDirectory. The server certificate of sles-2
is also issued by the trusted root CA, but there I cannot see a certificate 
chain
like in tomcat-certificate. Is this correct? I dont know?!?!

You have written:
"Alternatively, you can use a one of the nightly pwm builds which has an 
auto-import ldap certificate feature."

I have already read this but I cannot find this build. Where can I get this new 
version of pwm?

Nevertheless I'm very interested to know, what's the solution of my problem.

Original comment by tui-...@tenno.com on 3 Apr 2013 at 8:48

Attachments:

GoogleCodeExporter commented 9 years ago
Sorry but I do not think this case and mine are the same.

I have a public certificate (Terena), and so according to the manual "
You use the certificate Issued by the Generally Recognized commercial 
certificate authority. The authority of this certificate Should Already be in 
the certificate database. If the LDAP server name in the URL is identical to 
the common name of the certificate, you're done. "

So I do not see how this information can help me. You can specify?

Original comment by uaberta...@gmail.com on 4 Apr 2013 at 3:38

GoogleCodeExporter commented 9 years ago
Sorry, these issues are between your ldap directory and the Java crypto engine. 
 PWM is not involved.  The errors may not be related, but are both generated by 
the Java crypto libraries, not PWM.  You can try asking for help on the 
pwm-general google group, or a Java/SSL related forum elsewhere.

As I mentioned, you can use PWM's certificate validator which is in the current 
builds (not in 1.6.4).  Click "daily builds" on the project home page to 
access.  This uses PWM custom libraries to import and validate ldaps 
certificates.

Original comment by jrivard on 5 Apr 2013 at 1:15

GoogleCodeExporter commented 9 years ago
Thanks for your answer.

Now I have installed the latest build of pwm. Then I imported the certificates
using the pwm menue - and all works fine! I'm happy!

But I can not understand why my fist attempt failed.

Where pwm does save the certificates imported by pwm's menue?

Best regards!

Original comment by tui-...@tenno.com on 15 Apr 2013 at 9:24

GoogleCodeExporter commented 9 years ago
The certs auto-imported by PWM are stored in the PwmConfiguration.xml.  There 
is a custom SSL Validator used to check those certs against the LDAP 
connection. 

If your curious, the format they are stored in the PWmConfiguration.xml is 
simply the standard base64 DER format.  You can copy and paste the base64 blob 
to a .der file and put the usual --BEGIN CERT HERE-- style lines before and 
after the blob and you can then use standard certificate manager tools 
(including keytool) to view them.

Original comment by jrivard on 15 Apr 2013 at 12:33