2032468 - VISA: Misissuance detected by PKIMetal

Status: ASSIGNED

(CA Program :: CA Certificate Compliance, task)

Description

[incident-reporting]

CA: VISA
Issue: Validity too long

Examples:

• https://crt.sh/?id=25258522869&opt=pkimetal
• https://crt.sh/?id=25311554923&opt=pkimetal
• https://crt.sh/?id=25258522869&opt=pkimetal

crt.sh trust flags:

• 360 Browser: No
• Apple: No
• Microsoft: Yes
• Mozilla: No
• Chrome: No
• Android: No
• Gmail: No
• Java: No
• Cisco: No
• EUTL QWAC: No
• Adobe EUTL: No
• Adobe AATL: No
• Adobe CDS: No

Comment 1

[ijeun]

Thank you for bringing this to our attention.
Visa acknowledges the report and is currently reviewing the findings related to the identified certificates. We are actively investigating the matter and will provide additional information once our review is complete.

Comment 2

[trusten]

More timely and substantive updates are generally expected from a publicly trusted CA, even in cases where the CA is only trusted within a limited ecosystem. At this point, the incident has been acknowledged, but there is still very little information available regarding scope, root cause, remediation, or preventive controls, and the community should reasonably expect an actual incident report rather than only a brief acknowledgement.

Given the nature of this incident, the community would appreciate clarification regarding compliance with section 4.3.1.2 of the CA/Browser Forum Baseline Requirements, which, effective 2025-03-15, states that the CA SHALL implement a Linting process to test the technical conformity of each to-be-signed artifact prior to signing it.

In particular, could Visa please confirm:

• Whether a Linting process was implemented for the affected to-be-signed Certificate or Precertificate content,
• Whether linting results are treated as issuance-blocking,
• Whether the CA uses Linting tools that are widely adopted by the industry as contemplated by BR 4.3.1.2,
• Whether this issue resulted from missing lint coverage, integration issues, configuration gaps, or another control failure,
• Whether additional certificates with similar validity problems have been identified.

Additional transparency around the controls currently implemented, along with a proper incident report covering timeline, scope, root cause, and remediation, would help the community better assess the effectiveness and maturity of the CA’s compliance processes going forward.

Comment 3

[ijeun]

Issue Scope
The certificates identified in this report were issued under the Visa Public RSA Root CA and exceed the maximum TLS certificate validity permitted by the Baseline Requirements.

Remediation
Visa is replacing the Visa Public RSA Root CA for publicly trusted TLS server certificate issuance with a newly established root, the Visa TLS Root CA, to ensure full compliance with the Baseline Requirements. The Visa TLS Root CA is dedicated exclusively to issuing TLS server certificates and enforces shortened certificate validity periods in accordance with current and forthcoming requirements.

Visa has submitted CCADB inclusion requests for the new root (case numbers 00001830 and 00002991). Upon approval, the Visa TLS Root CA will become the root used for publicly trusted TLS server certificate issuance.

Prevention
Following completion of the migration and applicable trust store updates, the Visa Public RSA Root CA will no longer be used for publicly trusted TLS server certificate issuance and will continue to operate exclusively as a private/internal CA. This change will prevent recurrence and ensure continued compliance with Baseline Requirements.

Comment 4

[Wayne]

As previously mentioned please fill out the full Final Incident Report template as per CCADB Incident Reporting Guidelines.

It is over 16 days since receipt of the original issue, as we have yet to see a preliminary, or final incident report. There is also a lack of weekly updates on this incident. That is 3 separate incidents to be filed.

This is important both for your continued inclusion and for any future root inclusions in other programs.

Comment 5

[ijeun]

Preliminary Incident Report

Summary

• Incident description: Visa acknowledges receipt of the report regarding the identified certificates. An internal review and investigation are currently underway to assess the findings and determine impact.
• Relevant policies: Under review (e.g., CA/Browser Forum Baseline Requirements, applicable internal certificate issuance policies).
• Source of incident disclosure: PKIMetal.

Comment 6

[ijeun]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000063
• Incident description: Certificates issued under the Visa Public RSA Root CA for publicly trusted TLS server authentication exceeded the maximum certificate validity period permitted by the CA/Browser Forum Baseline Requirements.
• Timeline summary:
  • Non-compliance start date: 3/15/2026
  • Non-compliance identified date: 4/16/2026
  • Non-compliance end date: Next release of trust list
• Relevant policies: CA/B Forum BR, the maximum allowed validity period for TLS server certificates.
• Source of incident disclosure: PKIMetal

Impact

• Total number of certificates: 233
• Total number of "remaining valid" certificates: 233
• Affected certificate types: TLS server certificates issued under the Visa Public RSA Root CA.
• Incident heuristic: Any TLS Server certificate issued after March 15, 2026 by the Visa Public RSA Root CA are affected by this incident.
• Was issuance stopped in response to this incident, and why or why not?: No, Visa TLS Root CA will no longer be used for publicly trusted TLS server certificates.
• Analysis: Visa is replacing the Visa Public RSA Root CA for publicly trusted TLS server certificate issuance with a newly established root, the Visa TLS Root CA, to ensure full compliance with the Baseline Requirements. The Visa TLS Root CA is dedicated exclusively to issuing TLS server certificates and enforces shortened certificate validity periods in accordance with current and forthcoming requirements
• Additional considerations: Visa has submitted CCADB inclusion requests for the new root (case numbers 00001830 and 00002991). Upon approval, the Visa TLS Root CA will become the root used for publicly trusted TLS server certificate issuance.

Timeline

• December 20, 2025: Visa determined that publicly trusted TLS issuance under the Visa Public RSA Root CA would be transitioned to a newly established root, the Visa TLS Root CA.
• February 20, 2026: Visa submitted CCADB inclusion requests for the Visa TLS Root CA (case numbers 00001830 and 00002991).
• March 15, 2026: TLS server certificates issued under the Visa Public RSA Root CA have validity periods exceeding the Baseline Requirements maximum.
• April 16, 2026: The issue was identified through PKIMetal.
• April 17, 2026: Visa initiated internal investigation and impact assessment.

Related Incidents

Bug	Date	Description
2032468	https://bugzilla.mozilla.org/show_bug.cgi?id=2032468	April 16,2026

Root Cause Analysis

Contributing Factor #1: Transition to Private CA

• Description: Visa is replacing the Visa Public RSA Root CA for publicly trusted TLS server certificate issuance with a newly established root, the Visa TLS Root CA, to ensure full compliance with the Baseline Requirements
• Timeline: Visa submitted CCADB inclusion requests for the Visa TLS Root CA (case numbers 00001830 and 00002991)
• Detection: Visa Public RSA Root CA will no longer be used for publicly trusted TLS server certificate issuance and will continue to operate exclusively as a private/internal CA.
• Interaction with other factors: CCADB inclusion requests for the new root(case numbers 00001830 and 00002991)
• Root Cause Analysis methodology used: Visa PKI CP/CPS

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Trust store update	Prevent	Transition to Private CA	Visa Public RSA Root CA will operate exclusively as a Private/Internal CA	Upon tyrst store update	In Progress

Appendix

Comment 7

[incident-reporting]

Were these EV, OV, or DV certificates?

Comment 8

[ijeun]

They are OV certificates.

Comment 9

[ijeun]

Please let us know if further clarification is needed, or additional corrective actions are expected prior to closure.

Comment 10

[trusten]

Comment 9 asks whether further clarification is needed before closure. The answer is yes — substantially so. The more pressing question is why Visa believes it is appropriate to seek closure when the questions posed in Comment 2 have received no response whatsoever.

To be direct: Not one of the five specific questions about linting compliance under BR 4.3.1.2 in Comment 2 was answered. Visa instead filed a full incident report that is conspicuously silent on whether any linting process existed, whether linting results were issuance-blocking, and whether this failure reflects a systemic control gap that extends beyond the certificates identified here. Visa’s apparent position is that those questions don’t require answers. That position is not defensible.

Visa’s report states that issuance was not stopped in response to this incident. The stated reason — “Visa TLS Root CA will no longer be used for publicly trusted TLS server certificates” — is not a reason. It describes a future state. It does not explain why 233 misissuance certificates, all of which remain valid today, were not revoked. Misissuance is a revocation trigger under BR 4.9.1.1. The incident report contains no revocation analysis, no explanation for why revocation was not pursued, and no timeline for remediation of the existing outstanding certificates. The word “revocation” does not appear anywhere in the incident report.

The root cause analysis deserves particular attention. The identified root cause is “Transition to Private CA.” This is not a root cause. This is a description of Visa’s intended future state, repurposed as an explanation for past non-compliance. A root cause analysis is supposed to explain why certificates with validity periods exceeding the BR maximum were issued after March 15, 2026 — the date the new maximum took effect. The report does not answer that question. Did Visa’s issuance systems not enforce validity period caps? Was there no linting? Was there a configuration error? Was the CA simply unaware of the March 15 effective date? None of this is addressed.

On that point: Visa appears to have decided in December 2025 to transition to a new root for public TLS issuance, and submitted CCADB inclusion requests in February 2026. The new validity period requirements were also known well in advance. The natural question — one the root cause analysis never asks — is why a CA that knew it was transitioning away from public TLS issuance continued to issue publicly-trusted TLS certificates after March 15, 2026 without ensuring those certificates conformed to the requirements that had been in effect since that date. That is either a process failure, a control failure, or both, and it remains unexplained.

Visa is currently trusted by Microsoft. Until that changes, Visa is a publicly trusted CA and is subject to the full obligations of the Baseline Requirements. The fact that Visa intends to eventually migrate to a different root does not suspend those obligations in the interim. The suggestion — implicit in Comment 3 and in the incident report — that compliance with BR requirements is essentially a matter of patience while the new root inclusion requests are processed reflects a misunderstanding of how public trust works. Root program membership is not a subscription that lapses gracefully; it carries ongoing compliance obligations that apply to every certificate issued under every currently-trusted root, for as long as that trust persists.

Before this bug can reasonably be considered for closure, Visa should address:

1.	The five questions from Comment 2 regarding linting, none of which have been answered.
2.	Why the 233 remaining-valid misissuance certificates have not been revoked, with a specific explanation of Visa’s analysis under BR 4.9.1.1.
3.	An actual root cause — meaning a technical and process explanation for why the validity periods exceeded the maximum, not a restatement of the remediation plan.
4.	What controls, if any, currently prevent continued misissuance under the Visa Public RSA Root CA while the trust store transition is pending.

The community cannot meaningfully assess whether Visa’s controls are adequate, or whether the new Visa TLS Root CA should be trusted, without answers to those questions. Seeking closure without providing them does not inspire confidence.

Comment 11

[ijeun]

Attachment: Updated incident report

Comment 12

[ijeun]

Full Incident Report

This is the revised version of our Full Incident Report.

Summary

• CA Owner CCADB unique ID: A000063

• Incident description: On April 16, 2026, PKIMetal detected that Visa had issued certificates with validity periods exceeding the maximum dates for publicly trusted TLS certificates. The maximum permitted validity for publicly trusted TLS certificates issued on or after March 15, 2026 is 200 days.<br>
  At the time of issuance, this non-compliance resulted from an internal transition effort to move the Visa Public RSA Root CA from public usage to private use. As part of this transition, Visa updated its CP/CPS to reflect the intended change, introduced a replacement root (Visa TLS Root CA), and submitted requests for replacement in public trust stores. The affected certificates are used only among Visa clients and partners to connect with Visa. <br>
  Despite this intended transition, the Visa Public RSA Root CA remained included in the public trust store. Visa acknowledges that operationally treating this Root CA as private prior to its formal removal from the trust stores was incorrect. Visa has since updated its processes to prevent recurrence and is executing a replacement and revocation plan for all affected TLS server certificates.

• Timeline summary:

  • Non-compliance start date: 3/15/2026 (effective date of the 200-day maximum validity requirement for publicly trusted TLS certificates).
  • Non-compliance identified date: 4/16/2026
  • Non-compliance end date: 6/2/2026

• Relevant policies: CA/B Forum BR

• Source of incident disclosure: PKIMetal

Impact

• Total number of certificates: 233. Visa reported 233 certificates as misissued. After further analysis of certificate profiles and Extended Key Usage (EKU), the population was refined as follows:
  • TLS Server certificates: 38
  • Internal Server Certificates: 86, deployed only within controlled internal environments.
  • Client authentication certificates: 109, containing only id-kp-clientAuth EKU.
• Total number of "affected" certificates: 124
• Affected certificate types: TLS Server certificates and Internal Server Certificates
• Incident heuristic: All certificates issued after March 15, 2026 by the Visa Public RSA Root CA containing serverAuth EKU.
• Was issuance stopped in response to this incident, and why or why not?: Yes
• Analysis: Visa recognizes that the certificates were not compliant with applicable CA/B Forum BRs, regardless of intended future state.Visa refined the affected certificates and planned the following revocation and replacement approach:
  • TLS Server Certificates (id-kp-serverAuth): Replacement and revocation are prioritized and in progress. Visa recognizes that immediate revocation without replacement could result in significant operational disruption to dependent systems. Therefore, Visa is executing an accelerated replacement-first approach to minimize service impact, with revocation performed promptly upon successful replacement. Due to operational dependencies requiring coordination with certificate owners and manual deployment, Visa expects 100% replacement and revocation by June 30.
  • Internal Server Certificates (id-kp-serverAuth, internal-only deployment): Although deployed in restricted internal environments, Visa acknowledges that they remain within scope of public CA requirements while the issuing root is publicly trusted. Given the same manual coordination constraints with internal certificate owners, replacement will be performed first to avoid service disruption, followed by revocation. Visa anticipates completion of replacement and revocation by July 30.
  • Client Authentication Certificates (id-kp-clientAuth only): These certificates contain only the id‑kp‑clientAuth EKU and do not include id‑kp‑serverAuth. Their usage is strictly limited to client authentication and they are not capable of being used for TLS server authentication.
• Additional considerations: While remediation activities are being conducted through a manual replacement process that requires additional coordination time, Visa is prioritizing accelerated replacement and revocation.

Timeline

• December 20, 2025: Transition strategy defined, CP/CPS updated to reflect the planned transition from public to private for Visa Public RSA Root CA.
• February 20, 2026: CCADB inclusion requests submitted for the Visa TLS Root CA (case numbers 00001830 and 00002991).
• March 15, 2026: Non-compliant certificate issuance began exceeding 200-day validity.
• April 16, 2026: The issue was identified through PKIMetal.
• April 17, 2026: Visa initiated internal investigation and impact assessment.
• June 2, 2026: Certificate profile corrected, linting was updated to include the RSA Root CA.

Related Incidents

Bug	Date	Description
-	-	-

Root Cause Analysis

Contributing Factor #1: Gap between intended private transition and actual public trust status

• Description: Visa treated the RSA Root CA as effectively private based on intended transition state, despite its continued presence in public trust stores, and therefore did not configure the maximum allowed validity period in a manner consistent with the applicable CA/B Forum BRs.
• Timeline: Present during the transition planning period and persisted until the incident investigation determined that Root CA still needed to be treated as publicly trusted.
• Detection: Identified during post-incident review of policy intent, operational control scope, and trust store status.
• Interaction with other factors: This factor contributed directly to the RSA Root being excluded from certain public CA control mechanisms, including linting coverage.
• Root Cause Analysis methodology used: Process trace across CP/CPS intent, trust store status, and operational enforcement.

Contributing Factor #2: Certificate profile configuration gap

• Description: Certificate profiles under the affected hierarchy continued to allow validity periods exceeding the maximum permitted lifetime after March 15, 2026.
• Timeline: Active from the effective date until the affected profiles were corrected.
• Detection: Identified during technical review of issuance configuration and issued certificate contents.
• Interaction with other factors: This gap was not caught pre-issuance because the RSA Root hierarchy had not been included in the linting enforcement scope.
• Root Cause Analysis methodology used: Technical configuration analysis.

Contributing Factor #3: Linting scope gap

• Description: Visa has pre-issuance linting deployed for publicly trusted CAs using an industry-recognized tool, and those linting results are treated as issuance blocking controls. However, the Visa Public RSA Root CA was excluded in that linting scope since CP/CPS was updated because it had been treated internally as transitioning to private CA usage.
• Timeline: Linting existed for other public CAs during the affected period but did not cover the RSA Root until after the incident.
• Detection: Identified during review of issuance controls following incident discovery.
• Interaction with other factors: This allowed the certificate profile configuration gap to result in actual issuance rather than being blocked pre-issuance.
• Root Cause Analysis methodology used: Issuance workflow and validation-control review.

Lessons Learned

• What went well: Visa conducted a deeper technical review to improve accuracy. Existing linting capabilities were already available in the environment for other publicly trusted CAs.
• What didn’t go well: Visa treated the RSA Root as effectively private before trust store removal was complete.
• Additional: All affected certificates were used solely in internal or client-only authentication contexts rather than broadly exposed public web server deployments. Future change governance will require explicit validation that a Root CA has actually been removed from public trust stores before it can be operationally treated as private.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Extend issuance-blocking linting to the Visa Public RSA Root CA while it remains publicly trusted	Prevent	#1, #3	Evidence that linting covers all publicly CAs	2026-06-02	Completed
Update all affected certificate profiles to enforce BR-aligned maximum validity	Prevent/Correct	#2	Configuration evidence showing maximum permitted validity	2026-06-02	Completed
Add process checkpoint requiring trust store status validation before any hierarchy is treated as private	Prevent	#1	Update internal process requiring verification of actual trust store removal	2026-06-02	Completed
Replace and revoke all affected TLS server certificates	Correct	#2	100% of serverAuth certificates replaced and revoked	2026-06-30	In Progress
Replace and revoke all affected internal server certificates containing serverAuth	Correct	#2	100% of Internal serverAuth certificates replaced and revoked	2026-07-30	In Progress
Perform periodic post-issuance compliance audits for validity and lint coverage	Detect	Root Cause #1, #2, #3	Audit evidence showing no new non-compliant issuance	2026-09-30	In Progress

Appendix

A CSV file with TLS server certificate details is attached.

Comment 13

[ijeun]

Attachment: Certificate list for TLS Server

TLS Server certificates - subject to revoke by June 30.

Comment 14

[Zacharias]

The aim here is transparency and a list containing just serial numbers leaves a lot of work for community members to look into the data. Could you please provide the amended the lists with a more complete set of information per certificate. Specifically I’m interested in subject attributes (such as common name and subject alternative name) and the validity period

Comment 15

[Wayne]

This is an awful incident to date, here are some of the minor issues so far.

VISA were aware from 2026-04-16, and only stopped being non-compliant on 2026-06-02 - that is 47 days.

The public acknowledgement of this incident is on 2026-04-22 in Comment 1. That is 6 days into being aware of the incident and outside of the 72h for a preliminary report. Notebaly Comment 3 on 2026-05-08 is not a preliminary report, however one did appear in Comment 5 which is 22 days after becoming aware.

An alleged full incident report is then posted on 2026-05-08 in Comment 6. It is rife with issues that stick to the latest report, but let's focus on the 233 remaining valid certificates at time of the report.

• 'Source of incident disclosure' alleges 'PKIMetal', which implies VISA are performing linting. Instead the actual source is a Third Party report who used PKIMetal. This is disingenuous and implies a level of foresight and proactiveness that is not shown in the rest of this incident.

• Timeline states an internal investigation starts on 2026-04-17, a different awareness date and notably a complete lack of followup.

• Related incidents is just this incident.

Questions were raised on 2026-05-27 that are still unanswered to this day.

The latest 'full' incident report now attempts to redefine the previous investigation: 38 TLS server certs, 86 "Internal" server certs, and 109 client auth certs. This is a departure from the previous report on affected certificates at 124.

Bizarrely despite claiming 124 certificates are impacted we only get a list of serial numbers for 38. VISA should be aware that even if a certificate is used internally, it truly does not matter for compliance purposes, disclosure, and revocation requirements.

The alleged revocation dates on 2026-06-30 and 2026-07-30 for "TLS Server" and "Internal Server" are wholy inadequate and further cement that VISA are not paying attention nor capable of operating as a public CA.

The new timeline now gives us a certificate profile update date of 2026-06-02. Therefore no remediation was done for the original 'full' incident report at all. This is further evident with the lack of revocations.

Related incidents still miraculously are unable to find any other CA having a linting issue or delayed revocation incident. This highlights the complete lack of duty to pay attention other CAs in the space, or to be capable of a modicum amount of research in creating this report weeks late.

Root Cause Analysis is where two new Contributing Factors appear (2, 3) that are frankly separate incidents. We've had a full incident report for this incident, and the CA was unable to fully remediate their issues until prompted by a member of the community here.

Lessons learned makes it clear VISA does not understand certificate issuance. The usage of the certificates does not matter when they chain up to a public root. They are all still required to meet the baseline requirements.

To that end I suggest the following:

• Revocation of all 233 affected certificates within 5 days. VISA should in theory have a mass revocation plan for this large amount of certificates and this would show they are capable of performing when a mass key compromise occurs.

• A new full incident report where VISA actually read the CCADB Incident Reporting Guidelines and pay attention to what each section is for. This is detailed thoroughly in the Incident Reporting section, and the disregard for the effort put into those guidelines reflects the attention the CA is paying.

• VISA should read incidents in the past two years and formulate a report on lessons learned. Linting is the tip of the iceberg as far as issues apparent here, and it is clear that there are more problems that need addressed.

• New incident is required to be raised for the delayed revocation of these certificates.

• Likewise that would necessitate sticking to the CCADB Incident Reporting Guidelines that are MUST:

For incidents affecting less than 10,000 certificates, a CA Owner MUST attach a comma separated listing of certificate details including the following fields for each:

So far in this incident we have reports that emulates the format but ignores the intent of each field that is clearly laid out. There are far more issues but that should be understood by the CA as they read the policy and put it into practice.

Comment 16

[incident-reporting]

This report remains incomplete and has gone stale.

Additionally, there are outstanding questions from the community, which are expected to be addressed in a timely manner.

VISA, please take action.

Comment 17

[chrome-root-program]

The CA Owner subject of this report has had ample time and opportunity to adhere to the requirements defined in the CCADB Policy and Incident Reporting Guidelines. Despite prior reminders and explicit ecosystem obligations (example), the CA Owner has continuously chosen not to meet well established and well documented expectations.

Because the CA Owner has demonstrated a persistent unwillingness to meet basic incident reporting expectations, we recommend closing this bug as RESOLVED / WONTFIX.

Please be advised that the Chrome Root Program maintains a record of this unaddressed non-compliance. Should this CA Owner apply for inclusion in the Chrome Root Store in the future, this deliberate failure to fulfill basic incident reporting obligations will be evaluated as direct commentary on the CA Owner's reliability and commitment to ecosystem expectations.