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)
NSS
Libraries
Tracking
(Not tracked)
RESOLVED
FIXED
3.12.3
People
(Reporter: lothar.haeger, Assigned: nelson)
References
()
Details
Attachments
(1 file)
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
Comment 1•15 years ago
|
||
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
Comment 2•15 years ago
|
||
Regression range is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1205662680&maxdate=1205677199
Reporter | ||
Comment 3•15 years ago
|
||
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
Comment 4•15 years ago
|
||
(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.
Comment 6•15 years ago
|
||
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?
Comment 8•15 years ago
|
||
JRE 1.6.0u5
Comment 9•15 years ago
|
||
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.
Comment 10•15 years ago
|
||
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)?
Assignee | ||
Comment 11•15 years ago
|
||
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.
Assignee | ||
Comment 12•15 years ago
|
||
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
Comment 13•15 years ago
|
||
@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.
Comment 14•15 years ago
|
||
(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?
Comment 15•15 years ago
|
||
(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?
Assignee | ||
Comment 16•15 years ago
|
||
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?
Assignee | ||
Comment 17•15 years ago
|
||
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.
Assignee | ||
Comment 18•15 years ago
|
||
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
Assignee | ||
Updated•15 years ago
|
Priority: -- → P3
Assignee | ||
Comment 19•15 years ago
|
||
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 20•15 years ago
|
||
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+
Assignee | ||
Comment 21•15 years ago
|
||
Checking in ssl3con.c; new revision: 1.115; previous revision: 1.114
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 22•15 years ago
|
||
(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.)
Comment 23•15 years ago
|
||
Do you know what SSL implementation is used in this server? Is it possible to fix the server side's SSL bug?
Comment 24•15 years ago
|
||
(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.
Description
•