On Tue, 20 May 2025 16:28:42 GMT, Daniel Jeliński <djelin...@openjdk.org> wrote:
>> If we use the same KeyStore and the same KeyManager then the certificate(s) >> will be the same most of the time but there is no guarantee of course: >> >> 1. We can have different constraints in `java.security` >> 2. Different `jdk.tls.server.SignatureSchemes` system property. >> >> As far as I can tell local certificates are not being used by TLS layer >> after the handshake but they can be requested by application layers above >> such as HTTPS. >> If having the same local certificate(s) for resuming the session is a >> requirement then I think we can add a few more bytes to the ticket as a >> certificate's fingerprint (`X509CertImpl.getFingerprint`) and then validate >> that fingerprint(s) against certificate(s) in the new possession. We then >> fall back to a full handshake if such validation fails. > >> As far as I can tell local certificates are not being used by TLS layer >> after the handshake but they can be requested by application layers above >> such as HTTPS. > > Right, that matches my observations. > >> If having the same local certificate(s) for resuming the session is a >> requirement then I think we can add a few more bytes to the ticket as a >> certificate's fingerprint (X509CertImpl.getFingerprint) and then validate >> that fingerprint(s) against certificate(s) in the new possession. We then >> fall back to a full handshake if such validation fails. > > I'm not aware of any uses of the local certificates / local principal on the > server side, but I'd err on the side of caution. The resumed session should > either return the same certificates, or return an obviously wrong value (like > null), so that users can detect unexpected values. > > Checking the fingerprint and falling back to a full handshake sounds > reasonable to me. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2098922120
