You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by John Palmer <jo...@gmail.com> on 2019/02/12 17:21:05 UTC

tomcat 8.5.37, Http11Nio2Protocol (OpenSSL), clientAuth or certificateVerification options

using the old Connector/clientAuth="true" or the new
Connector/SSLHostConfig/          certificateVerification="REQUIRED" (tried
lowercase and without the D) format..doesn't seem to work properly.

no matter what value I use or which format... the behavior seems to be that
the client cert is prompted for, but is optional.... (the web pages are
shown whether a cert is selected or Cancel is selected on the prompt.
(in the latter case, a JSP scriplet that shows X509 certificate content
throws an error, confirming that the client certifcate was not sent).

(Openssl s_client cmd confirms that the "Acceptable client certificate CA
names"
from the trustStore specified ARE being sent).

I don't doubt that I'm missing (mistyping or misunderstanding) something
(again), but I'm gonna ask for help a little sooner this time  rather than
continuing to beat a dead horse   :)     ...

thanks again..
John

Re: tomcat 8.5.37, Http11Nio2Protocol (OpenSSL), clientAuth or certificateVerification options

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

John,

On 2/12/19 12:21, John Palmer wrote:
> using the old Connector/clientAuth="true" or the new 
> Connector/SSLHostConfig/
> certificateVerification="REQUIRED" (tried lowercase and without the
> D) format..doesn't seem to work properly.
> 
> no matter what value I use or which format... the behavior seems to
> be that the client cert is prompted for, but is optional.... (the
> web pages are shown whether a cert is selected or Cancel is
> selected on the prompt. (in the latter case, a JSP scriplet that
> shows X509 certificate content throws an error, confirming that the
> client certifcate was not sent).
> 
> (Openssl s_client cmd confirms that the "Acceptable client
> certificate CA names" from the trustStore specified ARE being
> sent).
> 
> I don't doubt that I'm missing (mistyping or misunderstanding)
> something (again), but I'm gonna ask for help a little sooner this
> time  rather than continuing to beat a dead horse   :)     ...

Can you copy/paste your actual configuration?

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxjAhUACgkQHPApP6U8
pFiS8A//QFTFb+JC6n/QJ+KPZKZ5VYsNavfCZD5bkwoWByrO2KLoYQuzEyBMFHHr
qXZ/Ry1dtW2IYbxP29BopteKx/kdFBe554MoXiDUdKYJSZa3d4Bgq1qkRjRvZ7Xq
kago/cVz/ZmFK9xIYwz1mK1M4WfYCFA8BgIvyp9pQIGMzxCHSn8ull541XtFJrAz
VBH64+3WGhpFjv6vsAwC4MVZY9lwc/2wEXD6k5cnscyHHJQbH3fWwjmpQZgT0PXf
Q4g49YSTjBvvWu9QLE3Vq0QoqGmSnrCj8QjRVp4v5ot5JyxYXfjYY4/Gclu46x1a
IFy+K5hQ7YTNTzkKczT+UZGGCBfxiyW6NVC7tBkVx6t8WPJbIwD1/CUYzEmw6x7P
2IKuwCCkDyApzmU2QYzL7jDeEFuN98URQwhQz+mvRKdQGW5D9C58E8Ka8EEazxgF
dtstzkDeSNA9GEGJbk4H4e6+wiEjbCyBUj2zmxVYYYClA9oVa1888aEzDbSwJB15
eIwYnRal8RJ0hNt3ATh2lPV2NQHt168rf5Y3GMUPbO3kT7uKSjB7p/sJ8zWRxpMw
gL7JxqlGT3RN7wsAe4H84bucgJsIPj5IMoNYILFLMCpiZD9xrpK0d/QVtM2rd3B4
cNZ6cRGiF1hU/BS9Xq6ZVYMMA2G54BRFFEtkhERpLte+3aLPixw=
=fdPZ
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] tomcat 8.5.37, Http11Nio2Protocol (OpenSSL), clientAuth or certificateVerification options

Posted by Mark Thomas <ma...@apache.org>.
On 12/02/2019 22:26, Christopher Schultz wrote:
> Mark,
> 
> On 2/12/19 13:27, Mark Thomas wrote:
>> Try again. Prompted for certificate. Select valid cert. Connection
>> refused. Ah. the trust store again. Switch back to the OpenSSL
>> config.
> 
> This is a real point of confusion for users... the difference between
> configuring for OpenSSL versus JSSE (especially when using OpenSSL via
> JSSE).
> 
> Is there any technical reason why we can't accept either type of
> certificate for either type of connector? I can't think of a reason
> why we couldn't convert from one to the other if necessary.
> 
> Sure, it's a bunch of plumbing code that we have to babysit, but the
> configuration will be *so* much nicer, regardless of the user's
> preference (e.g. PEM-encoded DER files, just like $diety intended, or
> the hellspawn that is certificate keystores).

Some of that is already in place but there are gaps.

Likewise we have merged some of the configuration options but could
probably do more.

A good starting point would be a wiki page or similar that documented
the current state and then we could start to fill in the gaps.

Just thinking out loud, a nice way to test this would be with a single
set of key/cert files and multiple connectors on different ports that
each used a different combination. Testing would then be a case of start
Tomcat and check the homepage on a handful of different ports (which
could easily be made into a unit test).

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] tomcat 8.5.37, Http11Nio2Protocol (OpenSSL), clientAuth or certificateVerification options

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 2/12/19 13:27, Mark Thomas wrote:
> Try again. Prompted for certificate. Select valid cert. Connection 
> refused. Ah. the trust store again. Switch back to the OpenSSL
> config.

This is a real point of confusion for users... the difference between
configuring for OpenSSL versus JSSE (especially when using OpenSSL via
JSSE).

Is there any technical reason why we can't accept either type of
certificate for either type of connector? I can't think of a reason
why we couldn't convert from one to the other if necessary.

Sure, it's a bunch of plumbing code that we have to babysit, but the
configuration will be *so* much nicer, regardless of the user's
preference (e.g. PEM-encoded DER files, just like $diety intended, or
the hellspawn that is certificate keystores).

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxjSBgACgkQHPApP6U8
pFi4gA/+NjUUGQaEpE1XDrbE/mC47tZUhGQD1iZakwIgqtE159lAiK8ddZcDC073
xc2oWYRRKuqyzKQ/d7NowfU1FuZc/78dME/M0OJ0PQ/HFx1MKSx3qZnl6jWsIUV8
nayBPG4fKbJfDy7L+brUk/jdxTwE+5NRB2jdE4DcG5uqH4b2OQI2W3aZcNL3wqRW
LbvwyPtRVpm63G3ct8eB81kSlkRo/664bgQNzA+ZV1AiVu17cArKlHS7eyQJHf5A
Btn8WunosrG1haOGGjCM1yEN/aClbmrgoy3sWO6RK22SCgWFkP6CXKkYf5Q+E/4d
vfZWg25YwHQm7uPMEdBhDth9dIm9uZnoxDbzvmE3J7FIT30orJmb+MDLod1hAIYH
CWgJ4oF7uWgk5Q2/+EkF3tSy9OAF6fY3x/y24dH+NHDBWfj/2PXv90ohY/+IMeJQ
oYUuBwZd49BmdJiofw1IoRaDrtlJjw9aIFlszyS+bn87TSe2JozhMymmxhtPPb8C
T9KCMbQGpRkNFm1/PgKNKFi8SaqAdd+wl2f7h88qA8HJ5Xyjmn88VJfHjFdMUoAe
fgK1tcN1J4szSHO3ivCBMnqUeJPUgcWqJC8qh2likk77Mx+Qw3CMzfB0i4Ry7r1g
kg3T1/uRekmyaVTowb4vuVGwYP3p9BCBBFezSEKCGELa8RrQ3rI=
=m+qr
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: tomcat 8.5.37, Http11Nio2Protocol (OpenSSL), clientAuth or certificateVerification options

Posted by John Palmer <jo...@gmail.com>.
You're (both) quite right, my apologies.
(this is embarrassing)

In my defense, I've been bouncing back and forth between my personal
desktop machine (windows 10)
where I was having this issue...
and a development server, where this was working just fine.

While at lunch, it occurred to me to wonder if I had the same Tomcat and
TC-Native bits on each .. confirmed after lunch that these were different.
(tc-native 1.2.21 on the desktop, 1.2.19 on the server)
Changed those on my desktop to match those of the server, same issue...
compared the server.xml files and found that on the desktop, where I had
put back the older  (7.x) format Connector stuff and - (the mistake) - left
the clientAuth setting at "want" rather than "true".
corrected that, working as expected.

Went back to the OpenSSL Connector format and saw new errors...
(useServerCipherSuitesOrder="true" in the Connector section caused a
_default_hostConfig (something like that) error...PROBABLY because I had
moved the SSLProtocls  to theSSLHostConfig section.... moved the
useServerCipherSuitesOrder  attribute to the SSLHostConfig section and
renamed it to honorCipherOrder to fix that).
Also found I had to add the truststoreType and truststorePassword
attributes to the SSLHostConfig element.... (docs seem to say that's ONLY
for JSSE syntax - but I may be misunderstanding that),

long story short, I now have a Connector element that works correctly:
     <Connector
            port="443"
            protocol="org.apache.coyote.http11.Http11Nio2Protocol"
            maxThreads="150"
            SSLEnabled="true"
            scheme="https"
            secure="true"
        >
        <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"
/>
        <SSLHostConfig
            protocols="+TLSv1.2+TLSv1.3"
            honorCipherOrder="true"
            certificateVerification="required"
            truststoreFile="C:/certs/trustStore.pfx"
            truststoreType="PKCS12"
            truststorePassword="password"
            >
            <Certificate
                certificateKeystoreFile="C:/certs/servername.pfx"
                certificateKeystoreType="PKCS12"
                certificateKeystorePassword="password"
            />
        </SSLHostConfig>
    </Connector>


retested with tc-native 1.2.21 on the desktop...  and its working as
expected.
(Still not sure what was going on previously).

thanks, again.


On Tue, Feb 12, 2019 at 12:27 PM Mark Thomas <ma...@apache.org> wrote:

> On 12/02/2019 17:21, John Palmer wrote:
> > using the old Connector/clientAuth="true" or the new
> > Connector/SSLHostConfig/          certificateVerification="REQUIRED"
> (tried
> > lowercase and without the D) format..doesn't seem to work properly.
> >
> > no matter what value I use or which format... the behavior seems to be
> that
> > the client cert is prompted for, but is optional.... (the web pages are
> > shown whether a cert is selected or Cancel is selected on the prompt.
> > (in the latter case, a JSP scriplet that shows X509 certificate content
> > throws an error, confirming that the client certifcate was not sent).
> >
> > (Openssl s_client cmd confirms that the "Acceptable client certificate CA
> > names"
> > from the trustStore specified ARE being sent).
> >
> > I don't doubt that I'm missing (mistyping or misunderstanding) something
> > (again), but I'm gonna ask for help a little sooner this time  rather
> than
> > continuing to beat a dead horse   :)     ...
>
> Maybe. Or you might have hit a Tomcat bug.
>
> So, starting with a clean build of the latest 8.5.x source...
>
> Enable TLS (uncomment the second of the comment out TLS connectors in
> the default server.xml), switch it to NIO2 from APR/native and copy the
> key, cert, etc. into the correct locations.
>
> Starts with TLS enabled with NIO2 (JSSE) on 8443. Can connect with Chrome.
>
> Add certificateVerification="required" to the SSLHostConfig and restart.
>
> Starts with TLS enabled with NIO2 (JSSE) on 8443. Connection from Chrome
> rejected. Ah. No trust store configured on the connector.
>
> Add caCertificateFile="conf/ca-rsa-cert.pem" to SSLHostConfig and restart.
>
> Starts with TLS enabled with NIO2 (JSSE) on 8443. Connection from Chrome
> rejected. Realised I tried to use OpenSSL config and I'm using JSSE.
> Removed caCertificateFile="conf/ca-rsa-cert.pem" and added
> truststoreFile="conf/ca-rsa.jks" to SSLHostConfig.
>
> Starts with TLS enabled with NIO2 on 8443. Connection from Chrome
> prompts for client cert. Click cancel - connection rejected. As
> expected. Try again, this time selecting a certificate - connection
> allowed.
>
> All working as expected.
>
> Add Tomcat Native (so OpenSSL is usedd for TLS).
>
> Tomcat starts with NIO2 (OpenSSL) on port 8443.
>
> Prompted for user certificate. Click cancel. Connection refused.
>
> Try again. Prompted for certificate. Select valid cert. Connection
> refused. Ah. the trust store again. Switch back to the OpenSSL config.
>
> Tomcat starts with NIO2 (OpenSSL) on port 8443.
>
> Prompted for user certificate. Click cancel. Connection refused.
>
> Try again. Prompted for certificate. Select valid cert. Connection allowed.
>
> All seems to be working as expected here.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: tomcat 8.5.37, Http11Nio2Protocol (OpenSSL), clientAuth or certificateVerification options

Posted by Mark Thomas <ma...@apache.org>.
On 12/02/2019 17:21, John Palmer wrote:
> using the old Connector/clientAuth="true" or the new
> Connector/SSLHostConfig/          certificateVerification="REQUIRED" (tried
> lowercase and without the D) format..doesn't seem to work properly.
> 
> no matter what value I use or which format... the behavior seems to be that
> the client cert is prompted for, but is optional.... (the web pages are
> shown whether a cert is selected or Cancel is selected on the prompt.
> (in the latter case, a JSP scriplet that shows X509 certificate content
> throws an error, confirming that the client certifcate was not sent).
> 
> (Openssl s_client cmd confirms that the "Acceptable client certificate CA
> names"
> from the trustStore specified ARE being sent).
> 
> I don't doubt that I'm missing (mistyping or misunderstanding) something
> (again), but I'm gonna ask for help a little sooner this time  rather than
> continuing to beat a dead horse   :)     ...

Maybe. Or you might have hit a Tomcat bug.

So, starting with a clean build of the latest 8.5.x source...

Enable TLS (uncomment the second of the comment out TLS connectors in
the default server.xml), switch it to NIO2 from APR/native and copy the
key, cert, etc. into the correct locations.

Starts with TLS enabled with NIO2 (JSSE) on 8443. Can connect with Chrome.

Add certificateVerification="required" to the SSLHostConfig and restart.

Starts with TLS enabled with NIO2 (JSSE) on 8443. Connection from Chrome
rejected. Ah. No trust store configured on the connector.

Add caCertificateFile="conf/ca-rsa-cert.pem" to SSLHostConfig and restart.

Starts with TLS enabled with NIO2 (JSSE) on 8443. Connection from Chrome
rejected. Realised I tried to use OpenSSL config and I'm using JSSE.
Removed caCertificateFile="conf/ca-rsa-cert.pem" and added
truststoreFile="conf/ca-rsa.jks" to SSLHostConfig.

Starts with TLS enabled with NIO2 on 8443. Connection from Chrome
prompts for client cert. Click cancel - connection rejected. As
expected. Try again, this time selecting a certificate - connection allowed.

All working as expected.

Add Tomcat Native (so OpenSSL is usedd for TLS).

Tomcat starts with NIO2 (OpenSSL) on port 8443.

Prompted for user certificate. Click cancel. Connection refused.

Try again. Prompted for certificate. Select valid cert. Connection
refused. Ah. the trust store again. Switch back to the OpenSSL config.

Tomcat starts with NIO2 (OpenSSL) on port 8443.

Prompted for user certificate. Click cancel. Connection refused.

Try again. Prompted for certificate. Select valid cert. Connection allowed.

All seems to be working as expected here.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org