RE: Re: Supported signature algorithms in Tomcat 8.5

[Mandava, Sreevidya]

Hi

Attached my certs. The error message they were getting were "unsupported 
signature algorithm ecdsa_sha1". Unfortunately don't have the logs and can't 
paste the actual client cert. I only have a packet capture during the failure 
and I was comparing tomcat logs from successful case and the packet capture 
from failure case. I noticed that the only difference is when the tomcat is 
requesting for client certificate it is sending list of acceptable/supported 
certificate types and signature algorithms. I am trying to understand where 
tomcat gets those values from? We don't enable/disable any signature algorithms 
 in our java.security or java.policy files or in Catalina.policy files. The 
only place we specify any ciphers is in our connector (connector.txt). How does 
tomcat determine what to send as an acceptable/supported certificate type or 
signature algorithm?


Thanks



-Original Message-
From: Christopher Schultz 
Sent: Wednesday, September 22, 2021 6:16 PM
To: users@tomcat.apache.org
Subject: {EXTERNAL} Re: Supported signature algorithms in Tomcat 8.5

CAUTION: The message originated from an EXTERNAL SOURCE. Please use caution 
when opening attachments, clicking links or responding to this email.



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

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.
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 10285467790209796342 (0x8ebd5275e02d48f6)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Missouri, L=OFallon, O=Mastercard, OU=RSA Test CA, 
CN=RSA Test CA/emailAddress=sreevidya.mand...@mastercard.com
Validity
Not Before: Sep 16 17:40:39 2021 GMT
Not After : Sep 16 17:40:39 2022 GMT
Subject: C=US, ST=Missouri, L=OFallon, O=Mastercard, OU=ECDSA Test 
Client, CN=ECDSA Test Client/emailAddress=sreevidya.mand...@mastercard.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub: 
04:a7:a0:ae:3b:02:26:ba:b9:2b:f4:06:80:b9:c4:
83:db:70:31:bf:96:45:c7:ab:63:73:78:dc:41:da:
44:c0:e9:41:a4:79:b4:64:c9:29:eb:3d:59:07:67:
95:da:0a:80:71:30:7b:19:30:31:37:47:6b:78:92:
a9:48:f8:8c:c2
ASN1 OID: prime256v1
Signature Algorithm: sha256WithRSAEncryption
 1f:3c:bb:e5:18:48:b5:bf:90:8a:af:9a:5a:42:64:e3:6e:52:
 20:71:8a:f8:4d:5c:ac:2a:a9:a5:9c:2f:22:9a:8a:ea:d0:6e:
 47:36:7c:52:8e:8f:10:45:4b:a8:aa:cd:50:d2:04:ed:d5:87:
 82:f4:f8:fa:70:84:ce:b6:90:c7:e1:1d:1a:35:60:21:7b:cd:
 2b:c3:9b:09:6a:f7:a5:d9:3b:ee:a2:bb:99:72:4d:44:8b:0c:
 f2:be:bf:7e:2e:fc:9d:88:a6:07:e6:24:65:3f:96:34:b8:79:
 04:42:6b:13:e8:5e:bc:44:13:2c:c8:5d:52:04:96:6e:44:44:
 cd:e5:9b:c0:21:1a:73:59:ff:00:01:9f:e2:7b:af:c3:cb:a9:
 8b:5f:75:9f:7c:30:c3:ee:12:52:65:d2:7f:6f:ca:9a:06:83:
 fd:aa:5e:64:35:6e:ca:5b:28:19:8b:32:97:7c:83:91:ec:7c:
 17:3b:cc:02:6a:98:1a:8f:2b:a6:5b:9d:9d:46:50:3f:87:82:
 

Re: Checksum Validation of Release 9.0.53 on a Mac

[Darryl Philip Baker]

As I thought I was doing things wrong, thanks.


Darryl Baker, GSEC  (he/him/his)
Sr. System Administrator
Distributed Application Platform Services
Northwestern University
4th Floor
2020 Ridge Avenue
Evanston, IL  60208-0801
darryl.ba...@northwestern.edu
(847) 467-6674 
 

On 9/23/21, 10:03 AM, "Chris Cheshire"  wrote:


> On Sep 23, 2021, at 10:48 AM, Darryl Philip Baker 
 wrote:
> 
> I am trying to download and validate the binary release 53 file name is 
apache-tomcat-9.0.53.tar.gz using openssl and the SHA256 checksum from the link 
on the download web page. The target system for the installation is running 
RHEL7. The checksums don’t match. I don’t know if I am doing things wrong or 
there is an issue. If I am doing something wrong please let me know.
> 
> Here is what I am doing and the output on my Mac (11.6):
> $ /usr/bin/openssl sha256 apache-tomcat-9.0.53.tar.gz
> SHA256(apache-tomcat-9.0.53.tar.gz)= 
7b3e456ed76b0b42d99767985dc3774b22e2388834994f8539272eb7c05ab6fd
> $
> 
> The displayed checksum from the link on the download page is:
> 
ee731b2d0c3ab7e14fa924dcb8d598707cedf714c9ce1f2c2d907a1fd51e26f7eec1343c3dc39e240ff64dac2e0213f154d23e5f94a430f429165b5df51f786f
> 
Darryl,

The checksums are pgp and sha512.

On my Mac I used

$ shasum -a 512 apache-tomcat-9.0.53.tar.gz

and the checksums match.

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: Checksum Validation of Release 9.0.53 on a Mac

[Chris Cheshire]

> On Sep 23, 2021, at 10:48 AM, Darryl Philip Baker 
>  wrote:
> 
> I am trying to download and validate the binary release 53 file name is 
> apache-tomcat-9.0.53.tar.gz using openssl and the SHA256 checksum from the 
> link on the download web page. The target system for the installation is 
> running RHEL7. The checksums don’t match. I don’t know if I am doing things 
> wrong or there is an issue. If I am doing something wrong please let me know.
> 
> Here is what I am doing and the output on my Mac (11.6):
> $ /usr/bin/openssl sha256 apache-tomcat-9.0.53.tar.gz
> SHA256(apache-tomcat-9.0.53.tar.gz)= 
> 7b3e456ed76b0b42d99767985dc3774b22e2388834994f8539272eb7c05ab6fd
> $
> 
> The displayed checksum from the link on the download page is:
> ee731b2d0c3ab7e14fa924dcb8d598707cedf714c9ce1f2c2d907a1fd51e26f7eec1343c3dc39e240ff64dac2e0213f154d23e5f94a430f429165b5df51f786f
> 
Darryl,

The checksums are pgp and sha512.

On my Mac I used

$ shasum -a 512 apache-tomcat-9.0.53.tar.gz

and the checksums match.

Chris


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

Checksum Validation of Release 9.0.53 on a Mac

[Darryl Philip Baker]

I am trying to download and validate the binary release 53 file name is 
apache-tomcat-9.0.53.tar.gz using openssl and the SHA256 checksum from the link 
on the download web page. The target system for the installation is running 
RHEL7. The checksums don’t match. I don’t know if I am doing things wrong or 
there is an issue. If I am doing something wrong please let me know.

Here is what I am doing and the output on my Mac (11.6):
$ /usr/bin/openssl sha256 apache-tomcat-9.0.53.tar.gz
SHA256(apache-tomcat-9.0.53.tar.gz)= 
7b3e456ed76b0b42d99767985dc3774b22e2388834994f8539272eb7c05ab6fd
$

The displayed checksum from the link on the download page is:
ee731b2d0c3ab7e14fa924dcb8d598707cedf714c9ce1f2c2d907a1fd51e26f7eec1343c3dc39e240ff64dac2e0213f154d23e5f94a430f429165b5df51f786f

Darryl Baker, GSEC  (he/him/his)
Sr. System Administrator
Distributed Application Platform Services
Northwestern University
4th Floor
2020 Ridge Avenue
Evanston, IL  60208-0801
darryl.ba...@northwestern.edu
(847) 467-6674

Possible UpgradeInfo memory leak

[Harri Pesonen]

Hello, while looking at Tomcat 8.5.61 heap dump in VisualVM, in Dominators by 
Retained Size, two biggest ones are:

org.apache.tomcat.util.net.NioEndpoint#1  12 382 781 B (13,7%)
org.apache.coyote.http11.upgrade.UpgradeGroupInfo#1  7 066 212 B (7,8%)

I am wondering about UpgradeGroupInfo, because it has very large array of 
UpgradeInfos:

oname = javax.management.ObjectName#1240 : 
Catalina:Upgrade=websocket,name="https-jsse-nio-10.8.35.86-8443",type=GlobalRequestProcessor
 31 B (0%)  363 B (0%)
upgradeInfos = java.util.ArrayList#10079 : 146 098 elements 
20 B (0%)  7 066 144 B (7,8%)
elementData = java.lang.Object[]#22702 : 160 065 items   640 276 B (0,7%)   
 7 066 124 B (7,8%)
[0] = org.apache.coyote.http11.upgrade.UpgradeInfo#144 B (0%)  44 B 
(0%)

Single UpgradeInfo is very small, but there are 146 098 of them.
org.apache.coyote.http11.upgrade.UpgradeInfo   146 098 (12,8%)

I am not sure what this UpgradeInfo is, it looks like some statistics about 
upgraded connection, in this case from http to websocket.
To me it looks like these UpgradeInfos are not removed when connection is 
closed.
Any comments?

Thanks, Harri

AW: JASPIC AuthConfigProvider packaged with the web application not found

[Keil, Matthias (ORISA Software GmbH)]

Hi Bernd, 

Yes, I would like to define my Server Auth module in the jaspic-providers.xml 
and then provide the class with the web application.


Mit vielen Grüßen

Matthias Keil

-Ursprüngliche Nachricht-
Von: Bernd Schatz  
Gesendet: Dienstag, 21. September 2021 23:25
An: users@tomcat.apache.org
Betreff: Re: JASPIC AuthConfigProvider packaged with the web application not 
found

Hi,


Am 19.09.21 um 19:48 schrieb Keil, Matthias (ORISA Software GmbH):
> Hello everyone and thanks for the hints.
> They also work as expected and I can package the provider in the web 
> application .
> 
> Nevertheless, the Configuration Reference 
> (https://tomcat.apache.org/tomcat-9.0-doc/config/jaspic.html) suggests that 
> you define your own provider in jaspic-providers.xml and Tomcat will then 
> find it.
> I am really only interested in a separate server auth module (SAM). Since I 
> saw no way in the documentation to pack this into the web application. That's 
> why I tried the way through the provider.


You want to define the class in the  jaspic-providers.xml but package the 
provider implementation(s) in the application(s) ?

> 
> As I said, your suggestions work, but there are also a number of additional 
> classes needed to provide the actual SAM.
> Thank you again

If you dont need the whole flexibility of JASPI you can also do something like 
this:


public class MyAuthProvider implements AuthConfigProvider, 
ServerAuthConfig, ServerAuthModule, ServerAuthContext


-- 
Greets
   Bernd









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