Hi Brian,
I'm developing a Government Website that should be available to any of the main 
browsers, but our site certificate is not being recognized by Firefox since 
version 28 (it's OK for IE, Chrome and FF before v.28). To be able to recognize 
the certificate, our users have to manually import the certificates of all CA's 
in the chain.

The site is https://homologacao.nfce.fazenda.sp.gov.br 

Our certificate was issued by brazilian CA "ICP-Brasil" .

If you log with IE or Chrome you'll be able to download the certificate and 
check the CA chain.

I think that if the chain could be added to the list of certificates it would 
solve the problem. We have another website that is certified by Verisign and it 
works normally 
(https://nfe.fazenda.sp.gov.br/ConsultaNFe/consulta/publica/ConsultarNFe.aspx)

Could you please help? I'd like to open a proper change request but I don't 
know how to do that.

Thanks in advance,
Fabio



Em sexta-feira, 13 de dezembro de 2013 05h48min34s UTC-2, Brian Smith  escreveu:
> Previously, Firefox would try to use OCSP to check revocation of an EV
> 
> certificate, and then fall back to CRLs if there was no OCSP URI in the AIA
> 
> extension or if the OCSP fetch failed. In Firefox 28 and later, Firefox
> 
> will stop trying to use CRLs. See bug 585122 [1] which is fixed in Firefox
> 
> 28. Firefox 28 will be released 2014-03-18.
> 
> 
> 
> Because Firefox does not fall back from a failed OCSP request to a CRL
> 
> request, an unreliable OCSP responder will now be more likely to result in
> 
> an EV certificate being displayed as a non-EV certificate. Websites can
> 
> avoid this issue, mostly, by supporting OCSP stapling. (I say "mostly"
> 
> because it is still an issue for the intermediate certificate). For this
> 
> reason, I highly recommend that all EV sites enable OCSP stapling.
> 
> 
> 
> Another consequence of this is that certificates that are missing the OCSP
> 
> URI in the AIA extension, but which are otherwise valid EV certificates,
> 
> will no longer be displayed as EV certificates. Previous versions of
> 
> Firefox (27 and before) would display these certificates as EV certificates
> 
> if revocation checking via CRL succeeded.
> 
> 
> 
> If a website has a certificate without an OCSP AIA URL, but which is
> 
> otherwise a valid EV certificate, then the website administrator can get
> 
> the EV indicator back by either replacing the certificate with one that
> 
> does include an OCSP URI, or by manually configuring OCSP on the server to
> 
> use a fixed OCSP URI. In Apache, the option for setting the OCSP responder
> 
> URI is SSLStaplingForceURL [2]. I recommend you only use
> 
> SSLStaplingForceURL if your certificate does not contain an OCSP URI in the
> 
> AIA extension.
> 
> 
> 
> If the certificate chain that the CA provided is missing the OCSP URI in
> 
> the intermediates' AIA extension(s), then the certificate chain will need
> 
> to be replaced with one where all the necessary intermediates have the OCSP
> 
> URI in the AIA extension, in order for the EV indicator to be displayed in
> 
> Firefox.
> 
> 
> 
> For most users, this change marks the end of CRL support in Firefox (at
> 
> least in Firefox's default configuration), and we can act as though CRLs no
> 
> longer exist. (CRLs can still be imported into Firefox's certificate
> 
> database manually with command line tools, for now. However, people should
> 
> not expect Firefox to notice CRLs in the CRL database in Firefox 29 or
> 
> later.) Note that Firefox has never supported CRL fetching for non-EV
> 
> certificates.
> 
> 
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=585122
> 
> [2] http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstaplingforceurl
> 
> 
> 
> Cheers,
> 
> Brian
> 
> -- 
> 
> Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to