Error code: sec_error_bad_signature persists even after exception added

RESOLVED INCOMPLETE

Status

()

Core
Security: PSM
--
major
RESOLVED INCOMPLETE
10 years ago
2 years ago

People

(Reporter: Mark Zanfardino, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1

While attempting to access a development server with a self-signed certificate created using: 'keytool -genkey -validity 1024' which generates a certificate using the DSA algorithm, FF3 continues to display the Page Load Error page even after creating an exception for the site.  The certificate signature algorithm is: ANSI X9.57 DSA Signature with SHA1 Digest.

Reviewing bug #366157 which suggested that if a site is using a low-grade encryption method which is no longer enabled by default that it can be re-enabled in FF by toggling security.ssl3.rsa_1024_des_cbc_sha to true.  This, however, does not work.

Reissuing a certificate with the RSA algorithm using 'keytool -genkey -validity 1024 -keyalg RSA' on the server seems to resolve the issue.  The certificate signature algorithm is now: PKCS #1 SHA-1 With RSA Encryption

Reproducible: Always

Steps to Reproduce:
1. Navigate to a secured server with a self-signed certificate generated using the DSA algorithm.
2. Add this server to the exceptions list permanently.
3. The server certificate was generated using the following command: keytool -genkey -validity 1024
Actual Results:  
Attempt to navigate to server following exception blocks user at Page Load Error, the only option is to "Try Again".


Expected Results:  
Server web site should be displayed once the exception has been added to the exception list.

When the server was reissued a certificate using the RSA algorithm FF3 would accept the exception and permit the user to continue to the page requested.  The key was reissued using the following command: keytool -genkey -validity 1024

No other special conditions apply.  Tested on multiple workstations of varying hardware operating with Windows XP SP3 and Kubuntu 8.04.1
Assignee: nobody → kaie
Component: Security → Security: PSM
Product: Firefox → Core
QA Contact: firefox → psm

Comment 1

10 years ago
Mark please let's try to simplify the bug description, I think I did not understand it.

Do you say:
- you connect to your site, you get an error page
- you have the option to add an exception
- you add the exception
- you connect again
- now you get a different error page, saying bad_signature

is this correct?

Could you please attach your cert, or even better, are web able to connect to that site for testing?
(Reporter)

Comment 2

10 years ago
Created attachment 337472 [details]
keystore file created with keytool using default (DSA) key encryption
(Reporter)

Comment 3

10 years ago
I'm sorry if I wasn't clear.  To answer the last questions first: I can not make the specific page available to the outside - it's an internal development server.

To restate the sequence of events:
1. Attempt to access page with a self-signed certificate that was created with the default DSA key algorithm (see attached key)
2. FF3 displays warning page indicating self-signed certificate with the link option to create an exception.
3. Created an exception for this web address.
4. FF3 redisplays the self-signed certificate warning page with a button "Try Again".  This time there is not link to create an exception, but there is also no way to bypass this page.  NOTE: this is the standard FF3 self-signed exception warning page.

When I recreate the self-signed certificate using the RSA key algorithm and follow the same sequence of steps, FF3 will redirect to requested page at step 4.  The issue appears to be that creating the exception for a self-signed certificate using the DSA key algorithm is not accepted by FF3.
Attachment #337472 - Attachment mime type: text/plain → application/octet-stream
Created attachment 361839 [details]
extracted cert

I extracted this cert from the previous attachment.
Does this match the cert your server is sending out, exactly?

This cert is a self-signed EE cert with no extensions and no DNS name,
but the DSA signature checks out fine with NSS 3.12.current.

Comment 5

9 years ago
A dupe of bug 441321, possibly? Maybe someone could create a tryserver build with attachment 362072 [details] [diff] [review] applied, so that Mark could test more easily?
OS: Linux → All
Hardware: x86 → All
Very likely a dup of bug 441321, IMO, given that both bugs refer to Java
servers.  If I knew how to make/request a try server build combining NSS
from the CVS trunk and the rest of FF from something recent, I would, but 
I don't really have any idea how to arrange that.

Comment 7

9 years ago
Nelson, more information is available here: https://wiki.mozilla.org/Build:TryServer. Submitting the patch through the Web interface (https://build.mozilla.org/sendchange.cgi) should be sufficient for this case, I presume - you could then have it compile either Firefox 3.0 or trunk.

Comment 8

9 years ago
Mark, would you be able to test?

I started the process to produce a build as proposed in comment 5 and comment 6.
It will be a test build of Firefox 3.1 beta combined with today's latest development snapshot of NSS trunk.

Comment 9

9 years ago
Builds based on Firefox trunk and NSS trunk are available here:

https://build.mozilla.org/tryserver-builds/2009-02-17_07:50-kaie@kuix.de-trunk-nss-452712/

Mark, could you please test against your server and report the results?
Thanks a lot.


(as opposed to my comment 8, it's not a ff 3.1 beta build, because the patch against that branch was not accepted by the tryserver, it stalled, no error page, don't ask me what happened)
(Reporter)

Comment 10

9 years ago
I will test this week. I will post my results following the test.

Comment 11

9 years ago
Thanks Mark.
I'm not sure how long the builds at that site are kept available, but one week should be fine. If you are delayed, please make sure you download early. Thanks.

Comment 12

8 years ago
Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody.
Search for kaie-20100607-unconfirmed-nobody
Assignee: kaie → nobody
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.