Closed Bug 1717711 Opened 7 months ago Closed 4 months ago

Enable EV Treatment for HARICA's 2015 and 2021 root certificates

Categories

(Core :: Security: PSM, task)

task

Tracking

()

RESOLVED FIXED
95 Branch
Tracking Status
firefox95 --- fixed

People

(Reporter: kwilson, Assigned: jschanck)

References

Details

(Whiteboard: [psm-blocked] September 2021 Batch of EV Changes )

Attachments

(3 files)

Per bug #1690054 and bug #1695487 the request from HARICA has been approved to enable the following root certificates for EV use. Please make the corresponding changes to PSM.

Friendly Name: Hellenic Academic and Research Institutions ECC RootCA 2015
SHA-1 Fingerprint: 9FF1718D92D59AF37D7497B4BC6F84680BBAB666
SHA-256 Fingerprint: 44B545AA8A25E65A73CA15DC27FC36D24C1CB9953A066539B11582DC487B4833
EV Policy OID: 2.23.140.1.1
Test URL: https://haricaeccrootca2015-valid-ev.harica.gr

Friendly Name: Hellenic Academic and Research Institutions RootCA 2015
SHA-1 Fingerprint: 010C0695A6981914FFBF5FC6B0B695EA29E912A6
SHA-256 Fingerprint: A040929A02CE53B4ACF4F2FFC6981CE4496F755E6D45FE0B2A692BCD52523F36
EV Policy OID: 2.23.140.1.1
Test URL: https://haricarootca2015-valid-ev.harica.gr

Friendly Name: HARICA TLS RSA Root CA 2021
SHA-1 Fingerprint: 022D0582FA88CE140C0679DE7F1410E945D7A56D
SHA-256 Fingerprint: D95D0E8EDA79525BF9BEB11B14D2100D3294985F0C62D9FABD9CD999ECCB7B1D
EV Policy OID: 2.23.140.1.1
Test URL: https://tls-rsa-valid-ev.root2021.harica.gr

Friendly Name: HARICA TLS ECC Root CA 2021
SHA-1 Fingerprint: BCB0C19DE9989270193857E98DA7B45D6EEE0148
SHA-256 Fingerprint: 3F99CC474ACFCE4DFED58794665E478D1547739F2E780F1BB4CA9B133097D401
EV Policy OID: 2.23.140.1.1
Test URL: https://tls-ecc-valid-ev.root2021.harica.gr

NOTE: Bug #1717707 must be completed (the 2021 certs added to NSS), before this EV-enablement may be implemented. The 2015 roots are already in NSS.

Summary: Enable EV Treatment for HARICA's 2021 root certificates → Enable EV Treatment for HARICA's 2015 and 2021 root certificates
Blocks: 1690054
Whiteboard: [psm-blocked] Depends on September 2021 Batch of Root Changes → [psm-blocked] September 2021 Batch of EV Changes

I have verified that HARICA's 2021 root certificates have been added in Firefox 94.

Assignee: nobody → jschanck
Status: NEW → ASSIGNED
Pushed by dkeeler@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c6ec2978accb
Enable EV Treatment for HARICA's 2015 and 2021 root certificates r=rmf,keeler
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch

Thanks John and Dana. Would you please also help me with the following?

When I tried verifying EV-enablement in Firefox Nightly for these 4 root certificates, I found that the test URLs for the 2015 root certs are getting EV treatment now, but the test URLs for the 2021 root certs are not getting EV treatment.

So I ran https://tls-observatory.services.mozilla.com/static/ev-checker.html for the test URLs for the 2021 root certs, and get the following result:
ev-checker exited successfully: exit status 1, Stderr: Error making OCSP request to '

I understand that for EV, when Firefox is unable to complete the OCSP check it falls back to non-EV. But I'm trying to figure out why the OCSP check is failing. The message returned by the ev-checker isn't complete, so not quite sure what's going wrong.

To try to figure out more about the OCSP problem, I looked at
https://certificate.revocationcheck.com/tls-ecc-valid-ev.root2021.harica.gr
https://certificate.revocationcheck.com/tls-rsa-valid-ev.root2021.harica.gr
This OCSP response was cached at Oct 11, 2021 2:15:13 PM
OCSP appears to work fine.

Are you able to see where the OCSP check is failing?

I saw intermittent OCSP failures when I was testing this too. It's responding for me right now, but I think their OCSP server is not very reliable.

Thanks, John!

Dimitris, Please see Comment #6. The OCSP checks for the test URLs for the 2021 root certs are still not working for me, but it appears to work sometimes for John.

Flags: needinfo?(jimmy)

Hi Kathleen and John,

We are looking into this issue. We are not able to replicate the problem and we are not certain what the https://tls-observatory.services.mozilla.com/static/ev-checker.html is doing, exactly.

The error exit status 1, Stderr: Error making OCSP request to ' seems to be some problem with the tool and is not indicative of an error at the OCSP responder's side. Unfortunately we could not check the source code of your tool because https://github.com/mozkeeler/ev-checker only points to the web site where the tool is available.

All of our OCSP responders (for the 2015 and 2021 hierarchies) are using the same infrastructure and software. The 2015 hierarchy seems to work ok with your tool but not the 2021 one. Perhaps it's because the SubCA Certificate from the 2021 hierarchy does not contain an OCSP URI in the AIA extension so there is no OCSP check for that, as it is allowed according to the latest BRs, but that's just a guess.

We confirmed the correct behavior of our OCSP responders using OpenSSL which you can reproduce by following these steps:

Download the CA Certificates:
wget -q http://repo.harica.gr/certs/HaricaECCEVTLSSubCAR1.pem http://repo.harica.gr/certs/HARICA-EV-TLS-Sub-E1.pem http://repo.harica.gr/certs/HARICA-TLS-Root-2021-ECC.pem

For checking the 2015 ECC hierarchy (Serial Number from https://haricaeccrootca2015-valid-ev.harica.gr):
openssl ocsp -url http://ocsp.harica.gr -issuer HaricaECCEVTLSSubCAR1.pem -serial 0x481EB14FC4D8F65BF88476D1B5088897 -no_nonce

Response verify OK
0x481EB14FC4D8F65BF88476D1B5088897: good
This Update: Oct 12 08:26:28 2021 GMT
Next Update: Oct 14 08:26:28 2021 GMT

For checking the 2021 ECC TLS hierarchy (Serial Number from https://tls-ecc-valid-ev.root2021.harica.gr)
openssl ocsp -url http://ocsp.harica.gr -CAfile HARICA-TLS-Root-2021-ECC.pem -issuer HARICA-EV-TLS-Sub-E1.pem -serial 0x767FE746364554331D926EF9F8836FA7 -no_nonce

Response verify OK
0x767FE746364554331D926EF9F8836FA7: good
This Update: Oct 12 08:30:57 2021 GMT
Next Update: Oct 14 08:30:57 2021 GMT

We also checked our OCSP responders using https://certificate.revocationcheck.com. We run it more than 10 times and we had zero cases where an error was thrown. I will attach the reports.

If you have any concerns about the reliability of HARICA's OCSP servers, please provide us with more information so we can troubleshoot.

Flags: needinfo?(jimmy)

I received the following in email from Dimitris: The BRs have been updated to allow SubCA Certificates not to include an OCSP URL in the AIA extension, for reasons explained during the SC31 ballot. If Firefox NEEDS certificate status of CA Certificates to be performed via OCSP in order to enable EV treatment, just like it expects for end-entity certificates, then this seems to be an unintended consequence from the SC31 Browser Alignment ballot.

Indeed, looking at section 7.1.2.2 (Subordinate CA Certificate profile) of the BRs, it now says:
b. cRLDistributionPoints
This extension MUST be present and MUST NOT be marked critical. It MUST
contain the HTTP URL of the CA’s CRL service.
c. authorityInformationAccess
This extension SHOULD be present. It MUST NOT be marked critical.
It SHOULD contain the HTTP URL of the Issuing CA’s certificate (accessMethod =
1.3.6.1.5.5.7.48.2). It MAY contain the HTTP URL of the Issuing CA’s OCSP responder
(accessMethod = 1.3.6.1.5.5.7.48.1).

But I think that Firefox is still checking OCSP for the intermediate certificates:
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#Revocation_Checking

So it may be that since OCSP is failing on the intermediate certificates chaining up to the 2021 roots, so the certs for those test websites do not get EV treatment.

I filed Bug #1735386 for updating the way Firefox does revocation checking of intermediate certificates for EV.

You need to log in before you can comment on or make changes to this bug.