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
>
>

Reply via email to