modelcontextprotocol / modelcontextprotocol/registry

HTTP authentication verification fails due to unreachable verification endpoint / missing egress IP documentation

Open
#1,625 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Go
Stars
7.3k
Forks
994
Avg merge
4d 12h
Merged PRs (30d)
19

Description

Describe the bug

HTTP authentication login fails because the MCP Registry cannot fetch the public key verification file from the registered domain.

The domain is correctly configured according to the HTTP authentication flow:

  • /.well-known/mcp-registry-auth is publicly accessible
  • The response format is correct (v=MCPv1; k=ed25519; p=...)
  • The endpoint returns HTTP 200
  • The same endpoint is reachable from multiple networks

However, during the authentication flow, the Registry backend fails to fetch the verification file and returns a timeout error.

This appears to be related to Registry outbound connectivity or missing documentation about the Registry verification request source IPs.

To Reproduce

Steps to reproduce the behavior:

  1. Configure HTTP authentication for a domain.
  2. Publish the verification file at:

https://example.com/.well-known/mcp-registry-auth

  1. Run:

mcp-publisher login http --domain "example.com" --private-key "<private-key>"

  1. Observe that authentication fails when the Registry tries to fetch the public key.

Expected behavior

The MCP Registry should successfully fetch the HTTP authentication verification file and complete the login flow.

If the Registry requires specific network access rules, the documentation should describe:

  • Registry outbound/egress IP ranges
  • Required firewall/CDN allowlist configuration
  • Connectivity requirements for /.well-known/mcp-registry-auth

Logs

Command:

mcp-publisher login http --domain "tamin24.ir" --private-key "XX"

Output:

Logging in with http...

Signing in process using key algorithm ed25519

Expected proof record:

v=MCPv1; k=ed25519; p=gvexpyDRgdRQV7mn7lPmSvbKTA2Clbs32kcky72L8dc=

Error:

failed to get token: failed to exchange http signature: token exchange failed with status 401

HTTP authentication failed:

failed to fetch keys:
failed to fetch public key:
failed to fetch key:
Get "https://tamin24.ir/.well-known/mcp-registry-auth":
dial tcp 185.143.233.238:443: i/o timeout

The verification endpoint is reachable:

curl https://tamin24.ir/.well-known/mcp-registry-auth

Response:

v=MCPv1; k=ed25519; p=gvexpyDRgdRQV7mn7lPmSvbKTA2Clbs32kcky72L8dc=

Additional context

The domain is behind ArvanCloud CDN.

Additional tests:

  • TLS certificate is valid.
  • DNS resolution is correct.
  • Both CDN edge IPs respond successfully:

185.143.233.238

185.143.234.238

Both of the following tests return HTTP 200:

curl --resolve tamin24.ir:443:185.143.233.238 https://tamin24.ir/.well-known/mcp-registry-auth

curl --resolve tamin24.ir:443:185.143.234.238 https://tamin24.ir/.well-known/mcp-registry-auth

The registry endpoint appears to run on Google Cloud infrastructure, but no official documentation was found regarding the outbound IP addresses used for HTTP authentication verification requests.

It would be helpful to document the expected egress IP ranges or provide more detailed diagnostics for failed verification fetches.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the HTTP authentication login flow invoked by mcp-publisher login http and the Registry fetch of /.well-known/mcp-registry-auth; inspect outbound request diagnostics against the reported timeout and successful curl results. Done means the Registry can fetch the verification key for this case, or the required egress IP ranges, allowlist rules, and connectivity requirements are documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
authentication, backend, documentation, networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.