Re: Supported signature algorithms in Tomcat 8.5

[Christopher Schultz]

Sreevidya,

On 9/22/21 12:25, Mandava, Sreevidya wrote:

Tomcat version : 8.5.70

Attached my self -signed client cert(ecdsatestclient.crt_txt), self 
signed CA (rsatestca_original.crt_txt)output from openssl 
(defaultciphersuite.txt) my connector configuration(connector.txt)


Your attachment has been stripped. Please copy/paste your certificate in 
PEM-encoded-DER format (i.e. -BEGIN CERTIFICATE-) into the body 
of your post.


Problem: We have a client that is connecting to tomcat with an ECC cert 
signed by a RSA signer.


That would be a very odd configuration indeed.


Client authentication is enabled in tomcat. They are seeing handshake
failures in ClientKeyExchange/Certificate Verify stage.

Do you have a specific error message and/or stack trace?


Why is there difference between the “certificate types” and
“signature algorithms”? Where/how  does tomcat get the values for
“certificate types” and “supported signature algorithms”?
Certificate types are usually "RSA" or "EC" (or maybe "DSA") and 
sometimes just, generically, X.509. Signature algorithms are typically 
things like "sha256withRSAencryption", etc.


Having the certificate itself would be very helpful in trying to debug 
this issue.


-chris

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

Supported signature algorithms in Tomcat 8.5

[Mandava, Sreevidya]

Hi

Tomcat version : 8.5.70
Attached my self -signed client cert(ecdsatestclient.crt_txt), self signed CA 
(rsatestca_original.crt_txt)output from openssl (defaultciphersuite.txt) my 
connector configuration(connector.txt)

Problem: We have a client that is connecting to tomcat with an ECC cert signed 
by a RSA signer. Client authentication is enabled in tomcat. They are seeing 
handshake failures in ClientKeyExchange/Certificate Verify stage. To emulate 
their failure I generated self signed certs and tested with tomcat. I was able 
to make a successful connection. I attached my self signed certs ,connector 
configuration and openssl output from my successful test. I don't have the 
actual logs or client cert but I do have a packet capture during failure. I see 
in "CertificateRequest" message sent by server(tomcat) it is sending a list of 
"certificate types, supported signature algorithms and certificate 
authorities". I get that "certificate authorities" come from tomcat's 
truststore.  I was comparing the packet capture and tomcat log from successful 
case and  noticed that "certificate types and supported signature algorithms" 
are different between successful and failure cases. Why is there difference 
between the "certificate types" and "signature algorithms"? Where/how  does 
tomcat get the values for  "certificate types" and "supported signature 
algorithms" ?

We don't enable/disable/define any certificate types or signature algorithms in 
Catalina.policy or in the java.security or java.policy files(java that tomcat 
is pointing to). We have unlimited strength cryptography policy files.

I added client certificate issuer's CA into server's trust store and vice versa 
before I ran the openssl command.

The command I used to test is

openssl s_client -connect X.X.X.X:XX -cert ecdsatestclient.crt -key 
myselfsigned.key -CAfile rsatestca.crt -msg -state -showcerts -debug


CertificateRequest in successful case

javax.net.ssl|FINE|1F|https-jsse-nio2-X.X.X.X:XXX-exec-2|2021-09-22 
01:29:05.176 UTC|CertificateRequest.java:618|Produced CertificateRequest 
handshake message (
"CertificateRequest": {
  "certificate types": [ecdsa_sign, rsa_sign, dss_sign]
  "supported signature algorithms": [ecdsa_secp256r1_sha256, 
ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, 
rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, 
rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, 
rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, 
rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
  "certificate authorities": []
}


CertificateRequest in failure case:

Handshake Protocol: Certificate Request
Handshake Type: Certificate Request (13)
Length: 3316
Certificate types count: 2
Certificate types (2 types)
Certificate type: RSA Sign (1)
Certificate type: DSS Sign (2)
Signature Hash Algorithms Length: 30
   Signature Hash Algorithms (15 algorithms)
Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
Signature Algorithm: rsa_pss_pss_sha256 (0x0809)
Signature Algorithm: rsa_pss_pss_sha384 (0x080a)
Signature Algorithm: rsa_pss_pss_sha512 (0x080b)
Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature Algorithm: SHA256 DSA (0x0402)
Signature Algorithm: SHA224 RSA (0x0301)
Signature Algorithm: SHA224 DSA (0x0302)
Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
Signature Algorithm: SHA1 DSA (0x0202)
Signature Algorithm: MD5 RSA (0x0101)

Thanks
Sreevidya










CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the 
use of the intended recipient and may contain information that is privileged, 
confidential or exempt from disclosure under applicable law. If you are not the 
intended recipient, any disclosure, distribution or other use of this e-mail 
message or attachments is prohibited. If you have received this e-mail message 
in error, please delete and notify the sender immediately. Thank you.

CONNECTED(0003)
---
Certificate chain
 0 s:/C=US/ST=Missouri/L=St Louis/O=Testing/OU=Server/CN=4e820814131f
   i:/C=BE/O=MasterCard Worldwide/OU=Corporate Security/CN=MasterCard DEV 
Generic Sub CA1 G2
 1 s:/C=BE/O=MasterCard Worldwide/OU=Corporate Security/CN=MasterCard DEV 
Generic Sub CA1 G2
   i:/C=BE/O=MasterCard Worldwide/OU=Corporate Security/CN=MasterCard DEV 
Generic Root CA1 G2
 2 s:/C=BE/O=MasterCard Worldwide/OU=Corporate Security/CN=MasterCard DEV 
Generic Root CA1 G2
   i:/C=BE/O=MasterCard 

Re: Tomcat SSL - Issue

[Niranjan Babu Bommu]

port where server is listening ssl(8443) and ipaddres of server where
tomcat is running, expect output like this

starting Nmap 6.40 ( http://nmap.org ) at 2021-09-22 14:35 EDT
Nmap scan report for 12.0.0.1
Host is up (0.35s latency).
PORT STATE SERVICEVERSION
8443/tcp open  https-alt?
| ssl-enum-ciphers:
|   TLSv1.0:
| ciphers:
|   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|   TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|   TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
|   NULL
|   TLSv1.1:
| ciphers:
|   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|   TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|   TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
|   NULL
|   TLSv1.2:
| ciphers:
|   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|   TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|   TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong
|   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
|   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
|   NULL
|_  least strength: strong


On Wed, Sep 22, 2021 at 8:48 AM Kumawat, Priyanka 
wrote:

> Hi Niranjan ,
>
> Thankyou.
>
> The script here on the below command will be the ssltest script that Chris
> have given ?
> Also IP address will be the IP of the server .?
>
>
> nmap -sV --script ssl-enum-ciphers -p  
>
> https://clicktime.symantec.com/3Cx1tBjB9n6EQyoUQjHJNWU7Vc?u=https%3A%2
> F%2Fgithub.com%2FChristopherSchultz%2Fssltest
>
>
> Thanks & Regards,
>
> Priyanka Kumawat | Middleware Admin
> T +91.7879364483
> EMail - priyanka.kuma...@dxc.com
> DL - ams-leveraged-webadmin-offsh...@dxc.com
>
> DXC Technology
>
>
>
>
>
>
> -Original Message-
> From: Niranjan Babu Bommu 
> Sent: 22 September 2021 04:53
> To: Tomcat Users List 
> Subject: Re: Tomcat SSL - Issue
>
> Another way you get supported is TLS and the cipher suite.
>
> nmap -sV --script ssl-enum-ciphers -p  
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> nmap -sV --script ssl-enum-ciphers -p  
>
>
>
> On Tue, Sep 21, 2021 at 5:25 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > Priyanka,
> >
> > On 9/21/21 13:52, Kumawat, Priyanka wrote:
> > > Hello Team ,
> > >
> > > Please find the error details as below -
> > >
> > > The site can’t provide a secure connection .
> > >
> > > xmotam01.phl.com uses an unsupported protocol
> > >
> > > ERR_SSL_VERSION or CIPHER MISMATCH
> > >
> > > Unsupported protocol – The client and server don;t support a common
> > > protocol version.
> >
> > Many versions of Java 1.7 do not support TLSv1.2. Try running this
> > tool under your Java 1.7 environment for some good information:
> >
> > https://clicktime.symantec.com/3Cx1tBjB9n6EQyoUQjHJNWU7Vc?u=https%3A%2
> > F%2Fgithub.com%2FChristopherSchultz%2Fssltest
> >
> > -chris
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>
> --
> *Thanks*
> *Niranjan*
>
>
> DXC Technology Company -- This message is transmitted to you by or on
> behalf of DXC Technology Company or one of its affiliates. It is intended
> exclusively for the addressee. The substance of this message, along with
> any attachments, may contain proprietary, confidential or privileged
> information or information that is otherwise legally exempt from
> disclosure. Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient of this message, you are
> not authorized to read, print, retain, copy or disseminate any part of this
> message. If you have received this message in error, please destroy and
> delete all copies and notify the sender by return e-mail. Regardless of
> content, this e-mail shall not operate to bind DXC Technology Company or
> any of its affiliates to any order or other contract unless pursuant to
> explicit written agreement or government initiative expressly permitting
> the use of e-mail for such purpose.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For 

Re: Tomcat SSL - Issue

[Christopher Schultz]

Niranjan,

On 9/21/21 19:23, Niranjan Babu Bommu wrote:

Another way you get supported is TLS and the cipher suite.

nmap -sV --script ssl-enum-ciphers -p  

nmap -sV --script ssl-enum-ciphers -p  


nmap is great, but it won't tell you what your Java client's 
capabilities are.


-chris


On Tue, Sep 21, 2021 at 5:25 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Priyanka,

On 9/21/21 13:52, Kumawat, Priyanka wrote:

Hello Team ,

Please find the error details as below -

The site can’t provide a secure connection .

xmotam01.phl.com uses an unsupported protocol

ERR_SSL_VERSION or CIPHER MISMATCH

Unsupported protocol – The client and server don;t support a common
protocol version.


Many versions of Java 1.7 do not support TLSv1.2. Try running this tool
under your Java 1.7 environment for some good information:

https://github.com/ChristopherSchultz/ssltest

-chris

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






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

RE: Tomcat SSL - Issue

[Kumawat, Priyanka]

Hi Niranjan ,

Thankyou.

The script here on the below command will be the ssltest script that Chris have 
given ?
Also IP address will be the IP of the server .?


nmap -sV --script ssl-enum-ciphers -p  

https://clicktime.symantec.com/3Cx1tBjB9n6EQyoUQjHJNWU7Vc?u=https%3A%2
F%2Fgithub.com%2FChristopherSchultz%2Fssltest


Thanks & Regards,

Priyanka Kumawat | Middleware Admin
T +91.7879364483
EMail - priyanka.kuma...@dxc.com
DL - ams-leveraged-webadmin-offsh...@dxc.com

DXC Technology






-Original Message-
From: Niranjan Babu Bommu 
Sent: 22 September 2021 04:53
To: Tomcat Users List 
Subject: Re: Tomcat SSL - Issue

Another way you get supported is TLS and the cipher suite.

nmap -sV --script ssl-enum-ciphers -p  
















nmap -sV --script ssl-enum-ciphers -p  



On Tue, Sep 21, 2021 at 5:25 PM Christopher Schultz < 
ch...@christopherschultz.net> wrote:

> Priyanka,
>
> On 9/21/21 13:52, Kumawat, Priyanka wrote:
> > Hello Team ,
> >
> > Please find the error details as below -
> >
> > The site can’t provide a secure connection .
> >
> > xmotam01.phl.com uses an unsupported protocol
> >
> > ERR_SSL_VERSION or CIPHER MISMATCH
> >
> > Unsupported protocol – The client and server don;t support a common
> > protocol version.
>
> Many versions of Java 1.7 do not support TLSv1.2. Try running this
> tool under your Java 1.7 environment for some good information:
>
> https://clicktime.symantec.com/3Cx1tBjB9n6EQyoUQjHJNWU7Vc?u=https%3A%2
> F%2Fgithub.com%2FChristopherSchultz%2Fssltest
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

--
*Thanks*
*Niranjan*


DXC Technology Company -- This message is transmitted to you by or on behalf of 
DXC Technology Company or one of its affiliates. It is intended exclusively for 
the addressee. The substance of this message, along with any attachments, may 
contain proprietary, confidential or privileged information or information that 
is otherwise legally exempt from disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended recipient 
of this message, you are not authorized to read, print, retain, copy or 
disseminate any part of this message. If you have received this message in 
error, please destroy and delete all copies and notify the sender by return 
e-mail. Regardless of content, this e-mail shall not operate to bind DXC 
Technology Company or any of its affiliates to any order or other contract 
unless pursuant to explicit written agreement or government initiative 
expressly permitting the use of e-mail for such purpose.

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

Re: mirrors are broken?

[Mark Thomas]

On 22/09/2021 10:00, jean-frederic clere wrote:

Hi,

https://tomcat.apache.org/download-90.cgi gives me:
+++
Error!

/var/www/dyn/closer.lua:322: attempt to index local 'cdn_uri_check' (a 
nil value)

+++

Have we break something with the mirror logic? Or is my favorite mirror 
broken?


https://bz.apache.org/bugzilla/show_bug.cgi?id=65587

Mark

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

mirrors are broken?

[jean-frederic clere]

Hi,

https://tomcat.apache.org/download-90.cgi gives me:
+++
Error!

/var/www/dyn/closer.lua:322: attempt to index local 'cdn_uri_check' (a 
nil value)

+++

Have we break something with the mirror logic? Or is my favorite mirror 
broken?


--
Cheers

Jean-Frederic


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

Re: Tomcat 9.0 async read becomes blocking

[Mark Thomas]

On 22/09/2021 08:22, Goldengate liu wrote:

Hi Chris,
Servlet 3.1 spec defines that ServletInputStream can be used to read as 
non-blocking way as long as there is data ready locally by calling isReady 
method and check the ready condition before calling read, and read should throw 
IllegalStateException if called by caller when data is not ready


The above only applies if the servlet is in async mode. Is it?


correct, when it’s running as async mode


OK. You are going to need to provide the simplest complete example that 
demonstrates this then. Something like the source for a single Servlet 
and a curl command to send a request to it.


Mark


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

Re: Tomcat 9.0 async read becomes blocking

[Goldengate liu]

>> Hi Chris,
>> Servlet 3.1 spec defines that ServletInputStream can be used to read as 
>> non-blocking way as long as there is data ready locally by calling isReady 
>> method and check the ready condition before calling read, and read should 
>> throw IllegalStateException if called by caller when data is not ready
> 
> The above only applies if the servlet is in async mode. Is it?

correct, when it’s running as async mode 

Andrew


> On Sep 21, 2021, at 11:17 PM, Mark Thomas  wrote:
> 
> On 21/09/2021 23:01, Javateck wrote:
>> Hi Chris,
>> Servlet 3.1 spec defines that ServletInputStream can be used to read as 
>> non-blocking way as long as there is data ready locally by calling isReady 
>> method and check the ready condition before calling read, and read should 
>> throw IllegalStateException if called by caller when data is not ready
> 
> The above only applies if the servlet is in async mode. Is it?
> 
> Mark
> 
> 
>> Agree that InputStream read api is blocking by nature, but if the data is 
>> already there in local buffer, then it’s not, it’s just exposing as 
>> ServletInputStream
>> https://javaee.github.io/servlet-spec/downloads/servlet-3.1/Final/servlet-3_1-final.pdf
>>  
>> 
>>  
>> >  
>> >
>>> On Sep 21, 2021, at 2:26 PM, Christopher Schultz 
>>> mailto:ch...@christopherschultz.net>> wrote:
>>> 
>>> Andrew,
>>> 
>>> On 9/21/21 13:54, Javateck wrote:
 Hi,
 With NIO connector with Servlet 3.1 support, I’m registering with a 
 ReadListener, while it got the first read signal from tomcat container (I 
 tried 9.0.19 and 9.0.53), the read call is blocked after isReady returns 
 true
   if (ServletInputStream.isReady()) {
ServletInputStream.read(buffer);  // this becomes blocking
   }
 I tried with jetty, it’s working fine
 When I did the test, I was holding the sending packet from client side
 Not sure whether anyone has tried this
>>> 
>>> InputStream is always blocking.
>>> 
>>> Are you trying to use async? That's not the way to use async...
>>> 
>>> -chris
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org 
> 
> For additional commands, e-mail: users-h...@tomcat.apache.org 
> 

Re: Tomcat 9.0 async read becomes blocking

[Mark Thomas]

On 21/09/2021 23:01, Javateck wrote:

Hi Chris,

Servlet 3.1 spec defines that ServletInputStream can be used to read as 
non-blocking way as long as there is data ready locally by calling 
isReady method and check the ready condition before calling read, and 
read should throw IllegalStateException if called by caller when data is 
not ready


The above only applies if the servlet is in async mode. Is it?

Mark




Agree that InputStream read api is blocking by nature, but if the data 
is already there in local buffer, then it’s not, it’s just exposing as 
ServletInputStream


https://javaee.github.io/servlet-spec/downloads/servlet-3.1/Final/servlet-3_1-final.pdf 






On Sep 21, 2021, at 2:26 PM, Christopher Schultz 
 wrote:


Andrew,

On 9/21/21 13:54, Javateck wrote:

Hi,
With NIO connector with Servlet 3.1 support, I’m registering with a 
ReadListener, while it got the first read signal from tomcat 
container (I tried 9.0.19 and 9.0.53), the read call is blocked after 
isReady returns true

  if (ServletInputStream.isReady()) {
   ServletInputStream.read(buffer);  // this becomes blocking
  }
I tried with jetty, it’s working fine
When I did the test, I was holding the sending packet from client side
Not sure whether anyone has tried this


InputStream is always blocking.

Are you trying to use async? That's not the way to use async...

-chris

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




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