Certificate Error When Connecting to api2.cursor.sh

Bug Reports
1

SSL Certificate Error When Connecting to api2.cursor.sh

Description

When attempting to connect to api2.cursor.sh, I’m receiving an SSL certificate verification error. The server is presenting a certificate for *.us-east-1.es.amazonaws.com instead of api2.cursor.sh.

Steps to Reproduce

  1. Attempting to connect to api2.cursor.sh:443
  2. SSL handshake occurs but fails during certificate verification
  3. Connection is closed with error: “SSL: no alternative certificate subject name matches target host name ‘api2.cursor.sh’”

Technical Details

The curl output shows:

  • Successfully connected to 18.210.68.197 (one of the resolved IPs for api2.cursor.sh)
  • TLSv1.2 connection established with ECDHE-RSA-AES128-GCM-SHA256
  • Certificate subject: CN=*.us-east-1.es.amazonaws.com
  • Certificate validity: Feb 21, 2025 to Mar 22, 2026
  • Error: subjectAltName does not match host name api2.cursor.sh

Impact

This prevents secure connections to the API, making it impossible to use any features that depend on this endpoint.

System Information

Version: 0.48.9 (Universal)
VSCode Version: 1.96.2
Commit: 61e99179e4080fecf9d8b92c6e2e3e00fbfb53f0
Date: 2025-04-12T19:19:47.994Z
Electron: 34.3.4
Chromium: 132.0.6834.210
Node.js: 20.18.3
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.3.0

Does this prevent you from using Cursor?

this error make me can’t interact with any AI Model，and i didn’t change any setting this problem just happened at that moment

2

Hi

I hit the exact same issue and it looks like some CloudFront edge IPs that api2.cursor.sh resolves to are presenting the wrong TLS certificate. Until the Cursor team finishes fixing those edges, the workaround below forces your machine to use a “good” edge IP—one that already serves the correct api2.cursor.sh cert.

Locate a IP with OpenSSL (macOS / Linux)

for ip in $(dig +short api2.cursor.sh); do
  echo -n "$ip  "
  openssl s_client -connect $ip:443 -servername api2.cursor.sh -brief < /dev/null 2>/dev/null \
    | grep subject=
done

Look for a line that prints subject=CN = api2.cursor.sh—for example:

3.227.202.252 subject=CN = api2.cursor.sh

Pin that IP in /etc/hosts

sudo sh -c 'echo "3.227.202.252  api2.cursor.sh" >> /etc/hosts'
sudo dscacheutil -flushcache         # macOS DNS cache
sudo killall -HUP mDNSResponder

Replace 3.227.202.252 with the IP you found.

image
image769×392 39.7 KB

This is only a temporary fix

When CloudFront shuffles traffic to new edges, that pinned IP may stop working or return a wrong cert again—you’ll need to repeat the steps with a new IP (or simply remove the hosts entry).

If you don’t want to touch the /etc/hosts files, you can try running Cursor through a VPN (WireGuard / OpenVPN) or enable DNS-over-HTTPS (e.g. Cloudflare 1.1.1.1). A tunnel avoids the broken edges

Hope this keeps you productive until the official fix lands!

1 Like
3

I had exactly the same issue! however none of the ips from a dig from my machine were serving the correct cert.
I resorted to a online dig tool to look up an ip list in the hope it hit a different edge location, it did and the first one of those IP’s worked great.