| Summary: | Generating of certificates without serial-number (-m) causes orphans | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Aleš Mareček <amarecek> | ||||||||||||||
| Component: | nss | Assignee: | Elio Maldonado Batiz <emaldona> | ||||||||||||||
| Status: | CLOSED NOTABUG | QA Contact: | Aleš Mareček <amarecek> | ||||||||||||||
| Severity: | high | Docs Contact: | |||||||||||||||
| Priority: | high | ||||||||||||||||
| Version: | 6.1 | CC: | rrelyea, syeghiay | ||||||||||||||
| Target Milestone: | rc | ||||||||||||||||
| Target Release: | --- | ||||||||||||||||
| Hardware: | All | ||||||||||||||||
| OS: | Linux | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||
| Last Closed: | 2011-10-06 03:01:13 UTC | Type: | --- | ||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||
| Attachments: |
|
||||||||||||||||
Ran the scrip on RHEL-6.2 with updated nss and got Test PASSED There is no orphan in nss database. I was running this [root@rhel62devel emaldona]# rpm -q nss nspr nss-3.12.10-4.el6.x86_64 nspr-4.8.8-3.el6.x86_64 Created attachment 524914 [details]
log file 1 produced by script
Created attachment 524916 [details]
redirection
(In reply to comment #11) Ales, I found out why my run didn't reproduce the orphans. In the system where I was running your script I had in in ~/.bashrc this line export NSS_DEFAULT_DB_TYPE="sql" which forced the tools to use the shared (sqlite based) nss database which doesn't produce orphans. If I run it as export NSS_DEFAULT_DB_TYPE="dbm"; ./cert_gen.sh or via unset NSS_DEFAULT_DB_TYPE; ./cert_gen.sh, then I see the orphans The same behaviour in 6.1 as in 6.2. To answer your prior question, "If there is upstream bugfix do you know what part of code fixes it?" No there is no upstream bug as such and no code code to fix because is not a bug. My search found some bugs and this one is interesting https://bugzilla.mozilla.org/show_bug.cgi?id=291383 and so is this https://bugzilla.mozilla.org/show_bug.cgi?id=291383 which shows that Upon examination of the log file you should see this #certutil: could not obtain certificate from file: You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert." Commercial CA's will always use a unique and increasing serial number. Only toy CAs and experimental tools for testing purposes will issue certs without serial numbers. NSS will allow you to import them but if detects that a collission then you will the error above. I should have analysed this as carefully when it was first reported. This is actually not a bug. Created attachment 525961 [details]
reproducer modified
This modified reproducer allows you to test with shared db or legacy db and allows you to supply serial numbers to certutil or not. It names the log files according the options chosen. The use cases are the following:
1) - shared db with serial numbers:
export NSS_DEFAULT_DB_TYPE="sql"; export USE_SERIAL_NUMBER="yes"; ./cert_gen.sh
should pass
2) - shared db and without serial numbers:
export NSS_DEFAULT_DB_TYPE="sql"; unset USE_SERIAL_NUMBER; ./cert_gen.sh
should pass
3) - legacy db and without serial numbers:
export NSS_DEFAULT_DB_TYPE="dbm"; unset USE_SERIAL_NUMBER; ./cert_gen.sh
should fail
4) - legacy db and with serial numbers:
export NSS_DEFAULT_DB_TYPE="dbm"; export USE_SERIAL_NUMBER="yes"; ./cert_gen.sh
should pass
http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html#1034010 The examples for Creating a Certificate, both the -S and -C examples pass in a serial number via the -m option. Unfortunately, the examples in http://www.mozilla.org/projects/security/pki/nss/ref/ssl/gtstd.html#1012351 didn't do it. Created attachment 526611 [details]
script that uses the noise file
It also creates the database director with a name that reflects the options of using sql vs. dm or using serial number or not. Same with the next attachment.
Created attachment 526612 [details]
script that may prompt you for extra seed
just keep hitting enter as you do something else.
|
Created attachment 482118 [details] reproducer Description of problem: When you generate some certificates in line without giving serial numbers it causes orphans in some cases. Version-Release number of selected component (if applicable): nss-3.12.9-4.el6 nss-3.12.8-1.el5 How reproducible: Should be reproducible in 100% with script Steps to Reproduce: 1. Run the attached script "cert_gen.sh" Actual results: Orphans. Expected results: No orphans. Additional info: I ran the test script many times and I got always some orphans. RHEL5 ===== Test FAILED There are 8 orphans in nss database! real 1m20.016s user 1m14.024s sys 0m42.370s i:ppc64|m:ppc64 root@ibm-js22-vios-01-lp4 [~]# rpm -q nss nss-3.12.8-1.el5 nss-3.12.8-1.el5 ------------------------------------- Test FAILED There are 85 orphans in nss database! real 0m8.279s user 0m7.733s sys 0m1.813s i:x86_64|m:x86_64 root@nec-em16 [~]# rpm -q nss nss-3.12.8-1.el5 nss-3.12.8-1.el5 ===================================== RHEL6 ===== Test FAILED There are 44 orphans in nss database! real 0m30.750s user 0m30.038s sys 0m2.511s i:i386|m:i686 root@tyan-gt24-05 [~]# rpm -q nss nss-3.12.9-4.el6.i686 ------------------------------------- Test FAILED There are 75 orphans in nss database! real 0m16.396s user 0m11.231s sys 0m2.369s i:x86_64|m:x86_64 root@hp-bl260cg5-01 [~]# rpm -q nss nss-3.12.9-4.el6.x86_64