Support for LDAPS authentication

567 views
Skip to first unread message

Carl Reid

unread,
May 22, 2014, 6:39:44 AM5/22/14
to go...@googlegroups.com
Does GO support connecting to the LDAP server using the LDAPS protocol? There is no mention of this is the documentation: http://www.thoughtworks.com/products/docs/go/current/help/dev_authentication.html

I have tried entering the LDAPS url with the default port number but am receiving an error:

Cannot connect to ldap, please check the settings. Reason: simple bind failed: office.mycompany.co.uk:636; nested exception is javax.naming.CommunicationException: simple bind failed: office.mycompany.co.uk:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

I have tried adding the root and intermediary to the GO Server Keystore and restarting the service but the error remains.

Jyoti Singh

unread,
May 22, 2014, 7:24:43 AM5/22/14
to Carl Reid, go...@googlegroups.com
There are no known issues of Go not working with LDAP over SSL. I have seen it work in past once the ldap server certificates were imported to the java keystore. Importing it to Go server keystore should also work, just follow the instructions in this blog.

Cheers,
Jyoti


--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Kevin Wright

unread,
May 22, 2014, 7:26:21 AM5/22/14
to Carl Reid, go...@googlegroups.com
It's not the keystore you want, it's the truststore

use -Djavax.net.ssl.trustStore on the java command line in server.sh


--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com
vibe / skype: kev.lee.wright
steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra
Message has been deleted

Carl Reid

unread,
May 22, 2014, 7:40:32 AM5/22/14
to go...@googlegroups.com, Carl Reid
Thanks for the reply. Just to be clear we are using GO over HTTPS/SSL and have successfully imported a custom certificate to the keystore. 

This issue is changing the authentication to use LDAPS to prevent user's passwords being sent over plain text.

Thanks

carl
Message has been deleted

Kevin Wright

unread,
May 22, 2014, 11:09:21 AM5/22/14
to Carl Reid, go...@googlegroups.com
In my case, I missed that go already provided a truststore, so I forcibly overrode it by hacking the start script (server.sh) and supplying that param to java.exe
For windows, I would have hacked the last line of server.cmd instead.

However... This is overkill given that go already has a truststore.  It *should* be enough to just add your root certificate to the config\truststore file.


On 22 May 2014 12:32, Carl Reid <carland...@gmail.com> wrote:
As someone who is very unfammiliar with Java can you expand on that a little please Kevin?

Are you saying I should repeat the exercise importing the ROOT and Intermediary certificates using KeyTool but into the truststore file instead? There appears to be a file in the C:\Program Files (x86)\Go Server\config directory called Truststore so I assume this is it. Are the commands the same?

And do no I need to add a parameter to the GO wrapper-server.conf file to tell JAVA to use the truststore.


Where would this line go "-Djavax.net.ssl.trustStore" and should it contain the path to the truststore? An example would be great thanks.

Cheers for your help

carl

Carl Reid

unread,
May 22, 2014, 12:24:25 PM5/22/14
to go...@googlegroups.com
For anyone interested this IS POSSIBLE.

Thanks for the replies I received here which reassured me this was possible so I persevered!  

You need to ensure that you either use a certificate issued by a trusted certificate authority (trusted by JAVA!) or (if you are using your own certificate authority) add the certificate chain to the cacerts store in the Java runtime.

To do this:(on Windows)
  1. Download the DER encoded public certificate for all the certificates in your trust chain
  2. Login with an account that has local administrator access to the GO server
  3. Open a command prompt (as Administrator)
  4. Navigate to the JAVA runtime directory LIB\Security folder on Windows this is C:\Program Files (x86)\Go Server\jre\lib\security
  5. Run the import command using
    KeyTool.exe: ..\..\bin\keytool.exe -import -trustcacerts -alias  <your cert alias name> -file <your cert filename> -keystore cacerts

  6. Stop the go service 'net stop "Go Server"'
  7. Start the go service 'net start "Go Server"'
  8. Go to the Server Configuration section in the Admin controls and change the LDAP settings URL to ensure you are using LDAPS:// and a port number of 636. e.g. l
  9. Click the Check LDAP button which should show a green tick
     
    That's it!

    Ken Mugrage

    unread,
    May 22, 2014, 12:27:39 PM5/22/14
    to Carl Reid, go...@googlegroups.com

    That's awesome, thanks for persevering! 

    Any chance you want to turn this into a blog post? You (or anyone, hint ;) ) can fork https://github.com/gocd/gocd.github.io, follow the format in the _posts directory and submit a pull request to update go.cd

    Thanks again,
    Ken


    --
    You received this message because you are subscribed to the Google Groups "go-cd" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.



    --

    Ken Mugrage - ThoughtWorks Studios
    kmug...@thoughtworks.comhttp://www.thoughtworks.com | Twitter: @kmugrage
    Go, the Continuous Delivery platform is now open source! http://www.go.cd/

    Carl Reid

    unread,
    May 22, 2014, 12:37:57 PM5/22/14
    to go...@googlegroups.com, Carl Reid
    I could have a go! However I wonder whether this is something that would be better part of the existing documentation ?

    I always feel blog posts are (or should be) supplementary material for advanced scenarios or where a narrative is needed whereas this use-case (secure transport for authentication credentials) is IMHO a basic one that EVERYONE should be doing. I looked in the LDAP documentation for how to do it (http://www.thoughtworks.com/products/docs/go/current/help/dev_authentication.html) found nothing and can here.

    How is the documentation being updated, is that also on GitHib? I see it is currently on the Thoughtworks website (and part of the the installed server) and therefore it is not clear how this might be updated.

    Whilst we are on the subject I think a post on how to use a genuine SSL certificate would be useful on the GO.CD page. There is an article here but how would anyone ever know how to find that?

    Cheers

    Carl

    Kevin Wright

    unread,
    May 22, 2014, 12:47:11 PM5/22/14
    to Carl Reid, go...@googlegroups.com
    Note that this only works on Windows.

    Under Linux (and OSX I suspect) you'll be using an external Java Runtime, which means you need to update in your central installation of jre/lib/security
    This requires root access and will make the certificate available to ALL other java apps run on the same machine

    If you don't have root, or don't want to do that, then you'll have to fall back to using the javax.net.ssl.trustStore property

    Carl Reid

    unread,
    May 22, 2014, 1:00:09 PM5/22/14
    to go...@googlegroups.com, Carl Reid
    Yes to make this clear we only use Windows and since we do not use any other JAVA applications on these machines we use the JRE that ships with GO.

    GO does allow you to choose an existing JRE when installing on Windows so if you have other JAVA applications installed then you can still do this.

    These steps would be the same apart from the location of the JRE.

    Personally I do not think having other applications trusting these certificates would be an issue. The certificates I have imported are already in the Windows trusted ROOT and INTERMEDIARY certificate stores for all our servers and workstations since they are part of our existing trust chain.

    I suspect this is common for people who have their own PKI setup.

    Carl

    Ken Mugrage

    unread,
    May 22, 2014, 1:21:15 PM5/22/14
    to Carl Reid, go...@googlegroups.com
    On Thu, May 22, 2014 at 9:37 AM, Carl Reid <carland...@gmail.com> wrote:
    I could have a go! However I wonder whether this is something that would be better part of the existing documentation ?

    That may well be true. The existing help file for that functionality is at https://github.com/gocd/gocd/blob/master/helper/topics/dev_authentication.xml

    I should say there is a fairly intense desire to refactor the entire help system. Detailed discussion of those potential changes are probably better in a new thread on go-c...@googlegroups.com. I know some UX work and exploration into other frameworks has already been done. 

    Whilst we are on the subject I think a post on how to use a genuine SSL certificate would be useful on the GO.CD page. There is an article here but how would anyone ever know how to find that?

    Good point. I'll ask Sachin about sharing that post.

    Thanks,
    Ken

    Md. Ali Ejaz

    unread,
    May 22, 2014, 4:00:20 PM5/22/14
    to Ken Mugrage, Carl Reid, go...@googlegroups.com
    Just as an FYI, we are working on making user documentation available on github alongside the present developer documentation. The plan is to serve it as a gitbook to make it easier to read, search in the doc, etc.


    --
    Reply all
    Reply to author
    Forward
    0 new messages