[GitHub] [solr-operator] thelabdude commented on issue #390: auto certificate renewal with restartOnTLSSecretUpdate and cert-manager fails

[GitBox <gi...@apache.org>]

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: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org