修改requests的verify为True后，CURL无-k参数请求出现NSS error -12276(SSL_ERROR_BAD_CERT_DOMAIN)问题求助

Hey there! Let's walk through why you're hitting this SSL error and how to get your requests code working with verify=True (and curl without -k) safely.

First, Understand the Error #

The SSL_ERROR_BAD_CERT_DOMAIN you're seeing means the IP address you're using to access your service doesn't match the domain/IP listed on the server's SSL certificate.

When you use verify=False in requests or -k in curl, you're telling the tool to skip this critical security check—hence why those work, but SonarQube flags it as a vulnerability (rightfully so, since skipping validation lets attackers intercept your traffic).

Step 1: Check What's on Your Certificate #

First, let's confirm exactly what domains/IPs your certificate is valid for. Run either of these commands:

• Using curl (even though it'll error, it shows certificate details):

  curl -v https://k8's_svc-IP:443
  

• Using openssl:

  openssl s_client -connect k8's_svc-IP:443
  

Look for two sections in the output:

• Subject: CN=... (the main domain the certificate is for)
• X509v3 Subject Alternative Name: (additional domains/IPs the certificate covers)

This will tell you the valid addresses your service expects you to use.

Step 2: Choose a Solution #

Pick the option that fits your environment (production vs development):

Option 1: Use the Certificate's Valid Domain (Recommended for Production)

If your certificate is issued for a domain like my-k8s-service.internal, update your requests URL and curl command to use that domain instead of the IP. For example:

• In your code:

  response = requests.post("https://my-k8s-service.internal:443/v3/history/data", data=json.dumps(req_body), verify=True, headers=headers)
  

• Curl command:

  curl -v -X POST https://my-k8s-service.internal:443/v3/history/data -H "Content-Type: application/json" -H "userName: admin" -H "source: console" -d '{"user_name": "admin", "token": "abcdd12345"}'
  

This works because the domain you're accessing now matches what's on the certificate, so SSL validation passes.

Option 2: Add Your Service IP to the Certificate (If You Must Use IP)

If you need to access the service via IP (e.g., no DNS setup), you'll need to reissue the SSL certificate to include the service's IP as a Subject Alternative Name (SAN). Here's a quick overview:

1. Generate a new Certificate Signing Request (CSR) with your service's IP added as a SAN. For openssl, create a config file with:

   [req]
   distinguished_name = req_distinguished_name
   req_extensions = v3_req
   prompt = no
   
   [req_distinguished_name]
   CN = my-k8s-service.internal
   
   [v3_req]
   keyUsage = keyEncipherment, dataEncipherment
   extendedKeyUsage = serverAuth
   subjectAltName = @alt_names
   
   [alt_names]
   DNS.1 = my-k8s-service.internal
   IP.1 = k8's_svc-IP
   

2. Use this config to generate the CSR and get it signed by your CA (Certificate Authority).
3. Replace the service's existing certificate with the new one that includes the IP.

Once done, accessing via IP will pass SSL validation.

Option 3: Hosts File Hack (Development Only!)

If you're in a dev environment and just need a quick fix, add an entry to your local hosts file mapping the certificate's domain to the service IP:

• On Linux/macOS: Edit /etc/hosts and add:

  k8's_svc-IP  my-k8s-service.internal
  

• On Windows: Edit C:\Windows\System32\drivers\etc\hosts (run Notepad as admin) and add the same line.

Then use the domain in your requests/curl command—this tricks your system into thinking the IP is the valid domain for the certificate. Never do this in production!

Why This Matters #

Skipping SSL validation (verify=False/-k) exposes you to man-in-the-middle attacks, where an attacker can pretend to be your service and steal sensitive data like tokens. Fixing the certificate domain mismatch ensures your connections are secure, which is why SonarQube is pushing you to set verify=True.

内容的提问来源于stack exchange，提问作者Shailesh Yadav