Keystore Usage beyond the documentation

[Martha]

Hello,

I created a keystore file by following the command example from the documentation:

keytool -genkey -keystore /var/otp/keystore -alias OTPServerKey

I'm working on a Windows Server so the path was different, more like:

keytool -genkey -keystore C:\OTP\otp\keystore -alias OTPServerKey

After that, the documentation says "Once you have created a key, start up the OTP server and test that HTTPS access and authentication are possible." but I'm unable to access OTP via HTTPS in port 443 after I started up the server. I'm able to access the client web app via port 8080 without any issues. (Yes, I have port 443 open in my firewall and no other application is using this port)

I placed the keystore file in the same of the folder of the OTP jar file, which I also point to with the basePath tag. like this:

C:\Program Files\Java\jdk1.8.0_261\bin\java" -Xmx2G -jar C:\OTP\otp\otp-1.5.0-SNAPSHOT-shaded.jar --build C:\OTP\otp --inMemory --basePath C:\OTP\otp --securePort 443

I'm using IBI's OTP fork which I believe it originally forked OTP version 1.4.0

Any help will be appreciated. 

[Andrew Byrd]

Hello,

I was going through unresolved mailing list questions, and came back to this question about OTP1 SSL setup almost a year later. At the time I hadn’t used this aspect of OTP1 in a long time and didn’t have a response. I’m responding now to share some loosely related information that can simplify providing HTTPS in Java applications.

The approach used by most Java systems to supply encryption keys and certificates to web servers can seem rather complicated if you’ve used servers like nginx where you just drop the key and certificate files into the right directory with the right permissions, using common file formats. Especially when you're receiving short-lived automatically generated keys (like those from Let's Encrypt), it seems awkward to go through this whole dance of file conversion using special-purpose tools. 

I recently worked out a solution to this problem: it’s possible to programmatically create X509Certificate and PrivateKey instances from your certificate and key files, create a KeyStore instance and add the cert and key with the setKeyEntry method, then wrap that KeyStore in a KeyManager, and finally create an SSLContext for that KeyManager and supply it to your web server. I have seen this work in practice - you can just start up a TLS enabled server that reads your standard certificate and key files with no keytool manipulation at all. This was a proof of concept and has not been subject to any serious scrutiny, but if anyone is interested I can share the code.

Now, to briefly answer the original question for future reference: The approach described looks generally correct. It’s very difficult to diagnose something like this without seeing the log messages or how specifically the request fails, but reviewing the source code and documentation, a likely point of failure is probably the password on the keystore.

We can see here where OTP 1.5 initializes the SSL/TLS engine for its HTTPS listener:

https://github.com/opentripplanner/OpenTripPlanner/blob/v1.5.0/src/main/java/org/opentripplanner/standalone/GrizzlyServer.java#L77 

It will look for a file named keystore in the base directory. Note that as mentioned in the documentation it expects the keystore to have a password of “opentrip”.

It is of course odd to have a fixed password on the keystore, but this SSL setup and the authorization protecting the sensitive HTTPS endpoints (provided by the AuthFilter class) are just minimal working examples which were intended to be expanded upon and eventually subjected to a security review. The documentation states that the username and password are just placeholders and the system should be made configurable before the v1 release. In the end I don’t think any further work was done on protecting sensitive endpoints with HTTPS and auth. The decision was made to eliminate all such “dangerous” endpoints from OTP2 given the massive adoption of containerization and other changes in deployment operations in recent years. 

Hope this helps,

Andrew

--
You received this message because you are subscribed to the Google Groups "OpenTripPlanner Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opentripplanner...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opentripplanner-dev/e05ee821-1d4c-475b-a18d-97e8f7631c5an%40googlegroups.com.