It starts innocently enough. You're auditing certificates in Azure AD when you notice the red flag: "EXPIRED" next to your SAML certificate. Has been for months, apparently.
Your first thought: "oh no, authentication must be broken..."
Your second thought: "wait... why is everyone still logging in?"
Welcome to the SAML certificate twilight zone, where expired certificates live forever and security teams question reality.
The "this can't be right" moment
You dig deeper into your monitoring (because you're responsible like that) and confirm the timeline: AWS OpenSearch SAML certificate expired back in August. It's now well into the future, and yet...
- Users are happily logging in.
- No error messages anywhere.
- No angry Teams/Slack messages from the team.
- Your monitoring dashboards show everything green.
So naturally, you do what any rational person would do: you panic and assume you're missing something obvious.
The "let me fix this" disaster
Being the helpful engineer you are, you decide to "fix" the problem. You grab the tenant wide metadata (the one with shiny new certificates valid until 2030) and update your AWS OpenSearch.
Result: instant authentication meltdown.
HTTP/2.0 500
Error: Signature validation failed. SAML Response rejected
Users can't log in. Colleagues start to ping you. You quickly revert to the expired certificate and... everything works again.
Plot twist: The "broken" expired certificate was actually the correct one.
This is where things get interesting. You start digging and discover that SAML certificates live in their own special universe where normal rules don't apply.
- SSL Certificate expires: browser throws a tantrum, shows scary warnings, users panic.
- SAML Certificate expires: crickets chirping, everything continues working like nothing happened.
The technical reality check
Here's what's actually happening (and why it's both clever and concerning):
- Azure/Entra AD: "This certificate is expired, but hey, it still signs things mathematically"
- AWS OpenSearch: "I can verify this signature cryptographically, expiration date is just a suggestion"
- Your security team: "Why is our compliance dashboard lighting up?"
The vendor validation tour
Microsoft Support, with the enthusiasm of someone explaining why water is wet:
"If your application doesn't have any validation for the certificate's expiration and the certificate matches in both Azure AD and your application, your application is still accessible despite having an expired certificate."
Translation: "Working as intended, deal with it."
AWS Support, not to be outdone:
"AWS IAM does not invalidate SAML Responses that are signed using an expired X.509 certificate. The SAML specification itself does not strictly require expiration date validation."
Translation: "This is how SAML works everywhere, not just here."
Then Microsoft drops this gem in their official documentation (appearing not once, but twice because they really want you to get it):
"If your app lacks certificate expiration validation and the certificate matches both Microsoft Entra ID and your app, it remains accessible. This condition is true even if the certificate is expired."
So it turns out this isn't a bug or an oversight. It's a documented behavior that happens to contradict what most people expect.
The "why should I care?" reality check
You're living in a compliance gray area where:
- Technical reality: everything works perfectly.
- Audit reality: you're using expired certificates.
- Security reality: it's not great, but it's not catastrophic either.
The monitoring mirage
Want to monitor your SAML certificate expiration in AWS? Here's what you get:
- CloudWatch metrics for SAML certificates: none
- OpenSearch configuration for strict validation: none
- Built-in AWS monitoring: none
AWS basically says: "Certificate monitoring is Azure's job, we just validate signatures."
Meanwhile, Microsoft offers email notifications at 60, 30 and 7 days before expiration. Which raises the obvious question: why bother setting up alerts for something that keeps working anyway?
The answer: because your compliance auditor doesn't care about SAML protocol nuances.
The infrastructure reality
If you're managing this with CloudFormation, you're in for extra fun since it only supports hardcoded XML metadata content, no URL references like Terraform has for years.
So while your expired certificate keeps working, you still need to manually update CloudFormation templates every time you renew certificates.
I submitted a feature request in September 2023 for URL support. The GitHub roadmap now shows it as "Shipped" but the AWS documentation hasn't been updated to reflect this.
Here's the thing: your expired SAML certificate working is like finding out your car runs fine without oil changes: technically possible, not recommended and definitely not something you want to explain to your manager.
Follow Microsoft's renewal process - it takes a few minutes and prevents uncomfortable audit conversations.
Built entirely with Amazon Q CLI.