Broadcom SAML AuthnRequest Signing Certificate Renewal for VMC on AWS and Broadcom Cloud Console
search cancel

Broadcom SAML AuthnRequest Signing Certificate Renewal for VMC on AWS and Broadcom Cloud Console

book

Article ID: 458465

calendar_today

Updated On:

Products

VMware Cloud on AWS

Issue/Introduction

Broadcom is updating the SAML AuthnRequest Signing Certificate used by access.broadcom.com as part of its ongoing security practices.

This change affects customer Identity Provider (IDP) configurations used to access:

  • VMware Cloud on AWS Console (vmc.broadcom.com)
  • Broadcom Cloud Console (console.cloud.broadcom.com)

Starting November 20, 2026 at 5:00 PM PST, Broadcom SSO will begin signing SAML AuthnRequests using the new certificate.

Customers whose Identity Provider validates signed SAML authentication requests must ensure that the new Broadcom certificate is trusted before the cutover. If the IdP continues to trust only the current certificate, VMware Cloud on AWS Console or Broadcom Cloud Console login attempts may fail after the certificate rotation.

Environment

 

Products:

  • VMware Cloud on AWS Console
  • Broadcom Cloud Console

Authentication:

  • SAML Single Sign-On (SSO)
  • Broadcom SSO (access.broadcom.com)

Identity Providers may include:

  • Microsoft Entra ID
  • Okta
  • Ping Identity / PingOne / PingFederate
  • Other SAML-compatible Identity Providers

The required action depends on whether the Identity Provider automatically retrieves Broadcom SAML metadata or relies on a manually configured signing certificate.

 

Cause

Broadcom is rotating the certificate used to sign SAML AuthnRequests.

The existing certificate will be retired, and Broadcom SSO will begin signing SAML authentication requests with the new certificate on November 20, 2026 at 5:00 PM PST.

If an Identity Provider is configured to validate signed SAML requests but does not trust the new certificate, authentication will fail after the rotation.

Resolution

To prevent authentication disruption, review how the Identity Provider retrieves and validates Broadcom SAML signing certificates and complete the applicable steps before the certificate rotation.

Step 1 - Download the new certificate

The new certificate can be obtained from the Broadcom SAML metadata URL or from the certificate file provided with this Knowledge Base article.

Certificate file:
Download the new Broadcom SAML AuthnRequest Signing Certificate at the bottom of this KB (.crt)

Microsoft Entra ID

If "Require verification certificates" is not enabled, Microsoft Entra ID does not validate signed SAML requests. In that configuration, this certificate rotation does not affect authentication and no action is required.

If verification certificates are required, the new certificate must be manually uploaded. Entra ID does not automatically refresh the authentication request signing certificate from the Service Provider metadata file and supports multiple active verification certificates.

Before the cutover:

  1. Download the new Broadcom certificate.
  2. Sign in to the Microsoft Entra admin center using Cloud Application Administrator permissions or higher.
  3. Navigate to Identity > Applications > Enterprise applications > All applications.
  4. Open the VMC on AWS Service Provider application.
  5. Select Single sign-on.
  6. Locate SAML Certificates.
  7. Under Verification certificates, select Edit.
  8. Verify the Require verification certificates setting as appropriate for your configuration.
  9. Upload the new certificate.
  10. Select Save.

No manual action is required at the actual cutover if both certificates are present and trusted.

After confirming authentication is working normally:

  1. Return to the Single sign-on area for the Enterprise Application.
  2. Navigate to SAML Certificates.
  3. Under Verification certificates, select Edit.
  4. Select the previous Broadcom certificate.
  5. Delete the legacy certificate.
  6. Select Save.

Okta

Before the cutover, determine whether the Broadcom application is configured with a Signature Certificate.

  1. Go to Applications > Applications.
  2. Open the Broadcom application configured for VMC on AWS.
  3. On the General tab, locate SAML Settings and select Edit.
  4. Select Next.
  5. Select Show Advanced Settings.
  6. Review Signature Certificate.
  7. Review Signed Requests / Validate SAML requests with signature certificates.
  8. Select Cancel to exit without changing the configuration.

If a Signature Certificate is configured, it must be updated as part of the rotation and be done on November 20th, 2026.

To replace the certificate:

  1. In the Okta Admin Console, select Applications.
  2. Open the Broadcom application.
  3. Select the General tab.
  4. Under SAML Settings, select Edit.
  5. Select Next.
  6. Select Show Advanced Settings.
  7. Locate Signature Certificate.
  8. Select Browse files.
  9. Select the new .crt certificate.
  10. Select Upload Certificate.
  11. Select Next.
  12. Select Finish.

Ping Identity

Where supported, import the new certificate as a secondary verification certificate rather than immediately replacing the existing certificate.

This allows the current and new certificates to coexist during the transition and reduces the need to perform the replacement at the exact cutover time.

For PingOne for Enterprise:

  1. Navigate to Setup > Certificates.
  2. Locate the existing certificate.
  3. Open the Usage tab.
  4. Select the applicable connection.
  5. Import the new verification certificate when prompted.

For SAML IdPs:

  1. Navigate to Setup > Identity Repository.
  2. Edit the applicable configuration.
  3. Import the new verification certificate.
  4. When supported, configure it as the secondary verification certificate.

For PingFederate:

  1. Update the certificate in PingFederate.
  2. Push the changes to PingOne for Enterprise from the PingFederate Admin Console.

For SAML applications in PingOne for Enterprise and PingOne SSO for SaaS Apps:

  1. Navigate to Applications.
  2. Edit the applicable application configuration.
  3. Import the new verification certificate.
  4. When supported, configure it as the secondary verification certificate.

Some PingOne SSO for SaaS Apps IdP connections do not support secondary verification certificates. In these configurations, the certificate replacement must be coordinated with the Broadcom cutover.

Other Identity Providers

Systems that automatically retrieve SAML metadata

If the application dynamically retrieves Broadcom SAML metadata, verify that the SAML implementation processes the updated credentials and accepts the new certificate during the transition.

Verify that the application or SAML library can process both certificates and accepts the new ds:X509Certificate credential.

Systems using manually configured certificates

If the Identity Provider uses a fixed or manually uploaded signing certificate, download the new certificate before November 20, 2026 at 5:00 PM PST.

If the Identity Provider supports multiple trusted signing certificates:

  1. Add the new certificate to the trusted certificate list before the cutover.
  2. Keep the existing certificate in place during the transition.
  3. Confirm authentication after Broadcom begins using the new certificate.
  4. Remove the legacy certificate after successful validation.

If the Identity Provider does not support multiple certificates:

  1. Download the new certificate at the bottom of this KB (.crt) before the cutover.
  2. On November 20, 2026 at 5:00 PM PST, replace the existing certificate with the new certificate.

Additional Information

Emergency vCenter and NSX Access

The SAML certificate rotation does not affect direct access to vCenter or NSX management appliances.

Before the maintenance window, customers should record:

  • vCenter URLs
  • NSX Manager URLs
  • Emergency access URLs where applicable
  • Emergency credentials for Federated vCenter environments

These access methods can be used if SSO authentication is temporarily unavailable after the rotation.

Certificate Rotation Best Practices

Where possible, configure the Identity Provider to trust both the existing and new certificates before the cutover.

This allows the certificate transition to occur without requiring a configuration change at the exact cutover time.

After the cutover:

  1. Confirm that users can successfully authenticate.
  2. Confirm that the Identity Provider is validating requests using the new certificate.
  3. Remove the previous certificate after successful validation.

Attachments

access.crt get_app
Powered by Wolken Software