thelabdude commented on issue #390:
URL: https://github.com/apache/solr-operator/issues/390#issuecomment-1048259710
The fix for this is starting to feel more like it should go into `0.6.0` vs.
`0.5.1`.
My initial approach for this was to not set the `SOLR_SSL_TRUST_STORE` env
var unless the SolrCloud config explicitly declares it via:
`spec.solrTLS.trustStoreSecret`. I thought that would just let the JVM's
default truststore apply but Solr has this in `jetty-ssl.xml`:
```
<Set name="TrustStorePath"><Property name="solr.jetty.truststore"
default="./etc/solr-ssl.keystore.jks"/></Set>
```
So the Solr would start failing with:
```
Caused by: java.lang.IllegalStateException:
/opt/solr/server/./etc/solr-ssl.keystore.jks is not a valid keystore
at
org.eclipse.jetty.util.security.CertificateUtils.getKeyStore(CertificateUtils.java:50)
at
org.eclipse.jetty.util.ssl.SslContextFactory.loadTrustStore(SslContextFactory.java:1224)
at
org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:324)
at
org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:244)
```
So the current behavior of looking for a `truststore.p12` in the keystore
secret and using that if found or just using the `keystore.p12` if not seems
required with Solr having this default built into the jetty config. I didn't
love the idea of changing default behavior in a bug-fix release anyway, so I
think we just keep the current functionality.
So for now, I think the work-around Nik used (create your own truststore and
put into a secret) is the best solution until `0.6.0`.
In `0.6.0`, I do want to add an option to "merge" the JVM's built-in
truststore with a user-provided truststore using an `initContainer`, but that
would ideally require a new option in the CRD (something like
`mergeJavaTruststore: /usr/local/openjdk-11/lib/security/cacerts`) or more
hacky pull from a user-provided env var:
```
spec:
customSolrKubeOptions:
podOptions:
envVars:
- name: JAVA_TRUST_STORE
value: /usr/local/openjdk-11/lib/security/cacerts
```
For Nik's case, just using the Java default cacerts as the truststore for
Solr should fix his issue with Let's Encrypt's certs renewing as modern Java
(https://www.oracle.com/java/technologies/javase/8u141-relnotes.html) include
Let's Encrypt's root ca cert (see:
https://letsencrypt.org/docs/certificate-compatibility/). So in 0.6.0, my plan
is to support this merge option and if there's no explicit user-provided
truststore, Solr will just boot with the Java cacerts as the truststore.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
