Not a problem -- that was my issue as well, I'm just not familiar with the code, and it can take a while to figure it out. In the meantime, we're testing with only ECC the certificate for now, but of course it would be nice to have both.
Thanks for looking into it. On Fri, Dec 11, 2020 at 12:56 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Robert, > > On 12/9/20 21:31, Robert Turner wrote: > > Actually, one incorrect statement in my previous response. testssl.sh > > didn't report the details of the certificate chain, only that it was > > broken. I used https://ssllabs.com/ssltest/analyze.html as well, and it > > reported the specific details of the certificate chain (and that the > chain > > was also broken). > > > > Sorry about that. > > No problem. > > Sad to see that the single-file didn't work, though Tomcat should have > known enough to link server cert + chain cert in the <Certificate> in a > way that httpd actually can't be configured to do. (In httpd, it appears > that single-file cert+chain ought to work, though I haven't tried it). > > I will have to look more deeply at how Tomcat constructs those chains. > Tomcat creates a Keystore in memory containing all those PEM > certificates and hands it off to to the Java ServerSocketFactory which > makes all the decisions about which certificates and chains it will > provide. > > But each certificate specifies its signer's identity and the signer's > certificate is available, so ... I don't see why there would be any > confusion in there. > > When you use OpenSSL (which you ARE using, though the APR connector is > disabled based upon the useAprConnector="false" you can see on startup), > the process is the same except that the certificate and key material are > extracted from the KeyStore as if it were specified in PEM files. So it > should (theoretically) all be the same. > > Something isn't quite right. > > This will probably take me a long while to figure out (because of my > lack of familiarity with the code and even what's expected to happen), > but others (ahem, Markt) can probably answer from memory and maybe even > get it patched quickly. > > So... apologies if this takes a while to investigate. > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
