{"version":"2.1.301","anchor":"gateway-login-customer-allowlist-trust-path-for-tls-pinning","canonical_anchor":"gateway-login-customer-allowlist-trust-path-for-tls-pinning","heading":"Gateway login can trust administrator connections through a customer allowlist","tier":"notice","area":"Gateway Login","scope":"org","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.301\/e\/gateway-login-customer-allowlist-trust-path-for-tls-pinning","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.301","markdown":"### Gateway login can trust administrator connections through a customer allowlist\n\nIf the normal security check fails during an administrator's gateway login, Claude Code now checks a customer allowlist before giving up\n\n**Unclear.** It is not known where the allowlist comes from, or whether it holds any entries in this version.\n\n**What**\n\nWhen you log in through a gateway (a server that sits between Claude Code and the model service), Claude Code checks that the connection can be trusted. If that check fails and the login is for the \"administrator\" role, Claude Code now tries a customer allowlist before it gives up.\n\nTo do this it opens a secure (TLS) connection and compares these details against the allowlist:\n\n- The host name\n\n- The network range that the remote address belongs to\n\n- Optionally, a pinned root certificate, meaning one specific certificate authority that is trusted\n\nIf an entry matches, the login goes ahead and is recorded as allowlisted. When a root certificate is pinned, the connection check trusts only that one root.\n\n**Why**\n\nCompanies whose gateways run on private networks, or use their own certificate authority, can get past the trust check this way instead of failing it.\n\n- Area: Gateway Login\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 3\/5\n- Scope: org\n- Heads-up: no"}