{"id":16738,"date":"2026-02-17T13:30:36","date_gmt":"2026-02-17T13:30:36","guid":{"rendered":"https:\/\/dmsretail.com\/RetailNews\/changes-to-tls-clientauth-certificates-ensuring-youre-not-impacted\/"},"modified":"2026-02-17T13:30:36","modified_gmt":"2026-02-17T13:30:36","slug":"changes-to-tls-clientauth-certificates-ensuring-youre-not-impacted","status":"publish","type":"post","link":"https:\/\/dmsretail.com\/RetailNews\/changes-to-tls-clientauth-certificates-ensuring-youre-not-impacted\/","title":{"rendered":"Changes to TLS clientAuth Certificates: Ensuring You\u2019re Not Impacted"},"content":{"rendered":"

\"Retail<\/a><\/p>
\n<\/p>\n

\n

Cisco customers and partners\u00a0who use\u00a0Cisco equipment and services must be aware of important upcoming changes to public TLS certificates used for client authentication,\u00a0driven by browser security policies such as those from Google Chrome. These changes affect certificates\u00a0containing\u00a0the Client Authentication Extended Key Usage (EKU) and require careful management of certificate trust stores to avoid service disruptions.<\/p>\n

This article explains the changes, the role of trust stores, how to verify and update them, and steps to ensure your systems\u00a0remain\u00a0secure and operational.<\/p>\n

Important Note:<\/strong>\u00a0This does NOT affect certificates that are issued by private PKI.<\/p>\n

What is Extended Key Usage (EKU) and Why It Matters<\/h2>\n

Extended Key Usage (EKU) defines the specific purposes for which a digital certificate can be used. Two\u00a0common\u00a0EKUs in TLS certificates are:<\/p>\n

    \n
  • Server Authentication (OID 1.3.6.1.5.5.7.3.1):\u202fThis EKU verifies a server\u2019s identity to clients, enabling secure HTTPS connections.<\/li>\n
  • Client Authentication (OID 1.3.6.1.5.5.7.3.2):\u202fThis EKU verifies a client\u2019s identity to a server, which is essential for mutual TLS (mTLS) where both parties authenticate each other.<\/li>\n<\/ul>\n

    Changes to Public TLS Certificates<\/h2>\n

    The\u00a0change,\u00a0to disallow public TLS certificates\u00a0from containing the\u00a0clientAuth<\/strong>\u00a0EKUs, was\u00a0initiated\u00a0by\u00a0Google Chrome\u2019s root store program\u00a0policies. This may work fine within the boundaries of\u00a0web-browsing.\u00a0\u00a0However,\u00a0Cisco\u2019s ecosystem\u00a0has different security requirements which include\u00a0trusting\u00a0root certificates for its services and equipment to securely authenticate\u00a0both\u00a0clients and servers.<\/p>\n

    Important facts:<\/p>\n

      \n
    • From\u202fJune 15, 2026<\/strong>, public Certificate Authorities (CAs)\u00a0within Google Chrome\u2019s root store\u00a0will stop issuing TLS certificates\u00a0containing\u00a0both\u00a0serverAuth\u00a0and\u00a0clientAuth\u00a0EKUs.<\/li>\n
    • Certificates issued before this date remain valid until\u00a0their\u00a0expiration, even beyond June 15, 2026.<\/li>\n
    • Cisco\u2019s publicly\u00a0accessible Trusted\u00a0Root\u00a0Store bundles will include Root CAs needed for\u00a0clientAuth\u00a0validation.<\/li>\n<\/ul>\n

      Certificate Authority (CA) and EKU Mapping for Cisco Services<\/h2>\n

      If\u00a0Cisco customers\u00a0and partners are currently\u00a0utilizing\u00a0the\u00a0clientAuth\u00a0EKU in certificates, then it is important\u00a0to verify that\u00a0the\u00a0trust store includes\u00a0Root CAs\u00a0that will continue to include the\u00a0clientAuth\u00a0EKU.\u00a0<\/p>\n

      Cisco manages its own publicly\u00a0accessible Trusted\u00a0Root\u00a0Store\u00a0bundles<\/strong>\u00a0tailored for\u00a0various types\u00a0of services. These bundles include the necessary Root CAs to\u00a0validate\u00a0certificates used in Cisco services, ensuring secure mutual authentication while aligning with browser root store policies.<\/p>\n

      Click here for more information on Cisco\u2019s Trusted Root Stores\u00a0<\/p>\n

      Using\u00a0IdenTrust\u00a0and\u00a0Digicert\u00a0as examples, you can see how the industry is shifting from using the \u201cIdenTrust\u00a0Commercial Root CA 1\u201d and \u201cDigicert\u00a0Global Root G2\u201d towards different Root and Issuing\/Sub CAs.\u00a0\u00a0This is because the\u00a0aforementioned Root CAs\u00a0will remain in the Google Chrome root stores, where they are no longer allowed to issue certificates that\u00a0contain\u00a0the\u00a0clientAuth\u00a0EKU.<\/p>\n

      \n\n\n\n\n\n\n\n\n\n
      Solution\u00a0<\/strong><\/td>\nEKU Type<\/strong>\u00a0<\/td>\nRoot CA\u00a0<\/strong><\/td>\nIssuing\/Sub CA\u00a0<\/strong><\/td>\n<\/tr>\n
      IdenTrust\u00a0<\/td>\nclientAuth\u00a0<\/td>\nIdenTrust\u00a0Public Sector Root CA 1*\u00a0<\/td>\nTrustID\u00a0RSA\u00a0ClientAuth\u00a0CA 2\u00a0<\/td>\n<\/tr>\n
      IdenTrust\u00a0<\/td>\nclientAuth\u00a0+\u00a0serverAuth\u00a0<\/td>\nIdenTrust\u00a0Public Sector Root CA 1*\u00a0<\/td>\nIdenTrust\u00a0Public Sector Server CA 1\u00a0<\/td>\n<\/tr>\n
      IdenTrust\u00a0<\/td>\nserverAuth\u00a0(browser trusted)\u00a0<\/td>\nIdenTrust\u00a0Commercial Root CA 1\u00a0<\/td>\nHydrantID\u00a0Server CA O1\u00a0<\/td>\n<\/tr>\n
      DigiCert\u00a0<\/td>\nclientAuth\u00a0<\/td>\nDigiCert Assured ID Root G2*\u00a0<\/td>\nDigiCert Assured ID Client CA G2\u00a0<\/td>\n<\/tr>\n
      DigiCert\u00a0<\/td>\nclientAuth\u00a0+\u00a0serverAuth\u00a0<\/td>\nDigiCert Assured ID Root G2*\u00a0<\/td>\nDigiCert Assured ID CA G2\u00a0<\/td>\n<\/tr>\n
      DigiCert\u00a0<\/td>\nserverAuth\u00a0(browser trusted)\u00a0<\/td>\nDigiCert Global Root G2\u00a0<\/td>\nDigiCert Global G2 TLS RSA SHA256\u00a0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

      This example illustrates the drive towards new Root CAs for\u00a0clientAuth\u00a0needs and the importance of verifying that your services trust them\u00a0in order to\u00a0successfully make TLS connections.\u00a0\u00a0<\/p>\n

      Note:<\/strong>\u00a0The\u00a0above\u00a0Root CAs are\u00a0all\u00a0included in Cisco\u2019s\u00a0Trusted\u00a0Root\u00a0Store bundles.\u00a0<\/p>\n

      For more details, see Cisco\u2019s trusted root store bundles:\u00a0
      Cisco Trusted Root Store Bundles Readme<\/p>\n

      Understanding Trust Stores and Their Importance<\/h2>\n

      A\u00a0trust store<\/strong>\u00a0is a collection of trusted Root CA certificates that your systems use to\u00a0validate\u00a0TLS certificates. To avoid disruptions:<\/p>\n

        \n
      • Ensure your\u00a0systems\u2019\u00a0trust stores include the correct Root CAs\u00a0like those\u00a0listed above.<\/li>\n
      • Regularly update trust stores to align with Cisco\u2019s publicly available bundles.<\/li>\n
      • Missing or outdated Root CAs in trust stores can cause certificate validation failures.<\/li>\n<\/ul>\n

        How to Verify What Is in Your Trust Store<\/h2>\n

        General Verification Steps<\/strong><\/p>\n

          \n
        • Identify\u00a0the trust store location used by your system or application.<\/li>\n
        • Use tools such as\u202fKeytool\u202f(Java),\u202fOpenSSL, or platform-specific utilities to list certificates in the trust store.<\/li>\n
        • Confirm that the\u00a0new\u00a0Root CAs\u00a0you will\u00a0utilize\u00a0for\u00a0clientAuth\u00a0needs\u00a0(e.g.,\u00a0IdenTrust\u00a0Public Sector Root CA 1, DigiCert Assured ID Root G2) are present.<\/li>\n<\/ul>\n

          How to Ensure You Are Not Impacted<\/h2>\n
            \n
          1. Audit Your Current Certificates and Trust Stores<\/strong>\u00a0
            Inventory all public TLS certificates, especially those used for\u00a0mTLS, and verify the EKUs they\u00a0contain. Confirm that your trust stores include the correct Root CAs.\u00a0\u00a0Contact your Certificate Authority partner (Digicert,\u00a0IdenTrust,\u00a0Sectigo, etc) to ensure you understand which Root CA\u00a0to trust\u00a0for\u00a0clientAuth.<\/li>\n
          2. Update Trust Stores Regularly<\/strong>\u00a0
            Align your trust stores with Cisco\u2019s publicly available trusted root store bundles.<\/li>\n
          3. Add Missing Root CAs to Trust Stores<\/strong>\u00a0
            If a required Root CA is missing, import it into your trust store.<\/li>\n
          4. Coordinate with Partners<\/strong>\u00a0
            Communicate with external partners to ensure their certificates and trust stores\u00a0comply with\u00a0the new standards.<\/li>\n
          5. Monitor Browser and CA Policy Changes<\/strong>\u00a0
            Stay informed about browser policies (e.g., Google Chrome) that enforce these changes\u00a0and\u00a0website\u00a0of your chosen Certificate Authority partner.<\/li>\n
          6. Test<\/strong>\u00a0
            Utilizing new CAs requires testing on both the Server and Client sides to ensure the new certificates are trusted.<\/li>\n<\/ol>\n

            By auditing your certificates and trust stores now and aligning with Cisco\u2019s trusted root store bundles, you can ensure your Cisco services and equipment continue to\u00a0operate\u00a0securely and without interruption.\u00a0\u00a0We encourage impacted organizations to\u202freview their current certificate usage\u202fand begin planning their migration well ahead of the deadlines.<\/p>\n

            Reference Document Links:<\/strong>\u00a0<\/p>\n

              \n
            1. CUCM Certificate Management and Change Notification \u2013 Cisco<\/li>\n
            2. Security Guide for Cisco Unified Communications Manager, Release 15 and SUs \u2013 Default Security<\/li>\n
            3. Secure Network Analytics SSL\/TLS Certificates Guide for Managed Appliances v7.5.3\u00a0<\/li>\n<\/ol>\n
              \n

              We\u2019d love to hear what you think! Ask a question and stay connected with Cisco Security on social media.<\/em><\/p>\n

              Cisco Security Social Media<\/mark><\/strong><\/p>\n

              LinkedIn
              Facebook
              Instagram
              X<\/a><\/p>\n<\/p><\/div>\n