Closed Bug 441321 Opened 15 years ago Closed 15 years ago

Tolerate incorrect encoding of DSA signatures in SSL 3.0 handshakes

Categories

(NSS :: Libraries, enhancement, P3)

Product:
NSS
Component:
Libraries
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
3.12.3

People

(Reporter: lothar.haeger, Assigned: nelson)

References

(
URL
)

Details

Attachments

(1 file)

Patch v1 for NSS Trunk
724 bytes, patch
wtc
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0

trying to open https://passwd.steria-mummert.de lets FF3 show error "sec_error_bad_signature", though FF" and IE7 both successfully verify the cert. This is NOT a self-signed cert, and there is NO domain name mismatch as in other bugs reported about this error message. 
The CA that verified the cert is "TC TrustCenter Class 3 CA", which is a build-in token in FF3. What's going wrong here???

Reproducible: Always

Steps to Reproduce:
1. open https://passwd.steria-mummert.de in FF3 on WinXP
Moving to Core.  Typically I would expect this to be a configuration problem on the site's side, but in this case I can't rule out a problem.  I used openssl (since it's a non-NSS ssl engine) to test, using:

openssl s_client -connect passwd.steria-mummert.de:443 -showcerts

to get the certs in pem format, copying them to files, and then running:

openssl verify -verbose -purpose any -CAfile issuer.pem cert.pem 

To check the signature, which raised no complaints.  Perhaps I'm doing it wrong, but in any event, there are better better equipped than I to check this.
Status: UNCONFIRMED → NEW
Component: Security → Security: PSM
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Core
Hardware: PC → All
running "openssl s_client -connect passwd.steria-mummert.de:443 -showcerts" shows that the server also sends the CA cert, which is also validated by FF3 and found to be self-signed (what a surprise ;-). I'd say FF3 should not look at the CA cert in this case, since it's already known to be trusted root. Or recognize the CA cert as such and not complain about it being self-signed...

--------------------------------------

> openssl s_client -connect passwd.steria-mummert.de:443 -showcerts
CONNECTED(00000003)
depth=1 /C=DE/ST=Hamburg/L=Hamburg/O=TC TrustCenter for Security in Data Networks GmbH/OU=TC TrustCenter Class 3 CA/emailAddress=certificate@trustcenter.de
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/C=DE/ST=Hamburg/L=Hamburg/O=Steria Mummert Consulting AG/OU=Information Technology/CN=passwd.steria-mummert.de/emailAddress=webmaster@steria-mummert.de
   i:/C=DE/ST=Hamburg/L=Hamburg/O=TC TrustCenter for Security in Data Networks GmbH/OU=TC TrustCenter Class 3 CA/emailAddress=certificate@trustcenter.de
-----BEGIN CERTIFICATE-----
MIIE6jCCBFOgAwIBAgIPANFiAAEAAkDcDGt3U2H+MA0GCSqGSIb3DQEBBQUAMIG8
MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVy
ZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEg
TmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMyBD
QTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUwHhcN
MDcwOTE3MTM0NjAyWhcNMDgwOTE2MTM0NjAyWjCByDELMAkGA1UEBhMCREUxEDAO
BgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxJTAjBgNVBAoTHFN0ZXJp
YSBNdW1tZXJ0IENvbnN1bHRpbmcgQUcxHzAdBgNVBAsTFkluZm9ybWF0aW9uIFRl
Y2hub2xvZ3kxITAfBgNVBAMTGHBhc3N3ZC5zdGVyaWEtbXVtbWVydC5kZTEqMCgG
CSqGSIb3DQEJARYbd2VibWFzdGVyQHN0ZXJpYS1tdW1tZXJ0LmRlMIIBtzCCASwG
ByqGSM44BAEwggEfAoGBAP1/U4EddRIpUt9KnC7s5Of2EbdSPO9EAMMeP4C2USZp
RV1AIlH7WT2NWPq/xfW6MPbLm1Vs14E7gB00b/JmYLdrmVClpJ+f6AR7ECLCT7up
1/63xhv4O1fnxqimFQ8E+4P208UewwI1VBNaFpEy9nXzrith1yrv8iIDGZ3RSAHH
AhUAl2BQjxUjC8yykrmCouuEC/BYHPUCgYEA9+GghdabPd7LvKtcNrhXuXmUr7v6
OuqC+VdMCz0HgmdRWVeOutRZT+ZxBxCBgLRJFnEj6EwoFhO3zwkyjMim4TwWeotU
fI0o4KOuHiuzpnWRbqN/C/ohNWLx+2J6ASQ7zKTxvqhRkImog9/hWuWfBpKLZl6A
e1UlZAFMO/7PSSoDgYQAAoGAeKcSv3e/ZDtAvbqGsUoBBtfY8RSVG6NtFfQJBB0b
L4NN3vaRmQ7w0s6nrIAP2nw0ppiAsG+iLPyrZpfKe2DdQenbUMo+WuRV41sDgdz7
UuBRlzedE+W+bhx8SFV4eKKxjHYrRgd0d/R080aEvCeIGZ+WOU12FpPlqxWAPPok
HtOjgcYwgcMwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwPgYJYIZIAYb4
QgEIBDEWL2h0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lcy9pbmRl
eC5odG1sMBEGCWCGSAGG+EIBAQQEAwIGQDBQBglghkgBhvhCAQMEQxZBaHR0cHM6
Ly9ucnUudGNjbGFzczMudHJ1c3RjZW50ZXIuZGUvRDE2MjAwMDEwMDAyNDBEQzBD
NkI3NzUzNjFGRT8wDQYJKoZIhvcNAQEFBQADgYEAa+rdq49IUNM3Ve3HaH1/goB+
n/SCoGD1BcDdzO0kHOeNyOBLDNEdoQWMi+WUzKz4DLtjGgVrdFCqJq3l1Pik2KFf
Yoguxx6TjCcCJ7pey54T6QwnkGmWHfh+cX4hj23TTE3fGztk8+1w1cqZj9yVXiNn
hl9dcEbEpHKyBVeCIqw=
-----END CERTIFICATE-----
 1 s:/C=DE/ST=Hamburg/L=Hamburg/O=TC TrustCenter for Security in Data Networks GmbH/OU=TC TrustCenter Class 3 CA/emailAddress=certificate@trustcenter.de
   i:/C=DE/ST=Hamburg/L=Hamburg/O=TC TrustCenter for Security in Data Networks GmbH/OU=TC TrustCenter Class 3 CA/emailAddress=certificate@trustcenter.de
-----BEGIN CERTIFICATE-----
MIIDXDCCAsWgAwIBAgICA+swDQYJKoZIhvcNAQEEBQAwgbwxCzAJBgNVBAYTAkRF
MRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTowOAYDVQQKEzFU
QyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBHbWJI
MSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAzIENBMSkwJwYJKoZIhvcN
AQkBFhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZTAeFw05ODAzMDkxMTU5NTla
Fw0xMTAxMDExMTU5NTlaMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVy
ZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9y
IFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1
c3RDZW50ZXIgQ2xhc3MgMyBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVA
dHJ1c3RjZW50ZXIuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALa0wTUF
Lg2N7KBAahwOJ6ZQkmtQGwfeLud2zODa/ISoXoxjaitN2U4CdhHBC/KNecoAtvGw
Dtf7pBc9r6tpepYnv68zoZoqWarEtTcI8hKlMbZD9TKWcSgoq40oht+77uMMfTDW
w1Krj10nnGvAo+cFa1dJRLNu6mTP0o56UHd3AgMBAAGjazBpMA8GA1UdEwEB/wQF
MAMBAf8wDgYDVR0PAQH/BAQDAgGGMDMGCWCGSAGG+EIBCAQmFiRodHRwOi8vd3d3
LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwEQYJYIZIAYb4QgEBBAQDAgAHMA0G
CSqGSIb3DQEBBAUAA4GBABY9xs3Bu4VxhUafPiCPUSiZ7C1FIWMjWwS7TJC4iJIE
Tb19AaM/9uzO8d7+feXhPrvGq14L3T2WxMup1Pkm5gZOngylerpuw3yCGdHHsbHD
2w2Om0B8NwvxXej9H5CIpQ5ON2QhqE6NtJ/x3kit1VYYUimLRzQSCdS7kjXvD9s0
-----END CERTIFICATE-----
---
Server certificate
subject=/C=DE/ST=Hamburg/L=Hamburg/O=Steria Mummert Consulting AG/OU=Information Technology/CN=passwd.steria-mummert.de/emailAddress=webmaster@steria-mummert.de
issuer=/C=DE/ST=Hamburg/L=Hamburg/O=TC TrustCenter for Security in Data Networks GmbH/OU=TC TrustCenter Class 3 CA/emailAddress=certificate@trustcenter.de
---
No client certificate CA names sent
---
SSL handshake has read 2619 bytes and written 294 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-DSS-DES-CBC3-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : EDH-DSS-DES-CBC3-SHA
    Session-ID: 48637ACBF9E71025EE192B4A3F153B9190755B0F64A1F8AE57B6C2DCE9EFDCCE
    Session-ID-ctx: 
    Master-Key: F403A340A4E6AAF060861DA62E9D1303F1E1A0465055BDB113A2AC2CB1EE2331BBD15F25A71ED2982D3756A0ADC16E09
    Key-Arg   : None
    Start Time: 1214479051
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
closed

(In reply to comment #3)
> running "openssl s_client -connect passwd.steria-mummert.de:443 -showcerts"
> shows that the server also sends the CA cert, which is also validated by FF3
> and found to be self-signed (what a surprise ;-). I'd say FF3 should not look
> at the CA cert in this case, since it's already known to be trusted root. Or
> recognize the CA cert as such and not complain about it being self-signed...

Yes, sending the CA cert is a normal part of it, and Firefox will be fine with that, assuming that the issuer is in our trusted root (otherwise the error will be different).

The problem here (if it's not just breakage on the server side) seems to be a bug in the way we verify the signature on the server cert, which Ria appears to have tied to bug 406755 - a bug that does indeed have to do with signature verification.  We will need someone like Kai, Bob, Nelson or wtc to weigh in though, on the validity of the error.
The same happened to me recently when setting up my StartCom certificate. It turns out that the certificate bundled in firefox 3.0.5 is outdated. As they have different signature sec_error_bad_signature appears.
Another problem is that when this happens, you are not allowed to take a look at the certificate ( Bug 403220 ), and I tried to remove the outdated cert to import the new one but I was unable.
I have the same problem with a StartCom class 2 certificate which works in other browsers (opera, FF2, netscape, IE6, Safari, Konqueror). Others not tested yet. I also get error sec_error_bad_signature. The root certificate and intermediate server 2 ceritificate of StartCom is not outdated in my case. Here are the certs:

CONNECTED(00000003)
depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/C=DE/ST=Nordrhein-Westfalen/L=Essen/O=Marko Sacher/OU=StartCom Verified Certificate Member/CN=ns.some-time.eu/emailAddress=postmaster@some-time.eu
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
-----BEGIN CERTIFICATE-----
MIIH9zCCBt+gAwIBAgICA9owDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklM
MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh
bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAy
IFByaW1hcnkgSW50ZXJtZWRpYXRlIFNlcnZlciBDQTAeFw0wOTAyMTAxMzE2MjVa
Fw0xMDAyMTAxMzE2MjVaMIHDMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9yZHJo
ZWluLVdlc3RmYWxlbjEOMAwGA1UEBxMFRXNzZW4xFTATBgNVBAoTDE1hcmtvIFNh
Y2hlcjEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlmaWNhdGUgTWVt
YmVyMRgwFgYDVQQDEw9ucy5zb21lLXRpbWUuZXUxJjAkBgkqhkiG9w0BCQEWF3Bv
c3RtYXN0ZXJAc29tZS10aW1lLmV1MIIBtzCCASwGByqGSM44BAEwggEfAoGBAP1/
U4EddRIpUt9KnC7s5Of2EbdSPO9EAMMeP4C2USZpRV1AIlH7WT2NWPq/xfW6MPbL
m1Vs14E7gB00b/JmYLdrmVClpJ+f6AR7ECLCT7up1/63xhv4O1fnxqimFQ8E+4P2
08UewwI1VBNaFpEy9nXzrith1yrv8iIDGZ3RSAHHAhUAl2BQjxUjC8yykrmCouuE
C/BYHPUCgYEA9+GghdabPd7LvKtcNrhXuXmUr7v6OuqC+VdMCz0HgmdRWVeOutRZ
T+ZxBxCBgLRJFnEj6EwoFhO3zwkyjMim4TwWeotUfI0o4KOuHiuzpnWRbqN/C/oh
NWLx+2J6ASQ7zKTxvqhRkImog9/hWuWfBpKLZl6Ae1UlZAFMO/7PSSoDgYQAAoGA
V/4pdrNytgIdFsweNvAZ/A6G0Uj3OdQDULIGEcn4wYa7w23vouGxHEmABhHEbClO
esxlOFKWZlATEKBengTT0hu8ELOrzB7IzWoRa3H15y7vUT42+aq5yBy5egx8Zdbj
073f53PsM/ttpdyq5pW1UdbRPOKZAlethCjtmdNeQrKjggOTMIIDjzAJBgNVHRME
AjAAMAsGA1UdDwQEAwIDqDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEw
HQYDVR0OBBYEFDtXOPLrw6GevtN4BC2FK9Tmi6UrMIGoBgNVHSMEgaAwgZ2AFBHb
I0X9VMxqcW+EigPXvvcBLyaGoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj
YXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0
aG9yaXR5ggELMCgGA1UdEQQhMB+CD25zLnNvbWUtdGltZS5ldYIMc29tZS10aW1l
LmV1MIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYIKwYB
BQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYB
BQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gbwGCCsGAQUFBwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQg
TGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyog
b2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh
dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBh
BgNVHR8EWjBYMCqgKKAmhiRodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnQyLWNy
bC5jcmwwKqAooCaGJGh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydDItY3JsLmNy
bDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3Rh
cnRzc2wuY29tL3N1Yi9jbGFzczIvc2VydmVyL2NhMEIGCCsGAQUFBzAChjZodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLnNlcnZlci5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3
DQEBBQUAA4IBAQCnecAY4rgT2TvyRs/S9dkciMfvlCHIds2Q3mLPvVWAxnjcID5D
1toZwEOnkrxFTonfkxaZGMoVs6Wi76SuEVP/ru1Vy3pLU/AgjzkDiMWprLh4b7gZ
19ySi6CMYQnR59se/WYgoLmRIf4xlwyV7auR/R1PtjhgzP+zlhMzMA4BBRbf+Nx5
ZjC1BdAGJvcUjGXwWt9XmRnobmSFK6abFobLMQumtqXfyi0yGu4dnNZSI83AgTm4
9tD5QQsytzGwfdWUj80EFzOH1nCemGfCvqk8XN8Y3ldlWNfsw9wFj7NdxI5BdvQV
Kj7ubsSSfB47wSsVpcGJjzwDx5RMceu9Jtu0
-----END CERTIFICATE-----
 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
-----BEGIN CERTIFICATE-----
MIIH4zCCBcugAwIBAgIBCzANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjA1NzA4WhcNMTIxMDIyMjA1NzA4WjCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0
YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgU2VydmVyIENBMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4k85L6GMmoWtCA4IPlfyiAEh
G5SpbOK426oZGEY6UqH1D/RujOqWjJaHeRNAUS8i8gyLhw9l33F0NENVsTUJm9m8
H/rrQtCXQHK3Q5Y9upadXVACHJuRjZzArNe7LxfXyz6CnXPrB0KSss1ks3RVG7RL
hiEs93iHMuAW5Nq9TJXqpAp+tgoNLorPVavD5d1Bik7mb2VsskDPF125w2oLJxGE
d2H2wnztwI14FBiZgZl1Y7foU9O6YekO+qIw80aiuckfbIBaQKwn7UhHM7BUxkYa
8zVhwQIpkFR+ZE3EMFICgtffziFuGJHXuKuMJxe18KMBL47SLoc6PbQpZ4rEAwID
AQABo4IDXDCCA1gwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYDVR0OBBYE
FBHbI0X9VMxqcW+EigPXvvcBLyaGMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mH
MMo0aEPQQa7yoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEB
MAkGA1UdEgQCMAAwPQYIKwYBBQUHAQEEMTAvMC0GCCsGAQUFBzAChiFodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwYAYDVR0fBFkwVzAsoCqgKIYmaHR0
cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNybC5jcmwwJ6AloCOGIWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1UdIASCAVQwggFQMIIB
TAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFy
dGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh
cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0
YXJ0IENvbW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExp
YWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9m
IHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZh
aWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMBEG
CWCGSAGG+EIBAQQEAwIABzBRBglghkgBhvhCAQ0ERBZCU3RhcnRDb20gQ2xhc3Mg
MiBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBTZXJ2ZXIgQ2VydGlmaWNh
dGVzMA0GCSqGSIb3DQEBBQUAA4ICAQBkgkxZXAxsFraiOUURh5jfEDOuQp4l0f1w
U0Ve9DXA5DB34Jz37yflbijvrNfzFszBbFOcjy2Cb5T3FDYXrrLloj+ig3Ok36i7
ygExbJpDCN0aXa1LbX/0fvASOgW/p0QQBxdEk1DjlSmz9BPSQOA+3z09OV6BSA8y
ukjVAxv1904KjgON/MqH5snfJt+EOkmxmVU/1CyreA1iAxWfsUVLI3hiKu7re2At
d3IeYSRpYujhNTyCAkAVMktXzZe5KY+k14TbCeU1Wy9gWUnp1ln1+l3IzU2UcMTo
PDUBBnXocZt/KxDKaz/As5dy2v90Fo77+5vkBfCY5xWsyiSi54q0z3IxK+MxDjBf
1cuUs+41BNNFBwkUUYr1BzFeEy9dDNnXNqiwUjeUwnWcWi6o0bBza2naDDrWEWus
nbxFMgXoiXfVt77A7c3NTm0oWArwtFHIzYbRiSPFI+3PEPkObtjB1z+A+qYqR8Tb
BxbnC4tTlxEuo2Ens7tK1wFtsXGl5SPW2qGoVSavt7peVi09EKNxSpNFHHo8kipp
P08elpmQCcgBvyg0sn0RUFnQm+MzVmXumJc/PlRpLSYuAyugvqtrgCDhOku7Jr6r
q6U5sZpJprRblmbiSQtwAqpJSWEO/q71pZbn9rpsiZ8Ocuz7RQCHjyznf7LFpVK+
A/oxKgJq+A==
-----END CERTIFICATE-----
 2 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
-----BEGIN CERTIFICATE-----
MIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9
MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3Rh
cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUA
A4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLWwTYgIiRezul38kMKogZk
pMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXWeUyAN3rf
OQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/C
Ji/6tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYT
Kqi5pquDSR3l8u/d5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNi
HzvEvqBTViVsUQn3qqvKv3b9bZvzndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMM
Av+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu9ydmDBpI125C4z/eIT574Q1w
+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/89PrNbpHoNkm+
Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3
Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B
26Nu/yYwl/WL3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwID
AQABo4ICUjCCAk4wDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYE
FE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3Js
LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFM
BgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFy
dGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3Rh
cnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlh
YmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2Yg
dGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFp
bGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJ
YIZIAYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNT
TCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ
9GYMNPXQhV59CuzaEE44HF7fpiUFS5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8
jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk4gNXcGmXCPleWKYK34wGmkUW
FjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENNZEXO3SipXPJz
ewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1
ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5L
EUTINFInzQpdn4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYu
L6lwhceWD3yJZfWOQ1QOq92lgDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+Pwq
yvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVKt+V9E9e4DGTANtLJL4YSjCMJwRuC
O3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsfvw55qVguucQJAX6V
um0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEkkySh
NOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14=
-----END CERTIFICATE-----
---
Server certificate
subject=/C=DE/ST=Nordrhein-Westfalen/L=Essen/O=Marko Sacher/OU=StartCom Verified Certificate Member/CN=ns.some-time.eu/emailAddress=postmaster@some-time.eu
issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
---
No client certificate CA names sent
---
SSL handshake has read 6559 bytes and written 276 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-DSS-DES-CBC3-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : EDH-DSS-DES-CBC3-SHA
    Session-ID: 4992899223D9D962E2B4667BD6EF082AD66E2FBC556F0B80CFA2404EF0BF5D0F
    Session-ID-ctx:
    Master-Key: 2DED3882FF093853E312C6C2ED76F18EB92CC643BA0386B3A74A6B00A787454010666318315FED07E4AA773E58B5E201
    Key-Arg   : None
    Start Time: 1234340242
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
closed

I also have the problem with Bug 403220.
Lothar, Marko: are you running your Tomcats in a Sun JRE 6 VM, by chance? If so, what build exactly?
JRE 1.6.0u5
It is working now!
The first problem seems to be that FF3 has a problem with DSA signature: bug 452712
The second problem was that my installed Java JRE had a keytool which was not 
able to combine the option -keyalg RSA and -sigalg SHA1withRSA correctly. It generated a key but my CA Startcom said MD5 is no valid algorithm. After an update from JRE 1.5.0.16 to 1.6.0.7 and running the keytool with the following commands it is finally working now:
1. keytool -genkey -alias some-time -dname "cn=Marko Sacher, ou=some-time, 
o=some-time, l=Essen, s=Nordrhein-Westfalen, 
c=DE" -keystore .keystore -validity 365 -keyalg RSA -sigalg 
SHA1withRSA -keysize 2048
2. keytool -certreq -alias some-time -file 
ns.some-time.de.csr -keystore ./.keystore
3. keytool -import -file ca.crt -alias startcom.ca -keystore .keystore
4. keytool -import -alias startcom.ca.sub -file 
sub.class2.server.ca.crt -keystore .keystore
5. keytool -import -alias some-time -file 
ns.some-time.de.signed.crt -keystore .keystore

The problem is solved for me but I think it is still a good idea to make FF3 accept the certificates I posted before with DSA signature.
I presume that both this issue and the one reported in bug 452712 are actually manifestations of bugs in the server-side code of Sun's JRE.

Marko, if you revert to your "old" certificate (the one with the DSA key), but upgrade the JRE to 1.6.0_12, does the problem still exist then? And, second question: what happens if you keep 1.6.0_7 and set "security.enable_tls_session_tickets" in Firefox 3 to false (through about:config)?
When I test the cert chain in comment 3 with NSS's vfychain utility,
  vfychain -d DB -b 0801010101Z -a -u 1 -v /tmp/441321a*pem
(for the date Jan 1, 2008, before the cert expired) it reports that 
the chain is a valid chain for an SSL server cert.  I don't get any 
report of invalid signature.  So, NSS doesn't seem to have any 
problem with that chain.
When I test the chain from comment 6 with NSS's vfychain utility from
NSS 3.12.current, the tests pass, both with and without OCSP checking.

 vfychain -d DB -pp -a -u 1 -v /tmp/441321b*pem

 vfychain -d DB -pp -a -u 1 -v -g leaf -h requireFreshInfo -m ocsp \
 -s failIfNoInfo /tmp/441321b*pem
@Kaspar:
I updated to JRE 1.6.0u11. Still the same problem.
If I set "security.enable_tls_session_tickets" to false it works for DSA key certificate.
Installing a higher update JRE version is more difficult for me because it is the highest available version in SUSE 10.3.
(In reply to comment #13)
> I updated to JRE 1.6.0u11. Still the same problem.

That's what I would expect, yes. You're hit by Sun's bug 6728126, which was only fixed with 1.6.0_12, I'm afraid (see http://java.sun.com/javase/6/webnotes/6u12.html).

> If I set "security.enable_tls_session_tickets" to false it works for DSA key
> certificate.

Ok - this again is another indication that you're hitting the JRE 6 bug mentioned above.

Can you keep the DSA cert around for some further testing? Nelson, the handshake problem can be reproduced with tstclnt, actually - cf.

tstclnt -d /path/to/some/db -h ns.some-time.eu -2oc q
(works ok, negotiates TLSv1)

vs.

tstclnt -d /path/to/some/db -h ns.some-time.eu -2oc q -u
(fails with "SSL peer was not expecting a handshake message it received.")

For Firefox 3, it's actually the handling of TLS intolerant sites which causes these "strange" effects (with SEC_ERROR_BAD_SIGNATURE)... maybe PSM should try without TLS extensions first before falling back to SSLv3/SSLv2?
(In reply to comment #14)
> Can you keep the DSA cert around for some further testing? Nelson, the
> handshake problem can be reproduced with tstclnt, actually - cf.

In the mean time I changed the certificate to a new working one for www.some-time.eu.
I just reinstalled the DSA cert. How long do you need to test it?
Kaspar, 
Given that http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6728126 says
> This bug is not available.
how did you ever find that bug?

Given that there is no problem with the DSA certificate, but that the problem
is in the server's handling of the TLS session ticket client hello extension,
why would changing to an RSA certificate make any difference?  Or am I 
mistaken in understanding that it is thought to have made a difference?
OK, I see what's causing the bad signature error with the DSA cert. 
It's another server bug. 

There is a difference in the definition of the DSA signatures in the
server_key_exchange message between SSL 3.0 and TLS.  In TLS, the DSA
signature is DER encoded, but in SSL 3.0, it is a "raw" binary DSA 
signature, 40 bytes in length.  This server is sending the TLS form 
of a DSA signature in an SSL 3.0 handshake.  It only is a problem when
PSM "falls back" to using SSL 3.0.  It has nothing to do with an SSL2
style client hello.
I think we might be able to make NSS tolerate improperly encoded DSA 
signatures in SSL 3.0 handshakes.  This is not a bug in NSS, but rather 
requests that NSS be enhanced to tolerate buggy servers in this case 
where it seem reasonable and not risky.  I will attempt it.
Assignee: nobody → nelson
Severity: major → enhancement
Component: Security: PSM → Libraries
Product: Core → NSS
QA Contact: firefox → libraries
Summary: FF3 reports sec_error_bad_signature on perfectly good certificate → Tolerate incorrect encoding of DSA signatures in SSL 3.0 handshakes
Target Milestone: --- → 3.12.3
Version: unspecified → trunk
Priority: -- → P3
Wan-Teh, please review this one line patch.
Please see the comments immediately above this one for explanation.
I'm not sure if the test should be != or > .
I can see reasonable arguments for either one.
Attachment #362072 - Flags: review?(wtc)
Comment on attachment 362072 [details] [diff] [review]
Patch v1 for NSS Trunk

r=wtc.  Using != in the test is fine.  If the INTEGER r
or s happens to have a small value, will it still be
encoded as 20 or 21 bytes?

Perhaps you can also check the first byte to verify it
is DER encoding of a SEQUENCE:

    SEQUENCE {
        r INTEGER,
        s INTEGER
    }

A comment that explains we're doing this to tolerate
incorrect servers would be nice.
Attachment #362072 - Flags: review?(wtc) → review+
Checking in ssl3con.c; new revision: 1.115; previous revision: 1.114
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
(In reply to comment #16)
> Kaspar, 
> Given that http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6728126 says
> > This bug is not available.
> how did you ever find that bug?

It's mentioned in the release notes (http://java.sun.com/javase/6/webnotes/6u12.html):

6728126 	jsse 	runtime 	Parsing Extensions in Client Hello message is done in a wrong way 

And thanks to OpenJDK, we also know what exactly the problem is - the UnknownExtension class chokes on empty TLS extensions (such as a ticket in a ClientHello when a new session is negotiated):

http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/2dc727e4b6da

> Given that there is no problem with the DSA certificate, but that the problem
> is in the server's handling of the TLS session ticket client hello extension,
> why would changing to an RSA certificate make any difference?

A very good question, and it seems that you've found the answer in the meantime. If I apply the fix, then I can successfully connect to ns.some-time.eu with Firefox 3, also with the DSA cert (it will fall back to SSL 3.0).

(In reply to comment #15)
> In the mean time I changed the certificate to a new working one for
> www.some-time.eu.
> I just reinstalled the DSA cert. How long do you need to test it?

Marko, maybe you could configure the DSA cert on a different port on that host, so that it's still possible to test this specific case? (Note that it will take some time for this fix to show up in Firefox, as mozilla-central will have to pick up a newer NSS tag with this patch applied.)
Do you know what SSL implementation is used in this server?
Is it possible to fix the server side's SSL bug?
(In reply to comment #23)
> Do you know what SSL implementation is used in this server?
> Is it possible to fix the server side's SSL bug?

The SunJSSE provider, I would assume (Marko is running Tomcat with the Sun JRE).

http://java.sun.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
You need to log in before you can comment on or make changes to this bug.