Closed
Bug 376480
Opened 18 years ago
Closed 17 years ago
FF doesn't connect, popup with errorcode -8048 appears
Categories
(Core :: Security: PSM, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: bernhard.lascy, Assigned: KaiE)
References
()
Details
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•18 years ago
|
||
Please try it again with disabled OSCP
Assignee: nobody → kengert
Component: General → Security: PSM
Product: Firefox → Core
QA Contact: general
Updated•18 years ago
|
Summary: FF doe'nt connect, popup with errorcode -8048 appears → FF doesn't connect, popup with errorcode -8048 appears
Reporter | ||
Comment 2•18 years ago
|
||
Hi Matthias, That works! Thanks for the hint. Is this a bug of Firefox or a bug of the web site? sincerely yours Bernhard
Reporter | ||
Comment 3•18 years ago
|
||
(In reply to comment #1) > Please try it again with disabled OSCP > Thanks for help.
Comment 4•18 years ago
|
||
The error code means afaik that the OSCP certificate of the website is invalid
Reporter | ||
Comment 5•18 years ago
|
||
The OSCP-Service of the trust-center seems to have a bug
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Updated•18 years ago
|
Resolution: FIXED → INVALID
Reporter | ||
Comment 6•17 years ago
|
||
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
Assignee | ||
Comment 7•17 years ago
|
||
https://labs.cio.gv.at/SimpleSeLaTest gives me Not Found The requested URL /SimpleSeLaTest was not found on this server.
Assignee | ||
Comment 8•17 years ago
|
||
Is the CA certificate that issued the cert used by https://www.cio.gv.at/ available for download?
Reporter | ||
Comment 10•17 years ago
|
||
Hello Kai, here is the CA-certificate. http://www.a-trust.at/info.asp?ch=2&lang=GE&node=659 =;-) Bernhard
Reporter | ||
Comment 11•17 years ago
|
||
Hello Kai, do you have any news about the problem? best regards Bernhard
Assignee | ||
Comment 12•17 years ago
|
||
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
Reporter | ||
Comment 13•17 years ago
|
||
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•17 years ago
|
||
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
Assignee | ||
Comment 15•17 years ago
|
||
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).
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Comment 16•17 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago → 17 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•