Closed Bug 1934361 Opened 3 months ago Closed 15 days ago

ICP-Brasil: Mis-issued certificate

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: fhochstrasser, Assigned: bwilson, NeedInfo)

References

Details

(Whiteboard: [ca-compliance] [ov-misissuance])

User Agent: Mozilla/5.0 (X11; CrOS x86_64 14541.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36

Steps to reproduce:

https://crt.sh/?sha256=421329f0dc2f683d6e96c1b5b310974d0997ad984ef69120f55372b4f48e1037 is mis-issued.

google.com has a CAA RR which only allows pki.goog to issue certificates for this domain (I know, this is not a hard proof because this may have changed, but I am very confident it didn't change)

$ dig +short google.com caa
0 issue "pki.goog"

The certificate also has other issues. Here is the ouptut of the zlint -longSummary:

| LEVEL | # OCCURRENCES |                       DETAILS                       |
+-------+---------------+-----------------------------------------------------+
|  info |             0 |                                                  -  |
|  warn |             3 |                  w_ext_san_critical_with_subject_dn |
|       |               |       w_ext_subject_key_identifier_missing_sub_cert |
|       |               |                      w_subject_common_name_included |
| error |             3 |                                 e_rsa_allowed_ku_ee |
|       |               |           e_sub_cert_basic_constraints_not_critical |
|       |               |                         e_invalid_subject_rdn_order |
| fatal |             0 |                                                  -  |

I don't think ICP-Brasil is publicly trusted. I found inclusion requests, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1674669 or https://bugzilla.mozilla.org/show_bug.cgi?id=438825 or https://bugzilla.mozilla.org/show_bug.cgi?id=1677631.

I would like to add this mis-issuance to the list of events to consider when including (or not) ICP-Brasil in the Mozilla root store.

Actual results:

The certificate is mis-issued.

Expected results:

The certificate should not have been issued.

Would that mean the ICP-Brasil willingly ignores the CAA RR? Is checking that part of the root program inclusion process?

--
(hi from the other side)

(In reply to Fabien Hochstrasser from comment #0)

I don't think ICP-Brasil is publicly trusted.

The issuing intermediate "Autoridade Certificadora Raiz Brasileira v10" is trusted by Microsoft for server authentication according to https://learn.microsoft.com/en-us/security/trusted-root/participants-list

Curiously, ICP-Brasil has recently issued a determination removing itself from SSL/TLS certificates except for closed ecosystems (such as the financial network).
https://repositorio.iti.gov.br/resolucoes/Resolucao209_descontinuidade_SSL.htm

(In reply to Mathew Hodson from comment #2)

(In reply to Fabien Hochstrasser from comment #0)

I don't think ICP-Brasil is publicly trusted.

The issuing intermediate "Autoridade Certificadora Raiz Brasileira v10" is trusted by Microsoft for server authentication according to https://learn.microsoft.com/en-us/security/trusted-root/participants-list

Actually, unless I’m mistaken, V10 is a root.

ICP-Brasil is a national root that acts as a “Super CA”, issuing intermediates for external entities adhered to the trust model. In this case the intermediate doing the mis-issuance is assigned to Certisign (https://certisign.com.br/)

Maybe also to consider in this bug are the linting problems in the referenced certificate (and maybe others)

Taking a look at the issued certificate, “GOOGLE PAY BRASIL INSTITUICAO DE PAGAMENTO LTDA” is indeed a company affiliated with Google according to https://startups.com.br/negocios/google-pay-tem-aval-do-bc-para-ser-instituicao-de-pagamento-no-brasil/:

De acordo com o despacho, a Google Pay Brasil Instituição de Pagamento terá capital social de R$ 96 milhões e os controladores são Larry Page e Sergey Brin.

But I wonder if Certisign actually performed DCV for “google.com”? Maybe they can clarify how the DCV was conducted.

Finally, kind of off-topic here, I think, given the high number of linter findings, is Microsoft really supervising the operation of this type of CAs? Are these certificates truly compliant with their own “Microsoft Trusted Root Program”? Did Microsoft receive a request from ICP-Brasil to be removed from the Microsoft root program?

Certificates for Brazilian payment system (locally known as SPB) is one of the few uses where ICP-Brasil is still authorized to issue certificates in a SSL/TLS context. They are only considered valid and only supposed to be accepted by authorized payment and finance operators of SPB. Google Pay is only authorized in SPB as a payment initiator, so this is only to be used by Google Wallet initiating transactions (most likely Pix instant money transfer transactions).

So this looks like a context issue: these certificates are only to be trusted within specific scopes, not everywhere.

Given how certificates work, unless that scope is somehow codified and technically enforced so that it falls outside the jurisdiction of server certificates in the BRs, it doesn’t change the situation here.

Also I’m surprised that neither Microsoft nor the CA in question has commented on this yet. An acknowledgment from the CA within 24 hours is expected.

While a comment from Microsoft is not expected, it would be great if they also explained what mitigations they plan to put in place here.

See Bug #1674669 - the root is not yet included in the Mozilla Root Store, but this would be relevant to that inclusion request.

Would it be possible to put this certificate on a blocklist? (https://blog.mozilla.org/security/2011/03/22/firefox-blocking-fraudulent-certificates/)

Would it be possible to put this certificate on a blocklist? (https://blog.mozilla.org/security/2011/03/22/firefox-blocking-fraudulent-certificates/)

The certificate in question doesn't have a valid certification path that terminates at a root certificate trusted by Firefox, so there is no need to do this.

To your point, this action should be considered by the trust store operators where the certificate in question is trusted for TLS serverauth.

(In reply to Ben Wilson from comment #8)

See Bug #1674669 - the root is not yet included in the Mozilla Root Store, but this would be relevant to that inclusion request.

This would be relevant to Certisign's own inclusion request (https://bugzilla.mozilla.org/show_bug.cgi?id=1479040) as well, no?

(In reply to Jaime Hablutzel from comment #11)

(In reply to Ben Wilson from comment #8)

See Bug #1674669 - the root is not yet included in the Mozilla Root Store, but this would be relevant to that inclusion request.

This would be relevant to Certisign's own inclusion request (https://bugzilla.mozilla.org/show_bug.cgi?id=1479040) as well, no?

Apparently so.

Assignee: nobody → bwilson
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance] [ov-misissuance]
Depends on: 1934630
Type: defect → task

In reply to https://bugzilla.mozilla.org/show_bug.cgi?id=1934361#c8 from Ben Wilson

This request is old, from a time that ICP-Brasil was trying to get inclusion in trust stores. Current ICP-Brasil policy would not allow such a request, since it removed itself from SSL/TLS certificates used outside regulated sectors.

As for the Certisign request, it depends if it was asking inclusion of its CA connected to ICP-Brasil or its own root CA not connected to ICP-Brasil. If the former, an ICP-Brasil subordinate CA, then what I mentioned earlier also applies to this request. But if it's a standalone root of Certisign, it's up to them and to trust operators whether it should be still followed up.

Note that since ICP-Brasil itself was not in trust stores, subordinate CAs had to ask inclusion of ICP-Brasil->Subordinate CA path instead of wholesale recognizing ICP-Brasil.

Nonetheless, we'll add this certificate to OneCRL - see Bug #1934630.

During our standard certificate monitoring, an internal miscommunication led us to incorrectly deem a legitimate request as a one issued in error. We apologize for the confusion and will be performing a postmortem on this issue.

I find a bit strange that the certificate subscriber and/or incident reporter is the one doing the postmortem. The certificate issuer is the one expected here, to explain how CAA checks were bypassed or succeeded.

Also, it's worth noting that the certificate itself is a mis-issuance as shown by the linting problems, which BTW, don't only affect this certificate, as one could see at https://crt.sh/?caid=264347&opt=cablint,zlint,x509lint&minNotBefore=2024-01-01

Finally, if these certificates are trusted by Microsoft only, it would be good if someone from that Root Program could intervene here (maybe with a "needinfo" tagging?)

Could you clarify what you mean by "legitimate request"? Did Google intend for this certificate to be usable for TLS server authentication of google.com?

Flags: needinfo?(mozilla)

@Andrew, it seems Google preferred to wildcard it instead of enumerating specific endpoints for the Google Wallet infrastructure.

We still haven’t had the CA in question ack this report.

This certificate is still mis-issued, right? Has the CA revoked this certificate yet?

Is there anyone from the CA even monitoring this report?

Google: since you seem to be in contact with this CA, can you please let them know that this incident is open here? It’s important that root cause analysis also explains the delay in acknowledgment here.

I believe this certificate should have been issued from "AC Certisign SPB - G6" instead of "AC Certisign ICP-Brasil SSL EV G4" in order to follow CA practices of certificates for that specific environment and to follow current ICP-Brasil guidelines of not issuing overarching SSL/TLS certificates. But regardless, this certificate has been requested by a Google subsidiary, left hand didn't know what right hand was doing, and here we are.

(In reply to amir from comment #7)

While a comment from Microsoft is not expected, it would be great if they also explained what mitigations they plan to put in place here.

I noticed that this certificate was just added to Microsoft's disallowed certificates list.

This certificate has apparently been revoked by the CA. I intend to close this bug on or about Friday, 14-Feb-2025, unless it needs to remain open for some reason.

Flags: needinfo?(bwilson)
Status: ASSIGNED → RESOLVED
Closed: 15 days ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.