X
Thinta lapha ukuze uye kuveshini yamakhalekhukhwini kusayithi.

Isithangami Sabeseki

Lolu chungechunge lwabekwa kunqolobane. Uyacelwa ubuze umbuzo omusha uma udinga usizo.

EV Green Bar not working in latest FF, works in IE and Chrome

Kuphostiwe

I just purchased a new EV certificate from Entrust and installed in on my website. Now with IE and Chrome I get the nice green bar, but FF shows a blue bar and says "which is run by unknown".

I just purchased a new EV certificate from Entrust and installed in on my website. Now with IE and Chrome I get the nice green bar, but FF shows a blue bar and says "which is run by unknown".

Okulungisiwe ngu ARBlue79

Eminye Imininingwane Yohlelo

Isisebenziso

  • I-ejenti Engumsebenzisi: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17

Eminye Imininingwane

andrew.skretvedt 1 izisombululo 8 izimpendulo
Kuphostiwe

Answer: yes. If you turn off OCSP checking, EV indications will stop and you'll just get a grey padlock and no owner info. HOWEVER, the certificates used, if inspected, will be (under normal conditions) the EV certs, and so you're still getting the full measure of authentication from the website you normally get with EV.

It just becomes incumbent on you to inspect the certificate yourself on each occasion to use the site, if you want that assurance.

Anyone with back-end FF knowledge care to discuss the rationale for this? It seems reasonable to me I suppose, but I don't know what the devs are considering.

It might be helpful for FF to provide feedback to the user when clicking the padlock to point out the implications of the presented certificate info, given the current preferences set, and how changing those preferences may yield different results. E.g., "this certificate was issued by an issuer using extended validation, but due to your current preferences, Firefox was unable to confirm the validity of the certificate. Check...[...]...and restart Firefox to enable validity checking," or some such.

Answer: yes. If you turn off OCSP checking, EV indications will stop and you'll just get a grey padlock and no owner info. HOWEVER, the certificates used, if inspected, will be (under normal conditions) the EV certs, and so you're still getting the full measure of authentication from the website you normally get with EV. It just becomes incumbent on you to inspect the certificate yourself on each occasion to use the site, if you want that assurance. Anyone with back-end FF knowledge care to discuss the rationale for this? It seems reasonable to me I suppose, but I don't know what the devs are considering. It might be helpful for FF to provide feedback to the user when clicking the padlock to point out the implications of the presented certificate info, given the current preferences set, and how changing those preferences may yield different results. E.g., "this certificate was issued by an issuer using extended validation, but due to your current preferences, Firefox was unable to confirm the validity of the certificate. Check...[...]...and restart Firefox to enable validity checking," or some such.
jscher2000
  • Top 10 Contributor
8635 izisombululo 70627 izimpendulo
Kuphostiwe

OCSP checking is the default setting in Firefox. The CA/Browser forum prescribes the following in its "GUIDELINES for the PROCESSING of EXTENDED VALIDATION CERTIFICATES" (source):

12. Revocation Checking

Applications must confirm that the EV certificate has not been revoked before accepting it. Revocation checking must be performed in accordance with [RFC5280]. Certificates for which confirmation cannot be obtained must not be granted the EV treatment (see Section 13, below).

The application should support both CRL and OCSP services. For HTTP schemes, the application may use either the GET or POST method. If the application cannot obtain a response using one service, then it should try all available alternative services.

The application should follow HTTP redirects and cache-refresh directives.

Response time-out should not be less than three seconds.

I'm not clear on whether Firefox uses CRL as an alternative to OCSP when it is disabled, or unavailable, but as of the time of the following page, it appears it wasn't yet supported and might not have been in progress ("Bug number?"): https://wiki.mozilla.org/CA:EV_Revocation_Checking#Requiremen....

(All of the above based on some searching and no prior personal knowledge.)

OCSP checking is the default setting in Firefox. The CA/Browser forum prescribes the following in its "GUIDELINES for the PROCESSING of EXTENDED VALIDATION CERTIFICATES" ([https://www.cabforum.org/documents.html source]): <blockquote>'''12. Revocation Checking'''<br><br>Applications must confirm that the EV certificate has not been revoked before accepting it. Revocation checking must be performed in accordance with [RFC5280]. Certificates for which confirmation cannot be obtained must not be granted the EV treatment (see Section 13, below).<br><br>The application should support both CRL and OCSP services. For HTTP schemes, the application may use either the GET or POST method. If the application cannot obtain a response using one service, then it should try all available alternative services.<br><br>The application should follow HTTP redirects and cache-refresh directives.<br><br>Response time-out should not be less than three seconds.</blockquote> I'm not clear on whether Firefox uses CRL as an alternative to OCSP when it is disabled, or unavailable, but as of the time of the following page, it appears it wasn't yet supported and might not have been in progress ("Bug number?"): [https://wiki.mozilla.org/CA:EV_Revocation_Checking#Requirements]. (All of the above based on some searching and no prior personal knowledge.)
andrew.skretvedt 1 izisombululo 8 izimpendulo
Kuphostiwe

Good get, jscher2000. It all makes sense now...

Good get, jscher2000. It all makes sense now...