Resource synchronization jobs fail after Azure AD certificate rotation

MES DELMIA Apriso MES
, , , , , , , ,
1

We recently rotated our Azure AD certificates as part of our security compliance process, and now all resource synchronization jobs are failing with AADSTS700027 errors. The resource-mgmt module was working perfectly before the certificate rotation.

Error from logs:


AADSTS700027: Client assertion failed signature validation
Timestamp: 2025-03-15 08:45:12 UTC
Resource: https://graph.microsoft.com

The Azure AD certificate rotation was completed yesterday, and we updated the thumbprint in our cloud configuration. However, the sync jobs continue to fail. We’re running dam-2021 in Azure Kubernetes with OAuth authentication. Our production resource sync is completely blocked, and we can’t update resource availability or assignments. Has anyone dealt with Azure AD certificate issues after rotation in a cloud deployment?

2

Yes, there’s usually a token cache that needs to clear. The intermittent failures suggest some pods are still using cached tokens signed with the old certificate. Try these steps in order:

  1. Force a rolling restart of ALL pods in the namespace (not just resource-mgmt)
  2. Clear the Redis cache if you’re using one for token storage
  3. Wait 15-20 minutes for Azure AD token cache to expire naturally
  4. Monitor the logs for any pods still showing the old certificate thumbprint

The authentication flow needs time to fully propagate through all layers of the cloud infrastructure.

3

I’ve seen this before. The AADSTS700027 error typically means the application registration still has references to the old certificate. Did you update both the certificate thumbprint AND the actual certificate file in your Kubernetes secret? Sometimes updating the config alone isn’t enough - you need to restart the pods to pick up the new certificate.

4

Thanks Sarah. I updated the thumbprint in our cloud config file but didn’t think about the Kubernetes secret. I’ll check that now. Are there specific pods that need to be restarted for resource-mgmt authentication changes?

5

Also verify in Azure Portal that the old certificate has been properly removed from the app registration. Sometimes both certificates coexist during rotation, and the system might still be trying to use the old one. Go to Azure AD > App registrations > Your app > Certificates & secrets and confirm only the new certificate is listed. The cloud config update needs to match exactly what’s in Azure.

6

We had a similar authentication issue after certificate rotation. The problem was the certificate wasn’t being loaded correctly from the Kubernetes secret. Make sure your deployment yaml references the correct secret name and key. Also check the secret encoding - it should be base64 encoded PFX or PEM format depending on your setup.

7

Update: I found the issue. The Kubernetes secret was still pointing to the old certificate file. I recreated the secret with the new certificate, but the pods weren’t picking it up automatically. After manually restarting the resource-mgmt deployment pods, I’m still seeing intermittent failures. Should there be a grace period or cache clearing step?