404 on all v0 & v1 Secure Endpoint API's

jimmypuckett · ‎12-17-2023

I am able to connect & use the v3 API (different cred/token, but proof I can work with an API), but I cannot get the v0 or the v1 API's to give me anything but a 404.

```
curl -v \
-H 'accept: application/json' \
-H 'content-type: application/json' \
--compressed -H 'Accept-Encoding: gzip, deflate' \
-u <client_id>:<api_key> \
https://api.amp.cisco.com/v1/computers
```

```
* Trying 192.111.4.8:443...

* Connected to api.amp.cisco.com (192.111.4.8) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN: server accepted h2
* Server certificate:
* subject: CN=amp.cisco.com; O=Cisco Systems Inc.; L=San Jose; ST=California; C=US
* start date: Jul 18 21:12:37 2023 GMT
* expire date: Jul 17 21:11:37 2024 GMT
* subjectAltName: host "api.amp.cisco.com" matched cert's "api.amp.cisco.com"
* issuer: C=US; O=IdenTrust; OU=HydrantID Trusted Certificate Service; CN=HydrantID Server CA O1
* SSL certificate verify ok.
* using HTTP/2
* Server auth using Basic with user '<REMOVED>'
* [HTTP/2] [1] OPENED stream for https://api.amp.cisco.com/v1/computers
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: api.amp.cisco.com]
* [HTTP/2] [1] [:path: /v1/computers]
* [HTTP/2] [1] [authorization: Basic <REMOVED>]
* [HTTP/2] [1] [user-agent: curl/8.4.0]
* [HTTP/2] [1] [accept: application/json]
* [HTTP/2] [1] [content-type: application/json]
* [HTTP/2] [1] [accept-encoding: gzip, deflate]
> GET /v1/computers HTTP/2
> Host: api.amp.cisco.com
> Authorization: Basic <REMOVED>
> User-Agent: curl/8.4.0
> accept: application/json
> content-type: application/json
> Accept-Encoding: gzip, deflate
>
< HTTP/2 404
< date: Sun, 17 Dec 2023 21:09:06 GMT
< content-type: application/json
< status: 404 Not Found
< cache-control: no-store
< strict-transport-security: max-age=63072000; includeSubDomains
< referrer-policy: strict-origin-when-cross-origin
< x-permitted-cross-domain-policies: none
< pragma: no-cache
< x-xss-protection: 1; mode=block
< x-request-id: 41e4a17c-6d44-4683-9a4b-d4e33c6f4077
< x-download-options: noopen
< x-frame-options: SAMEORIGIN
< x-content-type-options: nosniff
< expires: Fri, 01 Jan 1990 00:00:00 GMT
< content-encoding: gzip
<
* Connection #0 to host api.amp.cisco.com left intact
```

If I send a known bad client_id/api_key, then I get a 401, so I feel that my cred must be good

```
curl -v \
-H 'accept: application/json' \
-H 'content-type: application/json' \
--compressed -H 'Accept-Encoding: gzip, deflate' \
-u bad:key \
https://api.amp.cisco.com/v1/computers
* Trying 192.111.4.7:443...
* Connected to api.amp.cisco.com (192.111.4.7) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN: server accepted h2
* Server certificate:
* subject: CN=amp.cisco.com; O=Cisco Systems Inc.; L=San Jose; ST=California; C=US
* start date: Jul 18 21:12:37 2023 GMT
* expire date: Jul 17 21:11:37 2024 GMT
* subjectAltName: host "api.amp.cisco.com" matched cert's "api.amp.cisco.com"
* issuer: C=US; O=IdenTrust; OU=HydrantID Trusted Certificate Service; CN=HydrantID Server CA O1
* SSL certificate verify ok.
* using HTTP/2
* Server auth using Basic with user 'bad'
* [HTTP/2] [1] OPENED stream for https://api.amp.cisco.com/v1/computers
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: api.amp.cisco.com]
* [HTTP/2] [1] [:path: /v1/computers]
* [HTTP/2] [1] [authorization: Basic YmFkOmtleQ==]
* [HTTP/2] [1] [user-agent: curl/8.4.0]
* [HTTP/2] [1] [accept: application/json]
* [HTTP/2] [1] [content-type: application/json]
* [HTTP/2] [1] [accept-encoding: gzip, deflate]
> GET /v1/computers HTTP/2
> Host: api.amp.cisco.com
> Authorization: Basic YmFkOmtleQ==
> User-Agent: curl/8.4.0
> accept: application/json
> content-type: application/json
> Accept-Encoding: gzip, deflate
>
< HTTP/2 401
< date: Sun, 17 Dec 2023 21:22:52 GMT
< content-type: application/json
< status: 401 Unauthorized
< cache-control: no-cache
< x-ratelimit-limit: 200
< x-ratelimit-reset: 59
< strict-transport-security: max-age=63072000; includeSubDomains
< referrer-policy: strict-origin-when-cross-origin
< x-ratelimit-remaining: 199
< x-permitted-cross-domain-policies: none
< x-xss-protection: 1; mode=block
< x-request-id: 5d9b193b-a1c3-4b46-9115-eb1577099f06
< x-download-options: noopen
< x-frame-options: SAMEORIGIN
< x-content-type-options: nosniff
< x-ratelimit-resetdate: 2023-12-17T21:23:52Z
<
* Connection #0 to host api.amp.cisco.com left intact
{"version":null,"data":{},"errors":[{"error_code":401,"description":"Unauthorized","details":["Unknown API key or Client ID"]}]}
```

I see others talking about 404's, but I see no answers to their questions. Can someone point me in the right direction?

dstaudt · ‎12-18-2023

That's a brand new version of Curl, but even so it seems to be working here...any chance a proxy or some other network interference is preventing you from reaching the AMP URL? Are you perhaps in a non-US region (look under the **Servers** dropdown here

:~/Downloads/curl-static-i686-8.5.0$ ./curl -v \
-H 'accept: application/json' \
-H 'content-type: application/json' \
--compressed -H 'Accept-Encoding: gzip, deflate' \
-u redacted:redacted \
https://api.amp.cisco.com/v1/computers
* Host api.amp.cisco.com:443 was resolved.
* IPv6: (none)
* IPv4: 192.111.4.8, 192.111.4.9, 192.111.4.7
*   Trying 192.111.4.8:443...
* Connected to api.amp.cisco.com (192.111.4.8) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / prime256v1 / rsaEncryption
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=amp.cisco.com; O=Cisco Systems Inc.; L=San Jose; ST=California; C=US
*  start date: Jul 18 21:12:37 2023 GMT
*  expire date: Jul 17 21:11:37 2024 GMT
*  subjectAltName: host "api.amp.cisco.com" matched cert's "api.amp.cisco.com"
*  issuer: C=US; O=IdenTrust; OU=HydrantID Trusted Certificate Service; CN=HydrantID Server CA O1
*  SSL certificate verify ok.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/2
* Server auth using Basic with user 'redacted'
* [HTTP/2] [1] OPENED stream for https://api.amp.cisco.com/v1/computers
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: api.amp.cisco.com]
* [HTTP/2] [1] [:path: /v1/computers]
* [HTTP/2] [1] [authorization: Basic redacted]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: application/json]
* [HTTP/2] [1] [content-type: application/json]
* [HTTP/2] [1] [accept-encoding: gzip, deflate]
> GET /v1/computers HTTP/2
> Host: api.amp.cisco.com
> Authorization: Basic redacted
> User-Agent: curl/8.5.0
> accept: application/json
> content-type: application/json
> Accept-Encoding: gzip, deflate
> 
< HTTP/2 200 
< date: Mon, 18 Dec 2023 18:25:12 GMT
< content-type: application/json
< status: 200 OK
< cache-control: no-store
< x-ratelimit-limit: 200
< x-ratelimit-reset: 59
< strict-transport-security: max-age=63072000; includeSubDomains
< referrer-policy: strict-origin-when-cross-origin
< x-ratelimit-remaining: 199
< x-permitted-cross-domain-policies: none
< pragma: no-cache
< x-xss-protection: 1; mode=block
< x-request-id: 40542483-efc1-4443-b425-247cfea31e73
< x-download-options: noopen
< etag: W/"c84e9ca51ec54fb5d847ba7250b3cdb6"
< x-frame-options: SAMEORIGIN
< x-content-type-options: nosniff
< x-ratelimit-resetdate: 2023-12-18T18:26:11Z
< expires: Fri, 01 Jan 1990 00:00:00 GMT
< strict-transport-security: max-age=31536000
< content-encoding: gzip
(content ommitted)

jimmypuckett · ‎12-18-2023

Thank you for the reply. I have tried the other ones (even though the v3 North America one works for me), and I get 401's...

```
< HTTP/2 401
< date: Mon, 18 Dec 2023 18:58:11 GMT
< content-type: application/json
< status: 401 Unauthorized
```

That is so puzzling. I get past the auth on North America with my credentials, so I know that they are good for the region.

dstaudt · ‎12-18-2023

The 401 for other regions would be expected AFAIK.
Definitely odd...I copy/pasted your request, added credentials and it worked fine. Are you logged into SecureX as the main admin, when you create the API key?
I would note the content-type header is extraneous, as that applies only to request bodies - there isn't one for this request...but that doesn't seem to matter.