Closed Bug 1895277 Opened 1 year ago Closed 4 months ago

Windows Firefox Kerberos authentication broken with Extended protection set to allow on ADFS server with a SHA384 SSL certificate

Categories

(Core :: Networking, defect, P2)

Firefox 125
defect
Points:
5

Tracking

()

VERIFIED FIXED
144 Branch
Tracking Status
firefox-esr140 --- fixed
firefox144 --- fixed

People

(Reporter: msmorris, Assigned: valentin)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged][necko-priority-queue])

Attachments

(2 files)

Steps to reproduce:

  1. Upgrade ADFS Communication and SSL certificate to SHA384
  2. Verify that ExtendedProtectionCheck is set to Allow on the ADFS service. Get-AdfsProperties| select ExtendedProtectionTokenCheck
  3. From a Domain Joined Windows client attempt to access a SAML configured website using Windows Firefox from internal network.

Actual results:

User is greeted with a prompt for username and password.
Manually entering the username and password fails and leads to the same prompt from the ADFS server.

Similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1179722 but specific only when using SHA384 certificate.

Expected results:

The user should have been directed to the ADFS server and complete the authentication using Windows Integrated Authentication.
User should have then been redirected to the website with the appropriate authentication and access

The Bugbug bot thinks this bug should belong to the 'Core::Security: PSM' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Security: PSM
Product: Firefox → Core

The severity field is not set for this bug.
:keeler, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(dkeeler)
Component: Security: PSM → Networking
Flags: needinfo?(dkeeler)
Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged][necko-priority-next]

Mike - how important would this be to enterprises?

Flags: needinfo?(mozilla)

I think it will be more of an issue as more folks roll out Extended Protection, so it definitely is important for enterprise.

It looks like bug 1179722 was the same issue, but they ended up reverting back to 256 temporarily.

Flags: needinfo?(mozilla)

This feels quite important. I’ll give this bug a higher priority and hope to see it resolved soon.

Points: --- → 5
Rank: 1
Duplicate of this bug: 1179722

Just for reference because of other issues we were finally forced to upgrade to a SHA384 certificate for our adfs/ identity server. This has effectively broken functionality on Firefox now.

My organization is also forced to temporarily downgrade to SHA256 for our ADFS server. After 1-1-2026 we are forced to use SHA384, so please resolve this as soon as possible.

Whiteboard: [necko-triaged][necko-priority-next] → [necko-triaged][necko-priority-queue]

I think this comment may point to the culprit:
https://searchfox.org/mozilla-central/rev/270c20e4b063d80ce71f029b4adc4ba03a12edc0/extensions/auth/nsAuthSSPI.cpp#366-383

// Start hashing. We are always doing SHA256, but depending
// on the certificate, a different alogirthm might be needed.
nsAutoCString hashString;

nsresult rv;
nsCOMPtr<nsICryptoHash> crypto;
crypto = do_CreateInstance(NS_CRYPTO_HASH_CONTRACTID, &rv);
if (NS_SUCCEEDED(rv)) rv = crypto->Init(nsICryptoHash::SHA256);
if (NS_SUCCEEDED(rv))
  rv = crypto->Update((unsigned char*)mCertDERData, mCertDERLength);
if (NS_SUCCEEDED(rv)) rv = crypto->Finish(false, hashString);
if (NS_FAILED(rv)) {
  free(mCertDERData);
  mCertDERData = nullptr;
  mCertDERLength = 0;
  free(sspi_cbt);
  return rv;
}
Assignee: nobody → valentin.gosu
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Hi Mervyn,

Could you check with this build and let me know if it fixes your issue when ExtendedProtection is on and off?
https://treeherder.mozilla.org/jobs?repo=try&revision=f5df60eedb97ab95c9cdf53a96a6f36510a0f589&selectedTaskRun=dZpd6YjXTQWpIm4Lw8o4Mg.0
Click on Artifacts and Debugging Tools and download either the installer setup.exe or the portable archive target.zip

Thanks!

Flags: needinfo?(msmorris)
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 144 Branch

Is this able to be backported to the ESR?

QA Whiteboard: [qa-triage-done-c145/b144]

(In reply to Mike Kaply [:mkaply] from comment #15)

Is this able to be backported to the ESR?

Yes, it grafts cleanly to esr140.
I'd prefer to wait for confirmation the fix works before uplifting.

Confirmed working by Steve Rast via email. Will request uplift to ESR.

I am also affected. I tested now with 144.0b2 and can confirm that the login to ADFS with the new SHA384 certificate is working.

firefox-esr140 Uplift Approval Request

  • User impact if declined: Failure to log into Active Directory Federation Services when the SSL certificate uses SHA384
  • Code covered by automated testing: no
  • Fix verified in Nightly: yes
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing: Ideally QE would be necessary, but I'm not sure if anyone in QA has access to an active directory setup
  • Risk associated with taking this patch: low
  • Explanation of risk level: Aready confirmed working by reporters.
  • String changes made/needed: None
  • Is Android affected?: no
Attachment #9514025 - Flags: approval-mozilla-esr140?

Good day.

Sorry it took so long to respond.

I have successfully tested Nightly 143.0a1 (2025-09-03) (64-bit) and verified that the issue is resolved when accessing a website using ADFS with a SHA384 ADFS certificate.

Flags: needinfo?(msmorris)

(In reply to Mervyn Morris from comment #20)

I have successfully tested Nightly 143.0a1 (2025-09-03) (64-bit) and verified that the issue is resolved when accessing a website using ADFS with a SHA384 ADFS certificate.

Thank you! 🙏 We really appreciate your help with this one!

Status: RESOLVED → VERIFIED
Attachment #9514025 - Flags: approval-mozilla-esr140? → approval-mozilla-esr140+
See Also: → 1781743
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: