TLS on Tomcat: Using ECC and RSA certificates together -- invalid intermediate certificate in chain

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

TLS on Tomcat: Using ECC and RSA certificates together -- invalid intermediate certificate in chain

Robert Turner
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.

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.

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


Thanks for any suggestions anyone can provide,

Robert
Reply | Threaded
Open this post in threaded view
|

Re: TLS on Tomcat: Using ECC and RSA certificates together -- invalid intermediate certificate in chain

Christopher Schultz-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: TLS on Tomcat: Using ECC and RSA certificates together -- invalid intermediate certificate in chain

Robert Turner
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 <
[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: TLS on Tomcat: Using ECC and RSA certificates together -- invalid intermediate certificate in chain

Robert Turner
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 <[hidden email]> 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 <
> [hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: TLS on Tomcat: Using ECC and RSA certificates together -- invalid intermediate certificate in chain

Christopher Schultz-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: TLS on Tomcat: Using ECC and RSA certificates together -- invalid intermediate certificate in chain

Robert Turner
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 <
[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>