Task #3480
closed
Enable SSL on ldap-liferay.d4science.org
100%
Description
The service is still using non encrypted connections.
When all the services will have switched to the encrypted connection, the non ssl port will be closed.
Related issues
Updated by Andrea Dell'Amico about 9 years ago
- Description updated (diff)
@massimiliano.assante@isti.cnr.it let me know when we can make the configuration change. A ldap restart is needed. It's a matter of seconds if all goes well.
Updated by Andrea Dell'Amico about 9 years ago
- Blocked by Task #3481: Add ldap.d4science.org as CNAME of ldap-liferay.d4science.org added
Updated by Massimiliano Assante about 9 years ago
- Status changed from New to In Progress
I'm available to discuss about this. If I understand correctly we need to change the service endpoint configuration pointing to it.
In order to perform this change, each production portal service endpoint must be updated ( see
<Endpoint EntryName="LDAPServer">ldap://ldap-liferay.d4science.org</Endpoint>)
and each production portal must be restarted.
I should also check if the java method which connects to this ldap instance has no problem with SLL. Should we give this a try in ldap-liferay dev instance? Is that working on SSL yet?
Updated by Andrea Dell'Amico about 9 years ago
- Infrastructure Development added
- Yes, the development ldap server is under ssl already.
- I also added two aliases, because
ldap-liferayis now misleading: ldap-d.d4science.org is an alias for ldap-liferay-d.d4science.org and ldap.d4science.org is an alias for ldap-liferay.d4science.org. Note that the certificate for the dev instance does not covers the alias yet, I'll add it in some minutes. - If the java standard CA list contains the parent CA for the letsencrypt certificates it should have no problems. I only checked with non java clients though, and the Oracle JRE/JDK use their private CA certs list.
- I can activate the ssl endpoint and maintain the non ssl one until all the services will be switched.
Updated by Andrea Dell'Amico about 9 years ago
Andrea Dell'Amico wrote:
- I also added two aliases, because
ldap-liferayis now misleading: ldap-d.d4science.org is an alias for ldap-liferay-d.d4science.org and ldap.d4science.org is an alias for ldap-liferay.d4science.org. Note that the certificate for the dev instance does not covers the alias yet, I'll add it in some minutes.
I stand corrected. The automatic procedure correctly updated the certificate last night and correctly reloaded the openldap server. So you can already test against the dev ldap service using ldaps://ldap-d.d4science.org (the SSL port is the 636 one if you need to set it explicitly).
Updated by Massimiliano Assante about 9 years ago
tried in dev, have the following exception
javax.naming.CommunicationException: simple bind failed: ldap-d.d4science.org:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Invalid Server Certificate: server certificate could not be verified, and the CA certificate is missing from the certificate chain. raw error: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]
Updated by Andrea Dell'Amico about 9 years ago
The CA used by letsencrypt is not known to the JRE, but the problem lies here:
-Djavax.net.ssl.trustStore=/etc/ssl/cacerts_isti
We used a personalized trust store because the ISTI pop/imap servers use an invalid CA and the pop/imap sessions failed for that reason. There was a ticket about it in the old issue tracker.
I'm going to generate a new java keyring adding the CA chain used by letsencrypt. It will substitute the one currently used.
Updated by Massimiliano Assante about 9 years ago
- % Done changed from 0 to 50
now in dev.d4science.org it worked
2016-04-19 15:49:21,900 INFO ldapexport.LDAPSync [http-9090-1,<init>:52] %[PORTAL] 716481 [http-9090-1] INFO org.gcube.portal.ldapexport.LDAPSync - Starting LDAPSync over ldaps://ldap-d.d4science.org 2016-04-19 15:49:24,971 DEBUG ldapexport.LDAPSync [pool-11-thread-1,exportSingleUsers:216] %[PORTAL] 719552 [pool-11-thread-1] DEBUG org.gcube.portal.ldapexport.LDAPSync - LDAP Users Sync cycle done 2016-04-19 15:49:24,972 INFO ldapexport.LDAPSync [pool-11-thread-1,exportSingleUsers:218] %[PORTAL] 719553 [pool-11-thread-1] INFO org.gcube.portal.ldapexport.LDAPSync - LDAP Users Sync Completed OK!
Updated by Andrea Dell'Amico about 9 years ago
- % Done changed from 50 to 30
I'm installing the new keyring on all the portal hosts.
It should not be needed on any other servers with an up to date jdk.
Updated by Andrea Dell'Amico about 9 years ago
The new keyring has been installed on:
descramble.d4science.org egip.d4science.org i-marine.d4science.org preprod.d4science.org services.d4science.org infra-gateway.d4science.org dev.d4science.org dev2.d4science.org dev3.d4science.org
To actually use it, the following option needs to be passed to the java VM:
-Djavax.net.ssl.trustStore=/etc/ssl/cacerts_isti
Updated by Massimiliano Assante about 9 years ago
also on preprod.d4science.org please
Updated by Andrea Dell'Amico about 9 years ago
It's already there, it's listed together with the production hosts.
Updated by Andrea Dell'Amico about 9 years ago
- % Done changed from 30 to 90
The ldap server is now running with ssl enabled.
This redmine instance is already configured to bind on the ssl port.
Updated by Andrea Dell'Amico about 9 years ago
The sobigdata.eu drupal instance has started using ssl, FIY.
Updated by Massimiliano Assante about 9 years ago
- % Done changed from 90 to 100
LDAP configuration changed for production portal successfully, now contacting ldaps://ldap-liferay.d4science.org
Updated by Andrea Dell'Amico about 9 years ago
Thanks. I plan to close the plain text ldap port next Monday.
Updated by Andrea Dell'Amico almost 9 years ago
- Status changed from Feedback to Closed
