[dsoumis]

No description provided.

[fabian-hahn]

Shouldn't certificateSelectByKeyUsage="true" be the default behavior?

[ChristopherSchultz]

Shouldn't certificateSelectByKeyUsage="true" be the default behavior?

No: we do not want to change the default behavior at the moment. We may change the default behavior in Tomcat 12 but we do not want to change it in older versions.

[ChristopherSchultz]

@dsoumis I think maybe this would be better if it were:

1. Always ignoring incompatible key usages
2. Only failing after all certificates matching aliases (from a PEM file, where alias == DN) fail

[markt-asf]

I'd be happy ignoring any certificate we know (e.g. because of key usage) we can't use. Other than that, I'm not sure any changes are required here.

[christophvw]

Can you check for outdated certificates as well here? Perhaps choose the one with the longest remaining validity, or at least avoid any that have expired

[ChristopherSchultz]

Can you check for outdated certificates as well here? Perhaps choose the one with the longest remaining validity, or at least avoid any that have expired

I think we should not skip expired certificates unless there is an equivalent one with the same DN. We should not be preventing the server from starting if there is only an expired certificate to serve. It's the client's responsibility to decide whether or not to trust an expired certificate.

[dsoumis]

2. Only failing after all certificates matching aliases (from a PEM file, where alias == DN) fail

@ChristopherSchultz I have some second thoughts on the above before committing an implementation.

Considering the following example:

Keystore with entries:

1. app.example.com CN=app.example.com serverAuth | key not readable
2. app.example.com (1) CN=app.example.com serverAuth | key readable

Both are valid candidates, the first is tried, it fails, so selection falls through to the second entry and TLS stays up.

However, the above may mask a misconfiguration from my point of view. It keeps a client up on a possibly soon-to-expire cert instead of failing loudly so the client can fix the key.

[dsoumis]

Can you check for outdated certificates as well here? Perhaps choose the one with the longest remaining validity, or at least avoid any that have expired

I also don't think we should skip expired certs.
Client may use https://tomcat.apache.org/tomcat-11.0-doc/api/org/apache/catalina/security/TLSCertificateReloadListener.html to monitor the expiration dates of TLS certificates and trigger automatic reloading of the TLS configuration.

[christophvw]

Can you check for outdated certificates as well here? Perhaps choose the one with the longest remaining validity, or at least avoid any that have expired

I think we should not skip expired certificates unless there is an equivalent one with the same DN. We should not be preventing the server from starting if there is only an expired certificate to serve. It's the client's responsibility to decide whether or not to trust an expired certificate.

good point. But choosing the one with the longest remaining validity would be good. Certs skipped because of missing read permissions for the private key should be logged otherwise people will change the tomcat service to Local System again instead of setting proper key permissions.

[christophvw]

Client may use https://tomcat.apache.org/tomcat-11.0-doc/api/org/apache/catalina/security/TLSCertificateReloadListener.html to monitor the expiration dates of TLS certificates and trigger automatic reloading of the TLS configuration.

Oh, nice - didn't know that.
Looks like the https://tomcat.apache.org/tomcat-11.0-doc/ssl-howto.html should get an update how to use the windows keystore and this listener to fully automate certificate handling on windows.

[christophvw]

Java versions before 17.017 and 21.0.9 cannot open the Windows local computer keystore without elevated permissions.