Closed
Bug 494489
Opened 16 years ago
Closed 16 years ago
CERT_PKIXVerifyCert doesn't use the temporary root CA certificate trusted by CERT_ChangeCertTrust
Categories
(NSS :: Libraries, defect, P1)
Tracking
(Not tracked)
RESOLVED
INVALID
3.12.4
People
(Reporter: wtc, Assigned: alvolkov.bgs)
Details
(Whiteboard: PKIX MOZ)
NSS version: system NSS (3.12.0.3) in Ubuntu 8.04.
Chromium's unit tests use certificates issued by a test root CA.
The unit tests import the test root CA certificate as a temporary
certificate and trust it as follows:
static CERTCertificate* LoadTemporaryCert(const FilePath& filename) {
base::EnsureNSSInit();
std::string rawcert;
if (!file_util::ReadFileToString(filename.ToWStringHack(), &rawcert)) {
LOG(ERROR) << "Can't load certificate " << filename.ToWStringHack();
return NULL;
}
CERTCertificate *cert;
cert = CERT_DecodeCertFromPackage(const_cast<char *>(rawcert.c_str()),
rawcert.length());
if (!cert) {
LOG(ERROR) << "Can't convert certificate " << filename.ToWStringHack();
return NULL;
}
// TODO(port): remove this const_cast after NSS 3.12.3 is released
CERTCertTrust trust;
int rv = CERT_DecodeTrustString(&trust, const_cast<char *>("TCu,Cu,Tu"));
if (rv != SECSuccess) {
LOG(ERROR) << "Can't decode trust string";
CERT_DestroyCertificate(cert);
return NULL;
}
rv = CERT_ChangeCertTrust(CERT_GetDefaultCertDB(), cert, &trust);
if (rv != SECSuccess) {
LOG(ERROR) << "Can't change trust for certificate "
<< filename.ToWStringHack();
CERT_DestroyCertificate(cert);
return NULL;
}
return cert;
}
This stops working after Chromium switches from CERT_VerifyCertNow
to CERT_PKIXVerifyCert.
Moreover, CERT_PKIXVerifyCert seems to report different errors
depending on what is specified as cert_pi_trustAnchors. (I still
need to confirm this with the Linux Chromium developer who reported
this to me.)
1. If cert_pi_trustAnchors is omitted, CERT_PKIXVerifyCert reports
the SEC_ERROR_UNTRUSTED_ISSUER (-8172) error.
2. If the value of cert_pi_trustAnchors is
PK11_ListCerts(PK11CertListCA, NULL), CERT_PKIXVerifyCert reports
the SEC_ERROR_UNTRUSTED_CERT error. Note: Since SEC_ERROR_UNTRUSTED_CERT
looks very similar to SEC_ERROR_UNTRUSTED_ISSUER and the Linux
Chromium developer didn't include the numeric error code, it could
be a typo. But my code inspection shows this could be true:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/libpkix/include/pkix_errorstrings.h&rev=1.31&mark=199#199
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/libpkix/pkix/top/pkix_build.c&rev=1.57&mark=883-893#851
Comment 1•16 years ago
|
||
Wan-Teh,
When you specify cert_pi_trustanchors, that disables all reliance on
trust flags. When you explicitly specify trust anchors, then only the
trust anchors you specify are trusted, and the ordinary trust flags are
ignored. This is by design.
| Reporter | ||
Comment 2•16 years ago
|
||
I already told him to try omitting cert_pi_trustAnchors.
If cert_pi_trustAnchors is omitted, CERT_PKIXVerifyCert reports
the SEC_ERROR_UNTRUSTED_ISSUER (-8172) error.
Comment 3•16 years ago
|
||
Setting to P1, at least until problem analysis is complete.
Priority: -- → P1
Target Milestone: --- → 3.12.4
Updated•16 years ago
|
Whiteboard: PKIX MOZ
| Reporter | ||
Comment 4•16 years ago
|
||
The Linux Chromium developer told me he performed some
experiments incorrectly, so this bug report is invalid.
Sorry about the confusion.
He repeated the experiments and sent me these results:
1. If he uses PK11_ListCerts(PK11CertLicaCA, NULL) for
cert_pi_trustAnchors, he gets SEC_ERROR_UNTRUSTED_ISSUER
(-8172) for certs issued by Chromium's test root CA,
whose cert is imported as a temporary cert and trusted
with a CERT_ChangeCertTrust call. Note: previously he
incorrectly reported that he got SEC_ERROR_UNTRUSTED_CERT.
2. If he uses NULL for cert_pi_trustAnchors, the test program
dies by segfault (bug 494087).
3. If he uses CERT_NewCertList() (i.e., an empty CERTCertList)
for cert_pi_trustAnchors, the test program passes.
4. If he omits cert_pi_trustAnchors, the test program passes.
So the only remaining work is to fix or document the crash
of case 2, and review case 3 (whether an empty trust anchor
list should be interpreted as zero trust anchors or default
trust anchors). Also we should clarify that "default trusted
roots" include not only the root CA certs in libnssckbi.so
but also any other root CA certs trusted by the user:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certdb/certt.h&rev=1.51&mark=944#942
i.e., "default" != "built-in"
We can do this work in bug 494087.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
Comment 5•16 years ago
|
||
(In reply to comment #4)
> 1. If he uses PK11_ListCerts(PK11CertLicaCA, NULL) for
> cert_pi_trustAnchors, he gets SEC_ERROR_UNTRUSTED_ISSUER
> (-8172) for certs issued by Chromium's test root CA,
> whose cert is imported as a temporary cert and trusted
> with a CERT_ChangeCertTrust call.
Wan-Teh, I presume you meant PK11_ListCerts(PK11CertListCA, NULL).
I presume that he expected that call to return temporary trusted certs as
well as those stored in PKCS#11 tokens. Of course, that function only
returns certs that are stored in PKCS#11 tokens. Perhaps he expected that
"temporary" certs are stored as "session objects" in NSS's softoken. That's not an entirely unreasonable assumption, although it happens to be false.
I wonder if we should consider doing that, storing temp certs as session objects in softoken. Bob, what do you think?
| Reporter | ||
Comment 6•16 years ago
|
||
Yes, I mean PK11_ListCerts(PK11CertListCA, NULL). Sorry about the
typo.
Please don't interpret too much of his attempt to use
PK11_ListCerts(PK11CertListCA, NULL). I don't know how he
discovered PK11_ListCerts(PK11CertListCA, NULL), but it's
most likely after he got a crash from setting cert_pi_trustAnchors
to NULL ((bug 494087). So I were to guess his expectation,
I'd say his expectation is that setting cert_pi_trustAnchors to
NULL should work as documented.
You need to log in
before you can comment on or make changes to this bug.
Description
•