376480 - FF doesn't connect, popup with errorcode -8048 appears

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Bernhard Lassy]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Hi there,
I tried to use austrian government applications, but firefox does not open the link which should test the interface with a card reader. I don't want to use IExplorer, but with IExplorer that works. The service-provider said that they tested with IE, FF ... and that worked fine.

sincerely yours
Bernhard Lassy

Reproducible: Always

Steps to Reproduce:
1.open above link

Actual Results:  
FF pops the failure "Fehler beim Aufbau einer Verbindung zu labs.cio.gv.at Fehlercode: -8048"


Expected Results:  
page should be open with links for testing the card reader with security certificates.

Comment 1

[Matthias Versen [:Matti]]

Please try it again with disabled OSCP

Comment 2

[Bernhard Lassy]

Hi Matthias,
That works! Thanks for the hint. Is this a bug of Firefox or a bug of the web site?

sincerely yours
Bernhard

Comment 3

[Bernhard Lassy]

(In reply to comment #1)
> Please try it again with disabled OSCP
> Thanks for help.

Comment 4

[Matthias Versen [:Matti]]

The error code means afaik that the OSCP certificate of the website is invalid

Comment 5

[Bernhard Lassy]

The OSCP-Service of the trust-center seems to have a bug

Comment 6

[Bernhard Lassy]

Hello all together,
firefox seems to have a problem with checking OCSP-Responds from some sites.

http://labs.cio.gv.at is one of them. The OCSP-Responder of A-Trust (issuer of certificate) works. For example Acrobat can check electronic signatures with certificates from A-Trust. As far as I heared from A-Trust there are 3 possibilities to implement OCSP, das firefox support all of them?

sincerely yours
=:-) Bernhard

Comment 7

[Kai Engert (:KaiE:)]

https://labs.cio.gv.at/SimpleSeLaTest
gives me 
Not Found
The requested URL /SimpleSeLaTest was not found on this server.

Comment 8

[Kai Engert (:KaiE:)]

Is the CA certificate that issued the cert used by https://www.cio.gv.at/ available for download?

Comment 9

[Bernhard Lassy]

Hello Kai,
I have to check that.

Bernhard

Comment 10

[Bernhard Lassy]

Hello Kai,
here is the CA-certificate.

http://www.a-trust.at/info.asp?ch=2&lang=GE&node=659

=;-) Bernhard

Comment 11

[Bernhard Lassy]

Hello Kai,
do you have any news about the problem?

best regards
Bernhard

Comment 12

[Kai Engert (:KaiE:)]

Sorry, but your servers are not configured correctly.

For example, when connecting to https://www.cio.gv.at/ the server does not provide the intermediate certificate. It was not sufficient to import the root, I was required to import the intermediate cert, too. This is bad.

With OCSP enabled I get
An error occurred during a connection to www.cio.gv.at.
Invalid OCSP signing certificate in OCSP response. (sec_error_ocsp_invalid_signing_cert)

I suspected you are using an OCSP responder certificate that does not follow the specifications.

Debugging the connection, the OCSP response is signed using a cert with this common name:
serialNumber=896929130327,givenName=OCSP,SN=Responder 03,CN=OCSP Responder 03,C=AT
issued by:
CN=a-sign-corporate-light-03,OU=a-sign-corporate-light-03,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT


It was necessary to explicitly import that intermediate cert, too (you really should fix your servers to send out the server cert together with any required intermediates).

This brought me to:
An error occurred during a connection to www.cio.gv.at.
The signer of the OCSP response is not authorized to give status for this certificate. (sec_error_ocsp_unauthorized_response)

Your OCSP signer cert fails on all tests in ocsp_AuthorizedResponderForCertID, which has the following comment:

/*
 * Check that the given signer certificate is authorized to sign status
 * information for the given certID.  Return true if it is, false if not
 * (or if there is any error along the way).  If false is returned because
 * the signer is not authorized, the following error will be set:
 *	SEC_ERROR_OCSP_UNAUTHORIZED_RESPONSE
 * Other errors are low-level problems (no memory, bad database, etc.).
 *
 * There are three ways to be authorized.  In the order in which we check,
 * using the terms used in the OCSP spec, the signer must be one of:
 *  1.  A "trusted responder" -- it matches a local configuration
 *      of OCSP signing authority for the certificate in question.
 *  2.  The CA who issued the certificate in question.
 *  3.  A "CA designated responder", aka an "authorized responder" -- it
 *      must be represented by a special cert issued by the CA who issued
 *      the certificate in question.
 */

In particular, your response signer is neither the direct issuer of the server cert, nor does it carry the SEC_OID_OCSP_RESPONDER

Comment 13

[Bernhard Lassy]

Hallo Kai,
thanks for your detailed analysis. The servers are not my servers, these are servers from the austrian government. I hate to use IExplorer and I could not use firefox at these sites. A-Trust, the provider of the certificates, says they are doing the right things, but your analysis says that there is something wrong.

Thank you for your support.

=;-) Bernhard

Comment 14

[Ramin Sabet]

Hello,

thanks for the information so far, our (we implemented the OCSP Service mentioned above) OCSP-Responder would meet your case 1, since it is not issued by the CA.

We verified this by using different validations eg. OpenSSL ocsp ....
All work fine, and i am quite sure, when we implemented OCSP we verified that the Mozilla version available at that time also accepted our OCSP requests.

Concerning the extension SEC_OID_OCSP_RESPONDER, as far as we understand RFC 2560 the only extension neccessary is

 491 A3  430:     [3] {
 495 30  426:       SEQUENCE {
 499 30   19:         SEQUENCE {
 501 06    3:           OBJECT IDENTIFIER '2 5 29 37'
 506 04   12:           OCTET STRING, encapsulates {
 508 30   10:               SEQUENCE {
 510 06    8:                 OBJECT IDENTIFIER '1 3 6 1 5 5 7 3 9'
            :                 }
            :               }

which we included. We couldn't find the OID of SEC_OID_OCSP_RESPONDER or is it the same ?

You can find the DER encoded OCSP signer here: http://www.a-trust.at/certs/atrust_OCSP_Responder_03.crt

So do we need to add another extended key usage which is not mentioned in the RFC ? 

regards,
   Ramin

Comment 15

[Kai Engert (:KaiE:)]

Julien, Nelson,

are you able to answer the question in comment 14 (which is based on my analysis from comment 12, which was based on NSS' current OCSP implementation).

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

Kai, You analysis was correct.  IMO, there are numerous RFCs being violated
in this example.  The TLS server is not sending a complete cert chain,
and it appears to me that the OCSP responder is not using a certificate 
issued by the issuer of the TLS server's cert.  

RFC 2246 (TLS 1.0) requires the server to send a cert chain, starting with
the server cert, with all the issuers certs up to, but optionally omitting,
the root or "trust anchor" CA cert.  The existence of AIA cert extensions
in the server cert, by which it may be possible to fetch issuer certs, 
does not relieve the TLS server of its obligation to send a complete cert
chain (minus the root).  See RFC 2246, section 7.4.2, page 39, in the 
definition of certificate_list.

RFC 2560 (OCSP), section 4.2.2, page 10, reads as follows:

4.2.2.2  Authorized Responders

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. It is necessary however to
   ensure that the entity signing this information is authorized to do
   so.  Therefore, a certificate's issuer MUST either sign the OCSP
   responses itself or it MUST explicitly designate this authority to
   another entity.  OCSP signing delegation SHALL be designated by the
   inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
   extension included in the OCSP response signer's certificate.  This
   certificate MUST be issued directly by the CA that issued the
   certificate in question.

   id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

   Systems or applications that rely on OCSP responses MUST be capable
   of detecting and enforcing use of the id-ad-ocspSigning value as
   described above. They MAY provide a means of locally configuring one
   or more OCSP signing authorities, and specifying the set of CAs for
   which each signing authority is trusted. They MUST reject the
   response if the certificate required to validate the signature on the
   response fails to meet at least one of the following criteria:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

NSS follows that to the letter.  The OCSP responder cert given in the 
URL cited in comment 14 does have the id-ad-ocspSigning OID in the 
ExtendedKeyUsage extension, but it is not issued by the issuer of the 
TLS server's certificate.  Note that the RFC quoted above REQUIRES 
relying applications to enforce these rules.

As you know, mozilla/firefox browser users can configure their browsers to 
use a user-specified OCSP responder for ALL OCSP requests.  That fulfills
criterion 1 above.  I suspect that if the browser user configures his browser
to always use the server http://ocsp.a-trust.at/ocsp for OCSP responses, 
then the browser will be satisifed with the OCSP responses from that 
responder.  But of course, general web browser users on the Internet should
NEVER have to configure their browsers in this way.  This sort of special
configuration is intended to be used only in closed intranet environments.
Public CAs serving the Internet should ensure that their OCSP responders'
certificates satisfy the second or third criteria from RFC 2560.  It may
be necessary for the OCSP repsonder to have more than one signature cert,
one for each of the CAs that have designated it as their authorized OCSP
responder.  

Certain other products may not enforce the rules.  The fact that an OCSP
repsonder works with a product that does not enforce the rules is not an
indication that the responder is working correctly in conformance to the 
relevant standards.  

I concur with the original resolution.  This bug is invalid.