Open
Bug 1319000
Opened 8 years ago
Updated 2 years ago
Cache of database is broken in the case of same subjects and different nickname.
Categories
(NSS :: Libraries, defect, P3)
Tracking
(Not tracked)
UNCONFIRMED
People
(Reporter: fryasu, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
1.14 KB,
text/x-csrc
|
Details | |
9.57 KB,
patch
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 Build ID: 20161031141208 Steps to reproduce: When the two certificates which has same subject and different issuer are imported with different nickname, results of PK11_FindCertFromNickname() differ between the first time and the second time. STEP1. creating two CAs $ openssl genrsa 2048 > pki/ca1/ca.key $ openssl req -new -x509 -key pki/ca1/ca.key -out pki/ca1/ca.crt -days 365 -subj "/CN=CA1" $ openssl genrsa 2048 > pki/ca2/ca.key $ openssl req -new -x509 -key pki/ca2/ca.key -out pki/ca2/ca.crt -days 365 -subj "/CN=CA2" STEP2. creating two certificates with same subject with each CAs. $ openssl genrsa 2048 > pki/server1.key $ openssl req -subj "/CN=server" -new -key pki/server1.key > pki/server1.csr $ openssl ca -days 3650 -subj "/CN=server" -keyfile pki/ca1/ca.key -cert pki/ca1/ca.crt -in pki/server1.csr -batch > pki/server1.crt $ openssl x509 -in pki/server1.crt -noout -text |grep -e Subject: -e Issuer: Issuer: CN=CA1 Subject: CN=server $ openssl genrsa 2048 > pki/server2.key $ openssl req -subj "/CN=server" -new -key pki/server2.key > pki/server2.csr $ openssl ca -days 3650 -subj "/CN=server" -keyfile pki/ca2/ca.key -cert pki/ca2/ca.crt -in pki/server2.csr -batch > pki/server2.crt $ openssl x509 -in pki/server2.crt -noout -text |grep -e Subject: -e Issuer: Issuer: CN=CA2 Subject: CN=server STEP3. Imports each certificate with different nickname. $ certutil -d sql:pki/nss -N --empty-password $ certutil -d sql:pki/nss -E -i pki/server1.crt -n server1 -t u,u,u $ certutil -d sql:pki/nss -E -i pki/server2.crt -n server2 -t u,u,u $ certutil -d sql:pki/nss -L Certificate Nickname Trust Attributes server1 ,, server2 ,, STEP4. Please build the attached test code which is PK11_FindCertFromNickname() loop. $ gcc -Wall -std=gnu99 -Wall nsstest_PK11_FindCertFromNickname.c -o nsstest_PK11_FindCertFromNickname \ -I /usr/include/nss3/ -I /usr/include/nspr4/ -lnss3 -lnspr4 STEP5. Runs the test $ ./nsstest_PK11_FindCertFromNickname sql:pki/nss/ server1 server2 ---- [0] first loop ----- - in: nickname='server1' - out: nickname='server1' (0x...9b0), Subject='CN=server', Issuer='CN=CA1' OK - in: nickname='server2' - out: nickname='server2' (0x...210), Subject='CN=server', Issuer='CN=CA2' OK ---- [1] second loop (after cached) ----- - in: nickname='server1' - out: nickname='server2' (0x...210), Subject='CN=server', Issuer='CN=CA2' *ERR* - in: nickname='server2' - out: nickname='server2' (0x...210), Subject='CN=server', Issuer='CN=CA2' OK We doubt nss/lib/pki/tdcache.c behavior. Actual results: In the first loop, PK11_FindCertFromNickname("server1") returns the "server1" certificate. But in the second loop, PK11_FindCertFromNickname("server1") returns the unexpected "server2" certificate. Expected results: the result of second loop shoud be same with first loop's.
Updated•7 years ago
|
Priority: -- → P3
We could make the small patch, we'll be happy if it will be of any help. About cache handling, the following correction was added. before: share the values among the subject cache and nickname cache. after: make the nickname cache indepent from the subject cache. target: - remove_nickname_entry() - add_nickname_entry() because it's necessary of the reverse resolution from certificate to nickname, also following is corrected. before: from one certificate, acquire the entry of subject cache, and acquires the nickname from this entry. after: acquires the nickname from cache of issuer+serial_no cache. target: - remove_subject_to_cache() - add_subject_to_cache() - remove_issuer_and_serial_entry() - add_issuer_and_serial_entry() best regards,
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•