Closed Bug 1202636 Opened 6 years ago Closed 6 years ago

importing valid certificates in the "server" tab of the certificate manager can cause certificate verification failures

Categories

(Core :: Security: PSM, defect)

38 Branch
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: Ikonta, Unassigned)

References

Details

Attachments

(3 files)

3.64 KB, application/pkix-cert
Details
9.18 KB, application/pkix-cert
Details
3.56 KB, application/x-pkcs12
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150907101051

Steps to reproduce:

Using not only server, but client certs in complete model (i.e. including Certificate Revocation List) I have to use custom certification chain (started with CA certificate).
Last server certs are generated with amd64 built OpenSSL 1.0.2d.
The CA certificate was imported previously (in 31 ESR or even 24 ESR).
Initial request to https://host.domain.tld succeed. Opened from address bar certificate view is correct (server).
But if I import server's certificate into www-client/firefox-38.2.1 browser profile.


Actual results:

I fail to open a page with «sec_error_untrusted_cert» error.
Certificate viewer, started from browser's profile shows the same state (certificate verification failed).

The same certificate verification error is displayed for imported client certs.
But in this case request is authenticated by server, so issue don't breaks operability.
Verification of client certs, imported in previous version (31 ESR), succeed.


Expected results:

I expect request being procceeded in the both cases: when I've imported only CA certificate and when I've imported both CA and server's certificates.
And operable verification of imported client certs.
Component: Untriaged → Security: PSM
Product: Firefox → Core
See Also: → 1140332
One more notable detail:
In OpenSSL 1.0.2d I've seen  yet incompletebly documentated warning about deprecation of nsCertType attribute.

man x509v3_config:

   Netscape Certificate Type
       This is a multi-valued extensions which consists of a list of flags to be included. It was used to indicate the purposes
       for which a certificate could be used. The basicConstraints, keyUsage and extended key usage extensions are now used
       instead.

       Acceptable values for nsCertType are: client, server, email, objsign, reserved, sslCA, emailCA, objCA.


This issue was reproduced both with old-style (nsCertType used) and new-style (nsCertType not set, extendedKeyUsage=clientAuth or extendedKeyUsage=serverAuth set) certificates.
Can you attach the certificates you're using to this bug? (Just the public parts.) It's the fastest way to figure out what the issue is.
Flags: needinfo?(Ikonta)
Attached file ca.crt
CA for example chain.
Generated with recent version of OpenSSL (1.0.2d) with upstream, no PKIX default.
openssl-ca.cnf:
# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true
Flags: needinfo?(Ikonta)
Attached file web.example.crt
Previously attached CA was trusted to verify web servers.
It's type is identified correctly.

Now attaching example server's certificate.
For wich (please note: when imported into FF's profile) I see the following error:
Could not verify this certificate because it is not trusted.

One more notable detail: when I've checked previously generated old-style (setting cert usage via nsCertType attribute, I can't restore the openssl's version used), I've failed to reproduce subj. issue.
My FF is built with recent (1.0.2d) version of OpenSSL.
Flags: needinfo?(dkeeler)
To use a certificate as a client certificate, it needs to have the id-kp-clientAuth ("TLS WWW client authentication") extended key usage. It looks like that certificate only has the id-kp-serverAuth extended key usage.
Flags: needinfo?(dkeeler)
Attached file user1.pfx
(In reply to David Keeler [:keeler] (use needinfo?) from comment #5)
> To use a certificate as a client certificate, it needs to have the
> id-kp-clientAuth ("TLS WWW client authentication") extended key usage.

Or to generate certificate without setting extendedKeyUsage attribute.

> It looks like that certificate only has the id-kp-serverAuth
> extended key usage.

Of course.
It is the _server's_ certificate.
The bug's subject is in that FireFox failes to validate imported certificates, even with OpenSSL's default (not PKIX recommendation).
For CA certificates validation isn't expected, so their status is displayed correctly.
But all others (i.e. both client and server) failes to validate.
So server's certificate is enough to illustrate bug.

Attaching example client certificate hoping it will help you to analyze issue.
Certificate's PIN (import passphrase) — 0000
If I import the CA that issued that client certificate, trust it to identify mail users, and then import the client certificate, the certificate viewer says it is a valid client certificate.

The server case is a bit more complicated. That tab of the certificate manager is meant for certificate verification error overrides. That is, if a certificate is in that list, it's not expected to validate correctly. The UX/messaging isn't as clear as it could be, but there you go. If you import your CA, trust it to identify web sites, and then visit a website using the web server certificate (without importing it in the error override UI), it should work as expected.
(In reply to David Keeler [:keeler] (use needinfo?) from comment #7)
> If I import the CA that issued that client certificate, trust it to identify
> mail users, and then import the client certificate, the certificate viewer
> says it is a valid client certificate.

Thank you.
It workd.

But I find a little bit strange and unclear making trust CA for _email_ for correct classification of _web_ client certificate, which due to extendedKeyUsage restrictions should not be useable for email.

> The server case is a bit more complicated. That tab of the certificate
> manager is meant for certificate verification error overrides. That is, if a
> certificate is in that list, it's not expected to validate correctly. The
> UX/messaging isn't as clear as it could be, but there you go. If you import
> your CA, trust it to identify web sites, and then visit a website using the
> web server certificate (without importing it in the error override UI), it
> should work as expected.

Yes, it server's certificate is not imported, everything works.
Why not to make an exception for server's certificate, which validates?
Because if user for thirst time added an exception (imported server's certificate) and after that makes right (importing CA) he will wonder getting error and may want to roll-back right solution, that isn't a good idea.

P.S. Is this bug confirmed?
For posterity, I think the issue is that importing a certificate in the "server" tab of the certificate manager sets the terminal record bit in the trust database, so when the certificate verifier calls GetCertTrust for that certificate, it determines that it is untrusted.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: FireFox-38.2.1 broken verification in user's certification chain → importing valid certificates in the "server" tab of the certificate manager can cause certificate verification failures
The changes in Bug 1064402 mean that it is no longer possible to import certs into the Server tab of the cert manager.
=> Resolving as INVALID for now.
Status: NEW → RESOLVED
Closed: 6 years ago
Depends on: 1064402
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.