Java 8 and GoDaddy SSL certificates

I recently ran into an issue where I was trying to integrate two applications over SSL.

I was getting this error (which was covered in one of my earlier blog posts): PKIX path building failed: unable to find valid certification path to requested target

Essentially, GoDaddy is phasing on SHA-1 certs and moving to SHA-2 certs.  Check this out for further information:


In my case we were running Java 8 u60, so we had to import gd_bundle-g2-g1.crt into cacerts by running:

%JAVA_HOME%\jre\lib\security>keytool –import –alias gd_bundle-g2-g1 –file gd_bundle-g2-g1.crt –keystore cacerts -trustcacerts

And as you probably know, the password is changeit

Spring Security: Supporting Multiple LDAP Directory Services


The application I was working on authenticated against Active Directory (AD).  However, I wanted each developer to have the ability to run the full-fledged application on their own developer machine, and running AD on a developer machine isn’t ideal. Hence, problem #1.


Thankfully, there are free LDAP servers available.  Apache Directory Studio and Active Directory Lightweight Directory Services (AD LDS) are just a few.

Approach A:

We first tried Apache Directory Studio but the application would not recognize the username.  Finally we determined that AD accepts the sAMAccountName attribute as the username, while most other LDAP servers simply use uid.  So problem #2 became, how do we support both?

Approach B:

It turns out what I really needed to do was create an LDAP search filter.  And I found a great how-to on the Atlasssian website of all places.

So the spring security configuration went from:

<bean id=”userSearch”
<constructor-arg index=”0″ value=”” />
<constructor-arg index=”1″ value=”(sAMAccountName={0})” />
<constructor-arg index=”2″ ref=”contextSource” />

to this:

<bean id=”userSearch”
<constructor-arg index=”0″ value=”” />
<constructor-arg index=”1″ value=”(|(uid={0})(sAMAccountName={0}))” />
<constructor-arg index=”2″ ref=”contextSource” />

Another problem:

I wish I could say that solved everything.  Unfortunately, Apache Directory Studio became non-responsive on multiple developer machines after a restart.

We were unable to get it up and running again so we switched to AD LDS.  This proved to be a better fit for us because Apache Directory Studio was required to run in the foreground.  With AD LDS we could run it in the background.  However, one downside of AD LDS is that you require a client tool, like ADSI Edit to configure it.  Also, there was 1 gotcha.  You need to add your newly created users to the ‘Reader’ role.  You do that by adding them to the ‘member’ attribute of the Reader role.

Spring Security: Migrating from 3.x to 4.x

So I started out migrating the Spring components of my web application by updating Maven to pull the 4.x Spring releases.

I expected some changes with regards to Spring MVC, but I didn’t expect changes related to Spring Security.

The spring-security.xml started out as follows:

And the login.jsp had the standard fields and action:

<form name='loginForm' action="<c:url value='/j_spring_security_check' />" method='POST'>




<td><input type='text' name='j_username'></td>




<td><input type='password' name='j_password' /></td>



<td colspan='2'><input name="submit" type="submit" value="submit" /></td>




The problem started when I had the application entirely running on Spring 4.x and I tried logging in without success.

Nothing made sense.  I examined the logs which reported “Access is denied” and “anonymousUser”.  This seemed odd because the http posts seemed fine.

I tried modifying the spring-security.xml many times without success.  Then I tried to move the security configuration from xml to Java based.  Essentially, I introduced a SecurityConfig class (with @EnableWebSecurity annotation) but that didn’t work either.

Finally, I went back to the xml based configuration and added j_spring_security_check/j_username/j_password.  This solved the problem.  It still doesn’t make sense to my why I had to do that.

Here’s what the spring-security.xml ended up looking like:

<sec:http use-expressions=”true” auto-config=”true”>

<sec:csrf disabled=”true”></sec:csrf>

<sec:intercept-url pattern=”/css/*” access=”permitAll”/>

<sec:intercept-url pattern=”/images/*” access=”permitAll”/>

<sec:intercept-url pattern=”/jsp/login.jsp” access=”permitAll”/>

<sec:intercept-url pattern=”/**” access=”isAuthenticated()” />

<sec:form-login login-page=”/jsp/login.jsp” login-processing-url=”/j_spring_security_check” username-parameter=”j_username” password-parameter=”j_password” default-target-url=”/index.html” authentication-failure-url=”/jsp/login.jsp?login_error=1″ always-use-default-target=”true”/>

<sec:logout logout-url=”/j_spring_security_logout” invalidate-session=”true” logout-success-url=”/jsp/login.jsp?loggedout=true” />