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
•