<div dir="ltr"><div>Sean,</div><div><br></div><div dir="ltr">On Fri, Apr 14, 2023 at 9:18 PM Sean Mullan <<a href="mailto:sean.mullan@oracle.com">sean.mullan@oracle.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Not possible right now AFAICT, but I will keep it in mind as a candidate <br>
API change for the next MR, if and when that may occur.</blockquote><div><br></div><div>Thanks for your analysis, this was enlightening. Too bad our timing is off, but such is life :-)</div><div><br></div><div>I found the Compatibility risk description in the CSR a bit interesting:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There might be some applications that still use the deprecated SSLSession.getPeerCertificateChain() API. But they have had plenty of advance warning to switch to use the equivalent SSLSession.getPeerCertificates() API that use the java.security.cert APIs instead.</blockquote><div><br></div><div>Any existing application calling SSLSession.getPeerCertificateChain() will do so on some existing implementation which already overrides this method. So these applications should not observe a behavioural  change.<br></div><div><br></div><div>The only behavioural change I see that could surprise anyone is the set of applications which today fails to compile because they don't override getPeerCertificateChain. These applications may be surprised that their source code suddenly compiles.</div><div><br></div><div>But compatibility is a tricky topic, so I assume I'm missing some subtlety here.</div><div><br></div><div>Eirik :-)</div><div><br></div><div> </div><div><br></div></div></div>