Re: Supported signature algorithms in Tomcat 8.5

2021-09-24 Thread Christopher Schultz

Sreevidya,

On 9/23/21 22:11, Mandava, Sreevidya wrote:

Attached my certs.


Details for your certificates:

rsatestca:
Certificate type: RSA 2048-bit
Signature algorithm: sha256WithRSAEncryption

This is a self-signed certificate.

ecdsatestclient:
Certificate type: EC curve=prime256v1
Signature algorithm: sha256WithRSAEncryption

So yes, you are indeed using an EC key with an RSA signature. Uncommon, 
but certainly not impossible.


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?
I don't see any ECDSA_SHA1 in use in the certs themselves. Perhaps the 
problem is some algorithm chosen at runtime? ECDSA_SHA1 might be chosen 
as a part of the cipher suite chosen by the server.


What version of Java are you using?

Here is your connector (minus some irrelevant info):



Are you using the "rsatestca" certificate for your server, or something 
else? You have only enabled RSA cipher suites. I'm not sure what that 
will do when you have a mixed-key-type certificate chain for the 
client-certificate.


Is there any particular reason why you are using RSA for the CA and EC 
for the client-cert?


-chris


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



-
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: Re: Supported signature algorithms in Tomcat 8.5

2021-09-23 Thread 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:8

Re: Supported signature algorithms in Tomcat 8.5

2021-09-22 Thread 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

2021-09-22 Thread 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