Domain delegation not fully respected

[HAT-mkl]

Describe the bug
lk-jwt-service seems to follow configured domains in .well-known/matrix/server but fails to adjust the query string. The error I receive is: Failed to look up user info: Get "matrix://example.org/_matrix/federation/v1/openid/userinfo?access_token=<REDACTED>": tls: failed to verify certificate: x509: certificate is valid for proxy1.int.example.org, not example.org

To Reproduce
Steps to reproduce the behavior:

1. Setup Nginx and Synapse as described in the context section
2. Configure delegation as described in the context section
3. Try to start call.

Expected behavior
The call is correctly established.

Desktop (please complete the following information):

• Ubuntu 24.04 LTS
• Element Desktop 1.12.0

Smartphone (please complete the following information):

• Device: Pixel 8a
• OS: GrapheneOS
• Element X 25.03.1

Additional context

I've got my homeserver running on chat.example.org, the servername is set to example.org. I've correctly set up example.org/.well-known/matrix/server to return chat.example.org:443 and federation with foreign homeservers works flawlessly.

The homeserver on chat.example.org is proxied by Nginx (internal name: proxy1.int.example.org), which is a different server than the one serving example.org (and thus example.org/.well-known/matrix/server). The proxy server's default server block uses a self-signed certificate for domain "proxy1.int.example.org", and it has no server block for example.org (thus all requests for example.org are catched by the default server proxy1.int.example.org)

[katzecz]

I'm experiencing the same issue:

2025/10/23 21:38:55 Failed to look up user info: Get "matrix://example.org/_matrix/federation/v1/openid/userinfo?access_token=<REDACTED>": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

[justinbrick]

I had this issue, and checked the code. It is actually doing proper well-known delegation.
One thing I noticed, however, is that when delegation fails, it silently fails, and uses the passed domain as the default - basically assuming the token's claimed matrix server IS the delegation server.
Try checking your DNS settings on whatever networking you're using, and it should resolve itself.

With that being said, I think it's worth maybe adding a log for warning when well-known doesn't resolve properly. Looking at the Go client, it doesn't seem to be terribly hard, but also I've never used Go before.

[HAT-mkl]

Try checking your DNS settings on whatever networking you're using, and it should resolve itself.

Right now I've got no clue at all.
Federation with foreign Matrix servers works flawlessly with my server running on chat.example.org and my Matrix domain being example.org (e.g. @john.doe:example.org).

You say you had the issue as well - what did you do to solve it?

[TeamMasse]

I get an error that might be related to this.

Failed to look up user info: Get "matrix://example.org/_matrix/federation/v1/openid/userinfo?access_token=****************": dial tcp servers_public_ip:8448: connect: connection refused

I tried with curl matrix://example.org/_matrix/... doesn't work but matrix://matrix.example.org/_matrix/... does. How can I check if it uses my .well-known/matrix/server properly? And is this a proper .well-known?

{
    "m.server": "matrix.thefischer.org:8448"
}

Wouldn't the quickest way to fix be just another environment variable MATRIXSERVER which is used if set to get the userinfo?

[HAT-mkl]

Thanks for your PR, @TeamMasse - I discovered the same as you did, but simply hardcoded the domain.

@justinbrick it follows the .well-known delegation, but it still uses the (incorrect) servername (example.org instead of chat.example.org)

Also I had an error because of a setting I changed months ago in my Synapse configuration - enabling the ".well-known" file option. As soon as I set this option to false again, everything worked.

If I am not mistaken, using the wrong domain for the certificate check is a problem in the fclient package (from gomatrixserverlib) and not in the lk-jwt-service code itself.

[justinbrick]

Thanks for your PR, @TeamMasse - I discovered the same as you did, but simply hardcoded the domain.

@justinbrick it follows the .well-known delegation, but it still uses the (incorrect) servername (example.org instead of chat.example.org)

Also I had an error because of a setting I changed months ago in my Synapse configuration - enabling the ".well-known" file option. As soon as I set this option to false again, everything worked.

If I am not mistaken, using the wrong domain for the certificate check is a problem in the fclient package (from gomatrixserverlib) and not in the lk-jwt-service code itself.

I checked the code to troubleshoot this when I originally made this statement so I do believe you are mistaken. The Go Matrix server library follows the well-known and does proper delegation to the server after. You might be caught up in another area where it is failing, as after checking the code I have noticed that it silently fails, instead of giving more explicit errors. I would recommend running a troubleshooting setup if you're using Docker or Kubernetes to pinpoint where you're having issues. If it was truly failing to follow well-known for delegation then this would be an issue for much more people.

[HAT-mkl]

But why does it work then as soon as I override the "token.ServerName" parameter when the UserLookUp is done?

My error message - at least to me - clearly indicates that the TLS SNI fails. It uses the wrong "expected" domain name (not the one to which .well-known config delegates, but the original one, the servername).

If it was truly failing to follow well-known for delegation then this would be an issue for much more people.

Maybe this depends on some internal logic of the OS?

[justinbrick]

But why does it work then as soon as I override the "token.ServerName" parameter when the UserLookUp is done?

My error message - at least to me - clearly indicates that the TLS SNI fails. It uses the wrong "expected" domain name (not the one to which .well-known config delegates, but the original one, the servername).

Reading your explanation, you've explained it yourself - your server is serving traffic for the internal domain under the root domain. Because the initial request for well-known fails, it silently fails and then falls back to the root domain. This causes the issue you describe.
Since you are using some form of internal DNS, it would be worth checking to see what example.org/.well-known/matrix/server resolves to from inside of your network, if it does resolve it at all. You will likely find one of 2 issues happening:

• your DNS resolves internally to an external IP address representing your server, which your server may not support since it's sending a request to itself (see: hairpinning)
  this is the one most likely, as you have described it works fine with foreign servers. this is because it is resolving to external IPs.
  a bodge which you can do is having your hosts file resolve that domain to 127.0.0.1 for supported loopback.
  a more "proper" solution would be to change your router or firewall to support sending back those requests to server. i don't think there's a right answer here, but realize that if you do this you are effectively doing one hilariously long no-op to send messages back to yourself.

• you are not actually serving anything on .well-known/matrix/server
  this one is less likely, but still a possibility, as you will only ever see it working on foreign servers if they have their well known properly configured.

If it was truly failing to follow well-known for delegation then this would be an issue for much more people.

Maybe this depends on some internal logic of the OS?

I'm not sure what OS you are using, but I can assure you with high certainty that this is not an OS-specific behavior. HTTP/S, DNS resolution, and all others are well defined behaviors that are defined by the IETF and resolve properly on all operating systems (linux, windows, bsd).

[rexbron]

@TeamMasse https://federationtester.matrix.org/ will give you some info.

Failed to look up user info: Get "matrix://example.org/_matrix/federation/v1/openid/userinfo?access_token=****************": dial tcp servers_public_ip:8448: connect: connection refused

Adding my experience debugging the same error. Running the lk-jwt service on the host worked but in a rootless podman container it failed.

With podman's rootless networking, it maps the host IP to the container by default as of version 5.3. The default route to host in the container is: 169.254.1.2

Adding to the .container definition:

AddHost=<example.org>:169.254.1.2

routes the userinfo lookup to the host's reverse proxy and then onto the correct container.

[KevGamesUltimate]

Hey there, i just got the exact same problem. Everything worked a week ago, but today i found out, that can't i utilize element calls anymore. Element Desktop gives me a weird Error: MatrixError: [500] Failed to look up user info from homeserver (https://rtc.matrix.domain.com/livekit/jwt//sfu/get) when joining a videochat, but looking at the logs, it seems like jwt is ignoring the delegation.:

synapse-jwt  | 2026/07/12 22:15:00 Failed to look up user info: Get "matrix://domain.com/_matrix/federation/v1/openid/userinfo?access_token=<TOKEN>": dial tcp <WRONG IP>:8448: i/o timeout
synapse-jwt  | 2026/07/12 22:15:00 Error processing request: Failed to look up user info from homeserver

The fact that it worked before gives me headaches. Any suggestion?

[rexbron]

Did you you update recently?

https://rtc.matrix.domain.com/livekit/jwt//sfu/get

The double slash in the URL can cause problems with NGINX as reverse proxy.

Hard to diagnose without the actual set up but check the release notes as there have been breaking config changes in 0.5.0 with regards to LIVEKIT_FULL_ACCESS_HOMESERVERS

https://github.com/element-hq/lk-jwt-service/releases

>= 0.4.3 needs a compatible Element-Call:

Compatible: Element Call v0.19.2 or higher AND lk-jwt-service v0.4.3 or higher
Incompatible:

    Element Call v0.19.1 or lower AND lk-jwt-service v0.4.3 or higher
    Element Call v0.19.2 or higher AND lk-jwt-service v0.4.2 or lower

[KevGamesUltimate]

So, I completely rebuild the whole element call setup on my instance and found out, that for some reason, Element Desktop is not using the correct URL of the RTC Backend. It is possible to enter a custom JWT URL with the development tools in Element Desktop.

After entering my own RTC Backend URL - everything works. But i can't pinpoint where the issue is or where to look at. JWT and Livekit works, the federation and delegation works and i got no errors from federation testers. So I am currently clueless where to look at now. I'll post my solution, if I find one.