SD-WAN Dashboard GeoMap does not load in CA Performance Management (CAPM)

Products

Network Observability CA Performance Management

Issue/Introduction

The SD-WAN Dashboard GeoMap does not load in DX NetOps CAPM even after trying the following steps:

create a file WE.pem
use SslConfig to import trusted certificate
Point the WE.pem and give it an alias of google-we-cert
- restart services
Set browser to incognito mode

However, issue remains, GeoMap still does not appear.

Environment

DX NetOps CAPM all currently supported releases

Cause

Looking at:

openssl s_client -connect api.maptiler.com:443 -showcerts CONNECTED(00000003) depth=3 C = US, ST = California, L = San Jose, O = Cloud_Sec_Comp Inc., OU = Cloud_Sec_Comp Inc., CN = Cloud_Sec_Comp Root CA, emailAddress = support@Cloud_Sec_Comp.com verify return:1 depth=2 C = US, ST = California, O = Cloud_Sec_Comp Inc., OU = Cloud_Sec_Comp Inc., CN = Cloud_Sec_Comp Intermediate Root CA (Cloud_Sec_Comptwo.net), emailAddress = support@Cloud_Sec_Comp.com verify return:1 depth=1 C = US, ST = California, O = Cloud_Sec_Comp Inc., OU = Cloud_Sec_Comp Inc., CN = "Cloud_Sec_Comp Intermediate Root CA (Cloud_Sec_Comptwo.net) (t) " verify return:1 depth=0 CN = maptiler.com, O = Cloud_Sec_Comp Inc., OU = Cloud_Sec_Comp Inc. verify return:1 --- This is what we see

Root CA        : Cloud_Sec_Comp Root CA
Intermediate  : Cloud_Sec_Comp Intermediate Root CA
Leaf cert     : maptiler.com (re-signed by Cloud_Sec_Comp)

This output confirms that the network traffic to api.maptiler.com is being intercepted and analyzed by a Cloud_Sec_Comp Proxy via SSL Inspection.

Resolution

Normally, when you connect to maptiler.com, you should see a certificate issued by a public Certificate Authority (like Let's Encrypt or DigiCert).
However, the output shows:

Issuer: Cloud_Sec_Comp Root CA
Organization: Cloud_Sec_Comp Inc.
Leaf Certificate: CN = maptiler.com (but signed by Cloud_Sec_Comp, not MapTiler's actual issuer).

So, it appears that Cloud_Sec_Comp is acting as a "Man-in-the-Middle" (MITM). It decrypts the traffic to inspect it for malware or policy violations, then re-encrypts it using a certificate it generated on the fly. This is standard behavior in corporate networks.

However, applications (like Python requests, Node.js, Java, curl, or git) usually have a built-in list of trusted public CAs. They do not trust the private "Cloud_Sec_Comp Root CA" by default.

When your tool sees the Cloud_Sec_Comp certificate, it rejects it because it looks like an attacker is intercepting the connection, resulting in errors like:

CERT_HAS_EXPIRED
SELF_SIGNED_CERT_IN_CHAIN
UNABLE_TO_GET_LOCAL_ISSUER_CERTIFICATE

To resolve this, you generally have three options depending on your permission level and the tool you are using.

Option A. Add the Cloud_Sec_Comp Cert to your Application's Trust Store (Recommended)
You need to tell your application to trust the Cloud_Sec_Comp Root CA.

Export the Cloud_Sec_Comp Root CA:

You can extract the certificate from your original command output. Copy the block including

-----BEGIN CERTIFICATE-----

and

-----END CERTIFICATE-----

corresponding to the Root CA (depth=3) or the Intermediate (depth=2) and save it as Cloud_Sec_Comp-cert.pem.

Option B: Request an SSL Bypass (Network Admin)
If this traffic is critical and certificate pinning prevents Option A from working, you must ask your network administrator to add maptiler.comto the Cloud_Sec_Comp SSL Inspection Bypass list. This will allow the original certificate to pass through untouched.

Option C: Disable SSL Verification (Insecure - Testing Only)
Use this only for temporary debugging. Do not use in production.

Curl: curl -k https://api.maptiler.com
Node.js: process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
Python: requests.get(url, verify=False)