ppkarwasz commented on issue #3074: URL: https://github.com/apache/logging-log4j2/issues/3074#issuecomment-2431885698
@MichaelMorrisEst, Thanks for the reminder, this issue was buried deep down on my TODO list. > The cert renewal has no impact on existing established connections (as the handshake is done when the connection is established) so there is no need for the key/trust store to be reloaded for existing connections to continue working. However, when an error occurs in writing to the socket a retry is attempted which includes the creation of a new socket and connection. Using a no longer valid cert here will prohibit the connection being re-established. If, during the retry, the key/truststore are reloaded, then the latest certs would always be used in re-establishing the connection and would effectively remove the need to trigger the reconfiguration. Could you explain more your use case? I looked at Tomcat's SSL implementation ([`SSLUtilBase`](https://github.com/apache/tomcat/blob/3f5b0cc58ce3c5cc7f74a9cbcfe083b303f222ff/java/org/apache/tomcat/util/net/SSLUtilBase.java#L265)) and some HTTP client libraries for Java and I couldn't find an example of the opportunistic keystore reloading behavior you are proposing. How do you deal with modification of the key/trust store in other Java components? Certificate expiration events are usually very rare, so I would assume that whenever such an event occurs: 1. The keystore and truststore are modified. 2. All the applications that use them are notified. IIRC UNIX for servers like NGINX you just need to send a `SIGUSR` signal. Since Java applications do not support that, they need to be restarted. Spring Boot did introduce an [SSL reloading mechanim](https://docs.spring.io/spring-boot/reference/features/ssl.html#features.ssl.reloading) in 3.1.0. Maybe your application needs to do the same? -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
