Bug #2233

Certificate Manager CSR validator decreases key length on error

Added by Bruce Mah about 2 years ago. Updated about 2 years ago.

Status:Resolved Start date:02/23/2012
Priority:Normal Due date:
Assignee:- % Done:

100%

Category:Certificates
Target version:-
Affected version:2.1 Affected Architecture:

Description

Observed on the 16 February 2012 snapshot, i386 nanobsd version, running on a Soekris net4801.

Go to System -> Cert Manager -> Certificates.

Set Method: Create a Certificate Signing Request.

Notice the default Key Length is 2048 bits.

Now create a CSR that is invalid. A quick 'n' easy way to do this is to immediately click "Save".

Now notice that the Key Length has decreased to 512 bits for no apparent reason.

I tried something similar to create an internal CA and I didn't see this bug; in other words, the Key Length correctly remained at 2048 bits even after my inputs were rejected.

Associated revisions

Revision c04237e9
Added by Erik Fonnesbeck about 2 years ago

Carry over the key length on input errors when creating a certificate signing request. Ticket #2233

Revision b805ef90
Added by Erik Fonnesbeck about 2 years ago

Carry over the key length on input errors when creating a certificate signing request. Fixes #2233

History

#1 Updated by Erik Fonnesbeck about 2 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#2 Updated by Bruce Mah about 2 years ago

Thanks for the quick fix! I'll be happy to test that in the next snapshot and report back.

Not being familiar with the bug-fixing workflow for this project, is there anything else that I as a user should be doing at this point?

#3 Updated by Chris Buechler about 2 years ago

Our general workflow is after a fix is committed, the ticket goes to Feedback, and once either the submitter or another committer, or someone we know has a high degree of clue verifies, it goes to Resolved.

You're on nanobsd so I don't think you'll be able to gitsync, but FYI you can sync from git between snapshots.
http://doc.pfsense.org/index.php/Updating_pfSense_code_between_snapshots

or just manually scp the changed file(s) over, test that, and confirm. Since we don't have a snapshot builder going regularly yet, it may be a few days before a new build is up.

#4 Updated by Bruce Mah about 2 years ago

I have tested this functionality on a 28 February snapshot and it is now behaving as expected (that is, the key length is correctly preserved when inputs to a CSR fail validation). Thanks for the fix!

#5 Updated by Jim P about 2 years ago

  • Status changed from Feedback to Resolved

You're welcome - thanks for the feedback :-)

Also available in: Atom PDF