Allow using custom SSL certificates

[HoussemNasri]

Fixes #8126.

Context

When a browser or server attempts to connect to a website (i.e., a web server) secured with SSL, the browser requests that the web server identifies itself by sending a copy of its SSL certificate in response then it checks to see whether it trusts the SSL certificate. If it does, it signals this to the webserver and starts an SSL encrypted session; if it doesn't the connection fails. The Java HTTP client uses a similar method.

So, how does Java trust certificates?
The JVM stores a list of trusted certificates in a truststore. Normally Java uses a system-wide truststore:

• Java 8: $JAVA_HOME/jre/lib/security/cacerts
• Java 11: $JAVA_HOME/lib/security/cacerts

However it is possible to use a different truststore by specifying a parameter, -Djavax.net.ssl.trustStore=/path/to/truststore, where /path/to/truststore is the absolute file path of the alternative truststore.

When connecting to a server over HTTPS, the Java client looks up the associated certificate in our truststore. If the certificate or Certificate Authorities presented by the external server is not in our truststore, we'll get an SSLHandshakeException and the connection won't be set up successfully.

Problem Description

Using an SSL proxy, the Java client requests a certificate from a server through the SSL proxy, which intercepts the request and provides its own SSL certificate, which may or may not be available in our truststore

Solution

The solution is to copy the original JDK truststore into the project and edit it, such as adding or removing certificates based on user interactions. It also involves persisting user-created certificates for the UI.

UI Changes

I added a new section to network preferences for SSL configurations, this section contains a table of user-added certificates, with basic information about each certificate, such as serial number, version, validation dates and more.

Screenshots

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[HoussemNasri]

I tried putting the truststore file in resources, but it doesn't seem to work; the certificates don't seem to persist. I think I should put it in application data, but I'm not sure how to do that across operating systems.

[Siedlerchr]

For the app data dir thing, checkout the PdfIndexer class, we use an external library which uses an external library that provides OS independent path to app data

[Siedlerchr]

Alternative idea: Ask the user to store the file somewhere

[HoussemNasri]

We can add another setting to SSL configuration to choose the truststore path; I'll think about it later once I've set up SSL configuration preference storing logic; then it'll be a simple task.

[Siedlerchr]

This definitely needs to be checked at runime in a jpackage build.

[Siedlerchr]

Codewise lgtm! Needs to be tested when run from jpackage to be sure that all resources paths can be accessed.
Can you test it with ./gradlew jpackage ?
That should generate the binaries under build/distribution

[HoussemNasri]

I tested the installer and portable versions on windows, and they both work.

[calixtus]

Please fixe the language test, so we can merge.

[Siedlerchr]

Thanks a lot for this cool feature!