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:
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