Orchestrator script environment (Python) fails with SSL: CERTIFICATE_VERIFY_FAILED - how to set CA bundle file to verify certificates

[antonioaraujo]

Dear Colleagues,

I hope you all are fine.

Do you know the proper way to set CA-bundle file used by Python "requests" module to verify SSL certificates in a Python runtime environment?

I am getting the following error:

urllib3.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1007)

You can find the context below:

An Orchestrator script environment for Python was created with Python module "requests" as dependency successfully.

Then, a scriptable task uses the new Python runtime environment to send an HTTP request as shown below:

response = requests.post(url, headers=headers, params=parameters, json=payload)

However, the following error is thrown:

urllib3.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1007)

It is documented (https://requests.readthedocs.io/en/latest/user/advanced/#ssl-cert-verification) that we can pass verify the path to a CA_BUNDLE file or directory with certificates of trusted CAs.

So I tried copying the CA file to a specific path as shown below:

response = requests.post(url, headers=headers, params=parameters, json=payload, verify="/var/run/vco-polyglot/CA-CERT-MANAGER.pem")

but I get the following error:

OSError: Could not find a suitable TLS CA certificate bundle, invalid path: /var/run/vco-polyglot/CA-CERT-MANAGER.pem

I have not identified the proper path in which CA file should be copied. It seems path is invalid.

We have three pods running vco-app:

# kubectl get pods -n prelude | grep vco-app

vco-app-59654c6f96-kvdcr                        3/3     Running   0          2d22h

vco-app-59654c6f96-lr7d6                        3/3     Running   1          115d

vco-app-59654c6f96-zxnkt                        3/3     Running   1          115d

Description for each pods shows information about the "vco-polyglot-runner" container:

Containers:

  vco-polyglot-runner:

    Container ID:   docker://2667bf7a2fde623a8516e0ff2539f639d5d13b46030a977c1c0796834b15e4d4

    Image:          vco-polyglot-runner_private:latest

    Image ID:       docker://sha256:f11d1981cbf5facf93546071cad7fa0a408a8f5312daa842ccc7806d535a234a

    Port:           <none>

    Host Port:      <none>

    State:          Running

      Started:      Mon, 23 Sep 2024 12:52:06 +0000

    Ready:          True

    Restart Count:  0

    Limits:

      memory:  6G

    Requests:

      memory:     1G

    Liveness:     exec [docker ps] delay=30s timeout=30s period=40s #success=1 #failure=10

    Environment:  <none>

    Mounts:

      /var/log/collected-logs from service-logs (rw)

      /var/run/ from vco-polyglot-runner-sock (rw)

      /var/run/secrets/kubernetes.io/serviceaccount from default-token-kgmmh (ro)

      /var/run/vco-polyglot from vco-polyglot (ro)

I am trying to understand under which directory the CA file should be copied.

Mounts also shows the following volumes used:

    Mounts:

      /var/log/collected-logs from service-logs (rw)

      /var/run/ from vco-polyglot-runner-sock (rw)

      /var/run/secrets/kubernetes.io/serviceaccount from default-token-kgmmh (ro)

      /var/run/vco-polyglot from vco-polyglot (ro)

I have tested copying the file CA-CERT-MANAGER.pem within /var/run/vco-polyglot, and the workflow is run using verify parameter pointing to the path described below:

response = requests.get('https://cert-manager.com', verify='/var/run/vco-polyglot/CA-CERT-MANAGER.pem')

But It does not work.

I see that /var/run/vco-polyglot is mount from vco-polyglot volume, which has the following path /data/vco/var/run/vco-polyglot as shown below:

Volumes:

  vco-vol:

    Type:          HostPath (bare host directory volume)

    Path:          /data/vco/usr/lib/vco

    HostPathType:  DirectoryOrCreate

  vco-scripting:

    Type:          HostPath (bare host directory volume)

    Path:          /data/vco/var/run/vco

    HostPathType:  DirectoryOrCreate

  service-logs:

    Type:          HostPath (bare host directory volume)

    Path:          /services-logs/prelude/vco-app/file-logs

    HostPathType:  DirectoryOrCreate

  vco-polyglot:

    Type:          HostPath (bare host directory volume)

    Path:          /data/vco/var/run/vco-polyglot

    HostPathType:  DirectoryOrCreate

  vco-polyglot-runner-sock:

    Type:          HostPath (bare host directory volume)

    Path:          /data/vco/var/run/vco-polyglot-runner-sock

    HostPathType:  DirectoryOrCreate

  extcert-secret:

    Type:        Secret (a volume populated by a Secret)

    SecretName:  cert-ext

    Optional:    false

  dependencies:

    Type:      ConfigMap (a volume populated by a ConfigMap)

    Name:      vco-dependencies

    Optional:  false

  depcheck:

    Type:          HostPath (bare host directory volume)

    Path:          /usr/local/bin/depcheck

    HostPathType:  File

  vco-controlcenter-user-vol:

    Type:        Secret (a volume populated by a Secret)

    SecretName:  vco-controlcenter-user-secret

    Optional:    false

  default-token-kgmmh:

    Type:        Secret (a volume populated by a Secret)

    SecretName:  default-token-kgmmh

    Optional:    false

I also read that if we run certifi.where() function: 

import certifi

def handler(context, inputs):

    print("Check certifi module version...")

    print("certifi.where(): ", certifi.where())

we can see the path used by certifi module:

2024-09-26 16:07:29.678 +04:00infocertifi.where(): /var/run/vco-polyglot/environment/environment-bundle/lib/certifi/cacert.pem

I see the path /var/run/vco-polyglot/environment/environment-bundle/lib/certifi/ but I cannot copy the CA file to that location, because that path is not found.

I would appreciate any guidance to find the proper path in which the CA bundle file should be copied to verify certificates and to avoid it is deleted if pods are restarted.

Best regards

Antonio

[xian]

I can't see /var/run/vco-polyglot mounted within the scriptable task:

overlay on / type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/BHSAODO3YN6EO3W6EFIED3TTBT:/var/lib/docker/overlay2/l/REJXUPKRJLY7VW4GTJP7EDPOKD:/var/lib/docker/overlay2/l/ES5IQ2OZLAGKLRI4MGBYLDDNUE:/var/lib/docker/overlay2/l/K73GG5VCFKYNXJZ4S7CU5XUGAI:/var/lib/docker/overlay2/l/QFOUF4HV723CPVKKQ3LJSBV5RJ:/var/lib/docker/overlay2/l/224UX5FBVHMNBXGVXVPXKDYER2,upperdir=/var/lib/docker/overlay2/487d5436b632393d807b4ae26c289dd48ca6a9688dd86c5b3f0e8751221a9e80/diff,workdir=/var/lib/docker/overlay2/487d5436b632393d807b4ae26c289dd48ca6a9688dd86c5b3f0e8751221a9e80/work)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (ro,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/freezer type cgroup (ro,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/blkio type cgroup (ro,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (ro,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (ro,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/rdma type cgroup (ro,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/devices type cgroup (ro,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (ro,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
/dev/mapper/data_vg-data on /etc/resolv.conf type ext4 (rw,nosuid,nodev,relatime)
/dev/mapper/data_vg-data on /etc/hostname type ext4 (rw,nosuid,nodev,relatime)
/dev/mapper/data_vg-data on /etc/hosts type ext4 (rw,nosuid,nodev,relatime)
/dev/mapper/data_vg-data on /run/vco-polyglot/function type ext4 (ro,relatime)
/dev/mapper/data_vg-data on /run/vco-polyglot/outputs type ext4 (rw,nosuid,nodev,relatime)
/dev/mapper/data_vg-data on /run/vco-polyglot/environment type ext4 (ro,relatime)
proc on /proc/bus type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/fs type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/irq type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/sys type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/sysrq-trigger type proc (ro,nosuid,nodev,noexec,relatime)
tmpfs on /proc/acpi type tmpfs (ro,relatime)
tmpfs on /proc/kcore type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/keys type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/latency_stats type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/timer_list type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/sched_debug type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/scsi type tmpfs (ro,relatime)
tmpfs on /sys/firmware type tmpfs (ro,relatime)

What I suggest instead is to pass the certificate bundle as an input to your scriptable task. You can store it as a resource element, for example. This is what the IPAM plugin does too: passes the cert bundle each time the actions are run.

Something like this (you need to save the bundle into a file):

import requests
import tempfile

def handler(context, inputs):

    tmp = tempfile.NamedTemporaryFile(mode='wt')
    tmp.write(inputs["CA"])
    tmp.seek(0)
    
    r = requests.get('https://self-signed.badssl.com/', verify=tmp.name)
    print(r.text)
    tmp.close()
    return {"result": "done"}

And the result:

I have defined "CA" as a workflow input (for the sake of simplicity) and allowed line-breaks with Text area:

But again, this is just for testing purposes, you can/should store your cert chain somewhere in vRO.

[antonioaraujo]

Dear @xian,

I hope you are fine.

Thank you very much for sharing that magic idea! This is the goal of a community, sharing knowledge!

Everyday I learn new things about Aria Automation and how to integrate it with other products :)

I have not tested IPAM plug-in yet, but the idea of passing the CA file as an input of the scriptable task is simply great!

What I am testing now is creating a variable with the CA certificate within a Configuration Element as a string.

Then, varCertificateManagerCA is an input in the scriptable task.

However, after testing the following code:

def handler(context, inputs):
    …
    …
    tmp = tempfile.NamedTemporaryFile(mode='wt')
    ca_file = inputs.get("varCertificateManagerCA")
    tmp.write(ca_file)
    tmp.seek(0)
   
    response = requests.post(url, headers=headers, params=parameters, json=payload, verify=tmp.name)

I get this error "ssl.SSLError: [X509: NO_CERTIFICATE_OR_CRL_FOUND] no certificate or crl found (_ssl.c:4149)" as shown below:

2024-09-28 02:10:36.101 +04:00 infosend: b'CONNECT cert-manager.com:443 HTTP/1.0\r\n\r\n'
2024-09-28 02:10:36.102 +04:00 errorTraceback (most recent call last):
2024-09-28 02:10:36.103 +04:00 error  File "/var/run/vco-polyglot/environment/environment-bundle/lib/urllib3/util/ssl_.py", line 447, in ssl_wrap_socket
2024-09-28 02:10:36.104 +04:00 error    context.load_verify_locations(ca_certs, ca_cert_dir, ca_cert_data)
2024-09-28 02:10:36.105 +04:00 errorssl.SSLError: [X509: NO_CERTIFICATE_OR_CRL_FOUND] no certificate or crl found (_ssl.c:4149)
2024-09-28 02:10:36.106 +04:00 error
2024-09-28 02:10:36.107 +04:00 errorThe above exception was the direct cause of the following exception:
2024-09-28 02:10:36.108 +04:00 error
2024-09-28 02:10:36.109 +04:00 errorTraceback (most recent call last):
2024-09-28 02:10:36.110 +04:00 error  File "/var/run/vco-polyglot/environment/environment-bundle/lib/urllib3/connectionpool.py", line 775, in urlopen
2024-09-28 02:10:36.111 +04:00 error    self._prepare_proxy(conn)
2024-09-28 02:10:36.112 +04:00 error  File "/var/run/vco-polyglot/environment/environment-bundle/lib/urllib3/connectionpool.py", line 1044, in _prepare_proxy
2024-09-28 02:10:36.113 +04:00 error    conn.connect()
2024-09-28 02:10:36.114 +04:00 error  File "/var/run/vco-polyglot/environment/environment-bundle/lib/urllib3/connection.py", line 730, in connect
2024-09-28 02:10:36.115 +04:00 error    sock_and_verified = _ssl_wrap_socket_and_match_hostname(
2024-09-28 02:10:36.116 +04:00 error  File "/var/run/vco-polyglot/environment/environment-bundle/lib/urllib3/connection.py", line 909, in _ssl_wrap_socket_and_match_hostname
2024-09-28 02:10:36.117 +04:00 error    ssl_sock = ssl_wrap_socket(
2024-09-28 02:10:36.118 +04:00 error  File "/var/run/vco-polyglot/environment/environment-bundle/lib/urllib3/util/ssl_.py", line 449, in ssl_wrap_socket
2024-09-28 02:10:36.119 +04:00 error    raise SSLError(e) from e
2024-09-28 02:10:36.120 +04:00 errorurllib3.exceptions.SSLError: [X509: NO_CERTIFICATE_OR_CRL_FOUND] no certificate or crl found (_ssl.c:4149)

Maybe there is something wrong with the file.

You also mentioned "allowing line-breaks with Text area", Am I missing anything?

I would appreciate if you can guide me :)

Best regards

Antonio

[xian]

Unfortunately the line breaks cannot be saved in a string conf element attribute, and the certificate is not recognized this way by the Python code. That is why I created a string input with a multiline form, not to lose line breaks. Since this workaround not suitable for production cases, you need to choose the MimeAttachment type:

You need to bind this to a variable in your workflow. You have to "read" this MimeAttachment file and put the content into a string variable (CA):

You need a Javascript task for that:

Then you can use this string (including linebreaks) as a cert file in your Python code (second task in the WF).

[xian]

I was today years old to discover an attribute type Text that allows to save linebreaks in a config element attribute, as a string:

This can directly bound to an attribute, and passed into Python task as input:

No need to use MimeAttachment:

[antonioaraujo]

Dear @Xian,

I hope you are fine.

Thank you very much for your two last replies and excuse me for the late reply.

I tested MimeAttachement file with a JavaScript task following your first recommendation but it did not work.

Error received was:

ERRORurllib3.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1007)

I tested Configuration element with a Text variable following your second recommendation but it did not work.

Error received was:

DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): cert-manager.com:443

urllib3.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1007)

In both cases the error is the same.

I am guessing the issue is related to the structure of the CA Bundle file. I am sending an HTTP request to https://cert-manager.com and I observed that it fails even if I use the full chain from CA to server certificate.

On the other hand, you are testing https://self-signed.badssl.com. When I check certificate for that server with openSSL I get the following:

% openssl s_client -connect self-signed.badssl.com:443

CONNECTED(00000005)

depth=0 C = US, ST = California, L = San Francisco, O = BadSSL Fallback. Unknown subdomain or no SNI., CN = badssl-fallback-unknown-subdomain-or-no-sni

verify error:num=20:unable to get local issuer certificate

verify return:1

depth=0 C = US, ST = California, L = San Francisco, O = BadSSL Fallback. Unknown subdomain or no SNI., CN = badssl-fallback-unknown-subdomain-or-no-sni

verify error:num=21:unable to verify the first certificate

verify return:1

write W BLOCK

---

Certificate chain

0 s:/C=US/ST=California/L=San Francisco/O=BadSSL Fallback. Unknown subdomain or no SNI./CN=badssl-fallback-unknown-subdomain-or-no-sni

   i:/C=US/ST=California/L=San Francisco/O=BadSSL/CN=BadSSL Intermediate Certificate Authority

---

Server certificate

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

MIIE8DCCAtigAwIBAgIJAM28Wkrsl2exMA0GCSqGSIb3DQEBCwUAMH8xCzAJBgNV

BAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1TYW4gRnJhbmNp

c2NvMQ8wDQYDVQQKDAZCYWRTU0wxMjAwBgNVBAMMKUJhZFNTTCBJbnRlcm1lZGlh

dGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDgwODIxMTcwNVoXDTE4MDgw

ODIxMTcwNVowgagxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYw

FAYDVQQHDA1TYW4gRnJhbmNpc2NvMTYwNAYDVQQKDC1CYWRTU0wgRmFsbGJhY2su

IFVua25vd24gc3ViZG9tYWluIG9yIG5vIFNOSS4xNDAyBgNVBAMMK2JhZHNzbC1m

YWxsYmFjay11bmtub3duLXN1YmRvbWFpbi1vci1uby1zbmkwggEiMA0GCSqGSIb3

DQEBAQUAA4IBDwAwggEKAoIBAQDCBOz4jO4EwrPYUNVwWMyTGOtcqGhJsCK1+ZWe

sSssdj5swEtgTEzqsrTAD4C2sPlyyYYC+VxBXRMrf3HES7zplC5QN6ZnHGGM9kFC

xUbTFocnn3TrCp0RUiYhc2yETHlV5NFr6AY9SBVSrbMo26r/bv9glUp3aznxJNEx

tt1NwMT8U7ltQq21fP6u9RXSM0jnInHHwhR6bCjqN0rf6my1crR+WqIW3GmxV0Tb

ChKr3sMPR3RcQSLhmvkbk+atIgYpLrG6SRwMJ56j+4v3QHIArJII2YxXhFOBBcvm

/mtUmEAnhccQu3Nw72kYQQdFVXz5ZD89LMOpfOuTGkyG0cqFAgMBAAGjRTBDMAkG

A1UdEwQCMAAwNgYDVR0RBC8wLYIrYmFkc3NsLWZhbGxiYWNrLXVua25vd24tc3Vi

ZG9tYWluLW9yLW5vLXNuaTANBgkqhkiG9w0BAQsFAAOCAgEAsuFs0K86D2IB20nB

QNb+4vs2Z6kECmVUuD0vEUBR/dovFE4PfzTr6uUwRoRdjToewx9VCwvTL7toq3dd

oOwHakRjoxvq+lKvPq+0FMTlKYRjOL6Cq3wZNcsyiTYr7odyKbZs383rEBbcNu0N

c666/ozs4y4W7ufeMFrKak9UenrrPlUe0nrEHV3IMSF32iV85nXm95f7aLFvM6Lm

EzAGgWopuRqD+J0QEt3WNODWqBSZ9EYyx9l2l+KI1QcMalG20QXuxDNHmTEzMaCj

4Zl8k0szexR8rbcQEgJ9J+izxsecLRVp70siGEYDkhq0DgIDOjmmu8ath4yznX6A

pYEGtYTDUxIvsWxwkraBBJAfVxkp2OSg7DiZEVlMM8QxbSeLCz+63kE/d5iJfqde

cGqX7rKEsVW4VLfHPF8sfCyXVi5sWrXrDvJm3zx2b3XToU7EbNONO1C85NsUOWy4

JccoiguV8V6C723IgzkSgJMlpblJ6FVxC6ZX5XJ0ZsMI9TIjibM2L1Z9DkWRCT6D

QjuKbYUeURhScofQBiIx73V7VXnFoc1qHAUd/pGhfkCUnUcuBV1SzCEhjiwjnVKx

HJKvc9OYjJD0ZuvZw9gBrY7qKyBX8g+sglEGFNhruH8/OhqrV8pBXX/EWY0fUZTh

iywmc6GTT7X94Ze2F7iB45jh7WQ=

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

subject=/C=US/ST=California/L=San Francisco/O=BadSSL Fallback. Unknown subdomain or no SNI./CN=badssl-fallback-unknown-subdomain-or-no-sni

issuer=/C=US/ST=California/L=San Francisco/O=BadSSL/CN=BadSSL Intermediate Certificate Authority

---

No client certificate CA names sent

Server Temp Key: ECDH, P-256, 256 bits

---

SSL handshake has read 1938 bytes and written 413 bytes

---

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256

Server public key is 2048 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

No ALPN negotiated

SSL-Session:

    Protocol  : TLSv1.2

    Cipher    : ECDHE-RSA-AES128-GCM-SHA256

    Session-ID: 7126ACF51E2443CCFD3EAB9CC45C8FBD33D8C4C822FDE1A355AD96FA26765525

    Session-ID-ctx:

    Master-Key: C2CF78FA96B03E42766B5706BC5DB8A6BCF6D6A2F555A8B67CCA63926564639E34FCDE0D05BD2E9D204ABF0120C3A228

    TLS session ticket lifetime hint: 300 (seconds)

    TLS session ticket:

    0000 - 39 db ae f0 b8 78 7f 18-0a dc 1c 7b 83 2b 94 41   9....x.....{.+.A

    0010 - be 65 3e 9b 91 91 71 8f-59 b4 8e 49 ff 4b 73 6f   .e>...q.Y..I.Kso

    0020 - 9e 77 14 b0 da aa 1a 17-1d e1 cd bd bf 07 a5 cc   .w..............

    0030 - f9 06 51 76 83 8d 09 72-8f 0a dc 07 67 1d de b8   ..Qv...r....g...

    0040 - 82 5a 30 74 27 67 e4 de-d4 6a 41 39 13 9a 0d af   .Z0t'g...jA9....

    0050 - a9 68 f7 06 22 40 92 3e-b2 a7 93 d5 be 58 e9 f2   .h.."@.>.....X..

    0060 - 0b 8b 0c e6 12 0f 7b 2b-1a 66 0c 22 a9 40 93 15   ......{+.f.".@..

    0070 - 98 1d 2d c1 6e 8c f2 16-a0 20 fb e3 35 8f 2c 63   ..-.n.... ..5.,c

    0080 - 10 b5 59 54 34 ab a7 7c-2f fc 78 21 a0 99 3f de   ..YT4..|/.x!..?.

    0090 - 6d 18 7e 04 71 c4 bf 50-af 0a 9c f9 3f 4e be 32   m.~.q..P....?N.2

    00a0 - 92 7a c8 e4 3a 63 d9 c8-cc 68 c2 8e 1d af 77 10   .z..:c...h....w.




    Start Time: 1727627948

    Timeout   : 7200 (sec)

    Verify return code: 21 (unable to verify the first certificate)

---

m

HTTP/1.1 400 Bad Request

Server: nginx/1.10.3 (Ubuntu)

Date: Sun, 29 Sep 2024 16:39:31 GMT

Content-Type: text/html

Content-Length: 182

Connection: close




<html>

<head><title>400 Bad Request</title></head>

<body bgcolor="white">

<center><h1>400 Bad Request</h1></center>

<hr><center>nginx/1.10.3 (Ubuntu)</center>

</body>

</html>

read:errno=0

However, if I check the same URL,  using web browser I see that the certificate is different.

At this point I am confused, because I am still getting the same error with your two recommendations:

urllib3.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1007)

Maybe this is related to proxy or something else.

I think your second recommendation should work but it fails.

One question: when you create the CA bundle, does the chain start from CA to server or the opposite?

I will be checking the certificates.

Thanks again for your guidance.

Best regards

Antonio

[xian]

Hi,

cert-manager.com should not need any CA in Python, as it signed with a trusted CA. The reason I used badssl.org is to demonstrate that if you have a self-signed (or not trusted) certificate chain, you can still make it work in Python with providing the proper cert chain.

Your case seems to be different, and I suspect that you have a transparent SSL proxy that replaces the original certificate(s), so it becomes untrusted in your Python code.

I suggest to fetch the certificates of cert-manager.com from the vRA appliance itself, and provide that chain to the Python code. More than likely it will be different (replaced) from what you see in the browser.

[antonioaraujo]

Dear xian,

I hope you are fine.

Thank you very much for your comments and guidance.

I am checking with colleagues that transparent SSL proxy you were talking about. I will also test what you recommend: fetching cert-manager.com from vRA and then provide the chain to the Python code.

Best regards

Antonio

[antonioaraujo]

Dear Xian,

I hope you are fine.

Finally, I was able to use Python request module! You were right.

After fetching the transparent SSL proxy's issuer certificates (starting from Root CA), HTTP request was processed successfully.

Your recommendation of using a Text variable within an Orchestrator configuration element did the magic! along with the CA bundle :)

Thank you very much for your support and guidance!

Best regards

Antonio