Stuff I'm Up To

Technical Ramblings

Java Keystore Management — November 14, 2017

Java Keystore Management

keystore20explorer_256x256In the process of getting a new queue management system installed I discovered they’re using HTTP and not HTTPS. As part of out security process I had to recommend they change this to a HTTPS/SSL encrypted portal as it uses a logon process that would otherwise be in clear text.

The product is based on Wildfly and Java so they are progressing the deployment use Java keystores (JKS) and certificates. But as they pointed me to their installation guide I discovered they recommend the use of Keystore Explorer for managing the Java certificates.

So I downloaded it and have to say I’m impressed. It makes life so much easier when trying to manage certificates from Windows CA’s, OpenSSL and JKS. Definitely a valuable addition to my tool box. As it’s written in Java it’s available for Windows, Linux and fruit based systems.

Link: http://keystore-explorer.org/

Advertisements
Git – Version Control — October 13, 2017

Git – Version Control

We have a distinct lack of version control in the relatively small development team that manages one of our business applications. One of the main challenges isn’t really related to the developers, but to the vendor that connects remotely and “fixes” things without leaving any clue as to what has been changed.

So I came up with a sneaky plan to deploy Git onto the servers and manage the versions of configuration files used by the application. I can then capture any changes and roll back as necessary.

Continue reading

Tomcat log4j Errors — October 12, 2017

Tomcat log4j Errors

As I’ve been spending a lot of time with Tomcat these days I’ve tried to clear out the stderr log of error messages. One of the frustrating warnings I had to deal with was this:

log4j:WARN Continuable parsing error 208 and column 23
log4j:WARN The content of element type "log4j:configuration" must match "(renderer*,throwableRenderer?,appender*,plugin*,(category|logger)*,root?,(categoryFactory|loggerFactory)?)".

The log4j.xml file parsed correctly and was obviously working as we were seeing log output. But this error had me baffled for a while. I checked the syntax of the xml file, ensured it was sound structurally and couldn’t for the life of me spot the problem.

Turns out the order of the elements in the file is important and must match the order of the string listed above. We’d got some logger elements after the root element. A move of the root element below the logger elements and the error message went away.

 

Rant by a Complete Java Noob — February 1, 2017

Rant by a Complete Java Noob

I confess, I’m a complete Java noob. In fact slightly worse than that, I’m a Java hater. In principle it’s a great idea, cross platform and all that jazz, but in execution it leaves me frustrated. Seems most vendors I encounter may use Java, but use libraries specific to Windows making it as mobile as Jabba the Hutt. Also vendor installations that require Java seem to only be able to support last years version of Java, not the newest stable, and therefore it has so many vulnerabilities it makes it impossible to pass any kind of security audit.

This month I’ve been trying to buckle down and get stuck in to understand things more. Try to figure out how all of this is strung together and see if anything can be done to satisfy the needs of the application and security.

Continue reading

Tomcat and HTTPS — January 31, 2017

Tomcat and HTTPS

By default Tomcat gets installed with HTTP only and a number of default applications. Previously I linked documents on how to secure Tomcat. But put simply just delete the folders under webapps that you don’t need for your application. So you pretty much get left with host-manager and manager in there.

My next step was to try to figure out how to get the connection changed from HTTP to HTTPS and apply a valid certificate to the connection.

Continue reading

Securing Tomcat —

Securing Tomcat

Following a penetration test a large security weakness was exploited that allowed an attacker to gain local admin rights on a server running Tomcat. This in turn allowed the capture of session passwords from memory which in turn resulted in domain admin level access.

All because of a 3rd party application installed by a vendor who left the underlying Tomcat installation as a vanilla box product with all the softwares default settings.

Lesson: NEVER trust a vendor installation to be secure. Carry out a vulnerability scan whilst they’re still onsite and don’t sign off any installation until all security concerns have been resolved.

References:

http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html

https://www.owasp.org/index.php/Securing_tomcat

https://tomcat.apache.org/tomcat-8.0-doc/security-howto.html

https://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html

https://www.upguard.com/articles/15-ways-to-secure-apache-tomcat-8

Java SSL/TLS Ciphers — January 30, 2017

Java SSL/TLS Ciphers

You can specify what cipher suites Java uses by editing the file:

%JAVA_HOME%\lib\security\java.security

This file must also be used by the Java application. So if the application overrides this by using a -Djava.security.properties=<URL> setting then you should modify the file specified by <URL>.

The ciphers to disable are listed in the following keys:

jdk.certpath.disabledAlgorithms

jdk.tls.disabledAlgorithms

The file is documented, so you should be able to figure out the required settings from the examples.

The jdk.tls.disabledAlgorithms property in the policy file controls TLS cipher selection. The jdk.certpath.disabledAlgorithms controls the algorithms you will come across in SSL certificates.

Oracle has more information about this here.

Continue reading

Java Certificates —

Java Certificates

Certificates are the bane of my existence! After applying some updated certificates to Windows servers some of the systems are now failing to connect to database servers. This is due to the underlying Java program not knowing about the Windows certificate stores and using their own.

Now if life weren’t difficult enough the default keystores used by Java reside in their %JAVA_HOME%\lib\security folder, but we’ve got applications that have many flavours of Java installed. ie. java_jre_32bit, java_jre_64bit, java_jdk_32bit and java_jdk_64bit. I know, I didn’t install it like this, it’s a vendor install and they insist on it being this way and it must remain as a very specific version of Java.

So now we have to add the CA certificate into he cacerts file, which is where Java keeps its CA certs. So I’ve had to do this for each flavour of Java by using:

c:\> %JAVA_HOME%\bin\keytool -v -import -alias MyCA -file MyCA.pem -keystore %JAVA_HOME%\lib\security\cacert

Where MyCA is the name of the certificate and the .pem is a .cer file you must export from your CA’s mmc computer certificate snap in (management console).

Keytool will ask you for a password. What could it be? Well after a major trawl of the internet I found the default Java cacert password is ‘changeit‘.

I’m sure you can change it to whatever you’d like, but then you’re going to have to ensure that you update your Java configs to give it the new password. Which for me could be problematic as the vendors configs could be anywhere!

References: https://www.sslshopper.com/article-most-common-java-keytool-keystore-commands.html