Windows 10 reached EOS (end of support) on October 14, 2025. For more information, see this article.

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Rohkem teavet

need help upgrading 140.5 to 140.7 (esr) - how to make 140.7.0esr work?

  • 1 vastus
  • 2 on selline probleem
  • Viimati vastas pmc1

more options

Hi, 48 hours ago I upgraded firefox 140.5.0(esr) to 140.7.0(esr), and now, 48 hours later, everything suddenly stopped to work and I cannot load pages anymore.

48 hours is the lifetime of my kerberos ticket. After 48 hours firefox should send a new ticket to the applications, but 140.7 doesn't. The ccache in the application is empty!

I downgraded back to 140.5, and immediately everything works again.

Was support for GSSAPI/kerberos/SPNEGO removed between 140.5 and 140.7, and why so? Otherwise, how do I get it to work again?

Hi, 48 hours ago I upgraded firefox 140.5.0(esr) to 140.7.0(esr), and now, 48 hours later, everything suddenly stopped to work and I cannot load pages anymore. 48 hours is the lifetime of my kerberos ticket. After 48 hours firefox should send a new ticket to the applications, but 140.7 doesn't. The ccache in the application is empty! I downgraded back to 140.5, and immediately everything works again. Was support for GSSAPI/kerberos/SPNEGO removed between 140.5 and 140.7, and why so? Otherwise, how do I get it to work again?

All Replies (1)

more options

I had the same error again.

I tried to connect the application server. It failed with a JSON exception.

I started a different FF profile (i.e. different process). It also failed. I issued a new kerberos ticket and restarted the FF. It still failed.

I restarted the application server. It still failed. The exact error on the server log is "Delegated credentials not supplied." and afterwards "Object of type Exception is not JSON serializable" and other bogus. The first message is obviousely the relevant one.

I rebooted another desktop machine also with FF 140.7esr installed and issued a new ticket there. It failed all the same.

I started tcpdump -A (full HTTP headers) and watched the traffic to the application server. A correct negotiation is happening:

- the client sends a HTTP request.
- the server answers with "HTTP/1.1 401 UNAUTHORIZED" and
  WWW-Authenticate: Negotiate
- the client then sends a new request with
  Authorization: Negotiate and ~1000 byte cipher material

I hacked into the server code to observe what is actually received in the (python) gssapi.sec_contexts.SecurityContext object. It is this:

  initiator_name = pmc@INTRA.PHASE23
     -> correct, that is me
  lifetime = 23895
     -> correct, that is the remaining lifetime
  target_name = HTTP/admn-e.intra.daemon.contact@INTRA.PHASE23
     -> correct, that is the application server
  delegated_creds = None
     -> not correct, missing.

I deinstalled FF 140.7esr on a desktop machine, and reinstalled FF 140.5esr. And the connection worked flawlessly on the first try. The delegated ticket was received and is now stored server-side.

Now deleting it and evaluating anew::

In tcpdump -A the Authorization: Negotiate header now contains

  ~2200 byte cipher material instead of 1000 byte.

And the server receives this:

  initiator_name = pmc@INTRA.PHASE23
  lifetime = 20718
  target_name = HTTP/admn-e.intra.daemon.contact@INTRA.PHASE23
  delegated_creds = <gssapi.creds.Credentials object at 0x2f31e737c760>


Please help me evaluate: what else can this be than a problem introduced in FF between 140.5esr and 140.7esr ?

I have two options set in the about:config:

 network.negotiate-auth.trusted-uris:      admn-e.intra.daemon.contact
 network.negotiate-auth.delegation-uris:   admn-e.intra.daemon.contact

But now things behave like when delegation-uris were not set!

Küsimuse postitamine

You must log in to your account to reply to posts. Please start a new question, if you do not have an account yet.