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. Robert On Wed, Dec 9, 2020 at 9:22 PM Robert Turner <rtur...@e-djuster.ca> wrote: > Thanks Chris for replying. > > I'm pretty sure I'm using the APR connector. Without double-checking how > things are configured... the startup logs show: > > 09-Dec-2020 21:05:25.689 INFO [main] > org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache > Tomcat Native library [1.2.24] using APR version [1.7.0]. > 09-Dec-2020 21:05:25.689 INFO [main] > org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR > capabilities: IPv6 [true], sendfile [true], accept filters [false], random > [true]. > 09-Dec-2020 21:05:25.689 INFO [main] > org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL > configuration: useAprConnector [false], useOpenSSL [true] > 09-Dec-2020 21:05:25.704 INFO [main] > org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL > successfully initialized [OpenSSL 1.1.1g 21 Apr 2020] > > On your ECC/RSA separately question: yes, each one works fine by itself. > > I'm not sure what testssl.sh does specifically to verify the chains for > each certificate. I haven't dug into its source yet, but it reports that > the chain for my RSA certificate has the wrong intermediate (and shows the > intermediate for the ECC certificate). So, with minimal examination, to me > it suggests that Tomcat/OpenSSL is not exposing the correct intermediate > certificate when presenting the RSA certificate chain for validation by the > client. > > > I may be able to request the re-issue, but I'm running with fairly > inexpensive certificates, so it might be a bit more of a challenge to get > done, but I could try -- that was going to be my "last resort" approach. > > I'm not clear on it either -- I'm not sure it's a requirement per say from > what I can tell, but maybe just a limitation of the implementation. But I > haven't done enough research (yet) into how TLS negotiation works, or the > implementation of OpenSSL to offer a non-speculative conclusion. I was > sort-of hoping to avoid a 2 or 3 day diversion to learn enough about it all. > > I had been planning on trying the combined certificates in single files to > see if it worked (As it was the only idea that I had based on looking at > the code and how it "saved" the certificates for use), and just kicked it > off the changes while typing this up. (time to check the results) > > With the combined certificates (in order) in the main certificate file, > both certificates now get reported by testssl.sh as: > Chain of trust NOT ok (chain incomplete) > > And when I connect using "openssl s_client -connect <host>:<port>", I see > only the initial certificate in the server response, where normally I would > see the chain listed out up to the root CA. > > So unfortunately, it looks like that doesn't quite work properly either. > > Robert > > On Wed, Dec 9, 2020 at 8:38 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> Robert, >> >> On 12/9/20 17:54, Robert Turner wrote: >> > I am trying to configure Tomcat 9.0.37 (or later if I need to) to use >> both >> > an RSA and an ECC certificate for the same host. >> > >> > Platform is Windows 2008 R2, with the Tomcat Native 1.2.24 library >> > installed. >> >> Do you know if you are using the APR connector or the NIO(2) connector? >> >> > My configuration is roughly as follows: >> > >> > >> > <SSLHostConfig protocols="TLSv1.3,TLSv1.2" >> > honorCipherOrder="true" >> > ciphers="<omitted for simplicity>" >> > hostName="*.blahblah.com"> >> > <Certificate >> certificateKeyFile="conf/blahblah_com_priv.key" >> > certificateFile="conf/blahblah_com.crt" >> > >> > certificateChainFile="conf/blahblah_com.intermediate.crt" >> > type="RSA" >> > /> >> > <Certificate >> > certificateKeyFile="conf/blahblah_com_com-ECC.private.key" >> > certificateFile="conf/blahblah_com-ECC.pem" >> > >> > certificateChainFile="conf/blahblah_com-ECC.intermediate.pem" >> > type="EC" >> > /> >> > </SSLHostConfig> >> > >> > >> > The only change I've made was to add the additional Certificate element >> for >> > the ECC certificate (so I believe everything else about our >> configuration >> > is all good. >> > >> > When I run "testssh.sh" against the host, I end up with a failed >> > certificate chain for the RSA certificate. The ECC certificate is all >> fine >> > though, and before adding the ECC certificate, the RSA certificate was >> fine. >> >> Hmm. So if you specify either RSA or EC alone, with the certificate >> chain, all is well (aside from the fact that you can only use one of the >> two certs)? >> >> What does testssh.sh do? >> >> > I've dug into the documentation and found this statement with reference >> to >> > the certificateChainFile parameter: >> > >> > "Note that when using more than one certificate for different types, >> they >> > all must use the same certificate chain" >> > >> > So I checked the Git repo, and that was added with a commit comment that >> > references the Apache HTTP configuration which states something slightly >> > differently: >> > >> > "But be careful: Providing the certificate chain works only if you are >> > using a single RSA or DSA based server certificate. If you are using a >> > coupled RSA+DSA certificate pair, this will work only if actually both >> > certificates use the same certificate chain. Else the browsers will be >> > confused in this situation." >> > >> > The two statements suggest slightly different things. However the second >> > doesn't suggest that ECC and RSA cannot be combined with different >> chains. >> > >> > Is there any way to have two different certificate chains for the ECC >> and >> > RSA certificates and get it working with Tomcat/OpenSSL? (as we don't >> have >> > certificates with the same chains as our provider seems to use different >> > intermediate CAs for ECC versus RSA). >> >> Yeah... it's possible for a CA to use a single cert to sign both EC and >> RSA keys, but yours appears to use different ones. Any chance you can >> request a re-issue of one of your certificates using the other type of >> signing certificate? You will almost certainly have to call and request >> this from your CA. >> >> I don't know why the two certs have to have the same chain when you use >> SSLCertificateChainFile. Oh, I think it's because there isn't a way to >> say in httpd which certificate which chain goes with, so there can be >> only one (effective) directive for that. >> >> What happens if you pack everything into (each of) your certificateFile >> and don't use certificateChainFile *at all*? >> >> -chris >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >>
