92923 - Support OCSP checks via https in Mozilla clients

Status: RESOLVED WONTFIX

(Core :: Security: PSM, enhancement, P3)

Description

[Joerg Bruenner]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010628
BuildID:    2001062815

Prerequisitions:
- the X.509 server certificate contains a authority information access 
  field (OID 1.3.6.1.5.5.7.1.1) containing "https://ocsp.local.com"
- the browser is ordered to check certificates via OCSP (both options 
  showed the same bug)
- all the certificates were issued by my local CA
- certificates with an AIA containing "http://ocsp.local.com" worked 
  fine
The test case:
I made a https connection to server.local.com (situated in local 
network) and expected the browser to check the certificate via my 
local OCSP responder (ocsp.local.com). 
The bug:
The browser closed the connection to the server server.local.com 
directly after reciving the server certificate. The reason code was:
"bad certificate". It seems the check within the browser does not like 
the "https" in the AIA field.
There was no message to the user. The error message laid in the 
ssl-error log of the webserver. The OCSP request was not started. The 
page was not delivered.
The same webserver delivered the page without OCSP checking activated. 
The certificate was still the same. Here the browser seems not to 
check the content of the AIA field.


Reproducible: Always
Steps to Reproduce:
1. set up a webserver with a dummy page, activate SSL, give the server
   certificate an AIA containing OCSP, URI: https://ocsp-responder
2. set u an OCSP responder
3. import the root CA-Certificate into the browser (You should 
   redesign this procedure!!!)
4. activate OCSP check in the browser


Actual Results:  nothing, the page is not delivered the error log of the
webserver told me what's wrong (see long description)


Expected Results:  the page, after an succsessful OCSP request (OCSP response: Good)

Feel free to contact me. I can provide the certificates an keys used.

Comment 1

[John Unruh]

PSM

Comment 2

[Stephane Saux]

->javi
P1

Comment 3

[John Unruh]

Mass assigning QA to ckritzer.

Comment 4

[Stephane Saux]

changing to a RFE.
->future
P3

Comment 5

[John Unruh]

OS > all

Comment 6

[Samir Gehani]

adt: nsbeta1-

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Mass reassign Javi's old PSM bugs to nobody

Comment 8

[jim]

I think this bug is affecting at least one real site which uses Verisign: 
 
https://viewmyaccounts.moneysupermarket.com 
 
I can access this site in Konqueror and IE, but not Mozilla or Firefox. 
 
Always reproducible: set OCSP to "Use OCSP to validate certificates that 
specify an OCSP service URL", then visit the above URL. 

Comment 9

[Ralf Hauser]

it appears that situation is even worse. Currently, if a cert has a https ocsp URL and OCSP is on, it cannot be imported anymore - see Bugzilla Bug 331336

also, isn't Bug 205436 a duplicate of this?

Comment 10

[Kai Engert (:KaiE:)]

The site reported in comment 8 seems to be down.
Yes, this is a duplicate.


*** This bug has been marked as a duplicate of 205436 ***

Comment 11

[Kai Engert (:KaiE:)]

Actually I take that back, the bugs are not necessarily duplicates.

Bug 205436 is about supporting OCSP to https *within* NSS.
NSS has an internal http client, and might choose to enhance that to support https.

Independent of what NSS does internally, NSS now offers a http client delegation mechanism, and with bug 111384 we made use of that feature in PSM / the Mozilla clients.

So I propose this bug should track to enhance PSM to allow https.

In order to make this work in PSM, we need to extend the new code added in bug 111384 to use more than one SSL thread.

Comment 12

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Connecting to an https site while verifying a certificate means we attempt to verify another certificate, which could cause us to connect to an https site, and so on and so forth. This is a problematic and unnecessary practice that we won't be supporting.