https://planetarycomputer.microsoft.com (and at least /api/stac/v1/search) is presenting a TLS certificate for *.azureedge.net rather than one covering planetarycomputer.microsoft.com. Every HTTPS client that validates the certificate hostname (browsers, curl, Node's fetch) fails the handshake, so the site and API are effectively unreachable.
This looks like the custom-domain TLS binding on the Azure Front Door endpoint fronting this domain has dropped back to Front Door's default certificate.
Reproduction
$ curl -sv https://planetarycomputer.microsoft.com/api/stac/v1/collections/naip
...
- Server certificate:
- subject: C=US; ST=WA; L=Redmond; O=Microsoft Corporation; CN=*.azureedge.net
- start date: Aug 28 04:41:19 2026 GMT
- expire date: Feb 24 04:41:19 2027 GMT
- subjectAltName does not match host name planetarycomputer.microsoft.com
- SSL: no alternative certificate subject name matches target host name 'planetarycomputer.microsoft.com'
$ dig +short planetarycomputer.microsoft.com
planetarycomputer.azurefd.net.
mr-azurefd.tm-azurefd.net.
150.171.110.3
Reproduced consistently across multiple attempts over several minutes, from a plain network connection with no proxy, VPN, or custom DNS/hosts entries involved — so this isn't local interception, it's the certificate Front Door itself is serving.
Impact
Any client calling the STAC search API (POST /api/stac/v1/search) gets a hard TLS failure before the request is even sent, e.g. from Node:
fetch failed -> Hostname/IP does not match certificate's altnames: Host: planetarycomputer.microsoft.com. is not in the cert's altnames: DNS:*.azureedge.net (ERR_TLS_CERT_ALTNAME_INVALID)
Environment
- Client: macOS, curl 8.x and Node.js fetch
- Date/time observed: 2026-09-15
- No proxy, VPN, or /etc/hosts overrides in play
https://planetarycomputer.microsoft.com (and at least /api/stac/v1/search) is presenting a TLS certificate for *.azureedge.net rather than one covering planetarycomputer.microsoft.com. Every HTTPS client that validates the certificate hostname (browsers, curl, Node's fetch) fails the handshake, so the site and API are effectively unreachable.
This looks like the custom-domain TLS binding on the Azure Front Door endpoint fronting this domain has dropped back to Front Door's default certificate.
Reproduction
$ curl -sv https://planetarycomputer.microsoft.com/api/stac/v1/collections/naip
...
$ dig +short planetarycomputer.microsoft.com
planetarycomputer.azurefd.net.
mr-azurefd.tm-azurefd.net.
150.171.110.3
Reproduced consistently across multiple attempts over several minutes, from a plain network connection with no proxy, VPN, or custom DNS/hosts entries involved — so this isn't local interception, it's the certificate Front Door itself is serving.
Impact
Any client calling the STAC search API (POST /api/stac/v1/search) gets a hard TLS failure before the request is even sent, e.g. from Node:
fetch failed -> Hostname/IP does not match certificate's altnames: Host: planetarycomputer.microsoft.com. is not in the cert's altnames: DNS:*.azureedge.net (ERR_TLS_CERT_ALTNAME_INVALID)
Environment