Network and certificates

This page helps when a tool cannot reach Zata at all: the host name does not resolve, the connection times out, or you get a TLS or certificate error. It also covers proxies, Docker containers and bucket names with dots.

Good to know:

Zata’s endpoints use normal public certificates from Let’s Encrypt, valid for idr01.zata.ai and *.idr01.zata.ai (Mumbai: bom01.zata.ai and *.bom01.zata.ai). Every operating system trusts them — you never need to install a Zata certificate.
http:// is redirected (301) to https://. Always use https://.
Any HTTP answer from Zata — 200, 403 or 404 — proves that DNS, the network and TLS work. A request without keys (from curl or a browser) to a private bucket always gets 403 AccessDenied. That is normal, not a block.

Quick fixes

You see	Most likely cause	Fix
`Could not resolve host` or `no such host`	The machine or container cannot resolve the name (DNS)	Test step by step
Connection times out	A firewall blocks outbound HTTPS (port 443), or traffic must go through a proxy	Use the proxy or ask your network team to allow it
`certificate verify failed` or `certificate signed by unknown authority`	A proxy or security appliance inspects TLS and re-signs the traffic	Trust the proxy’s certificate
Certificate “not yet valid” or “expired”	The computer’s clock is wrong	Sync the clock — see Clock and credentials
Certificate error, and the bucket name contains a dot	Virtual-host style with a dotted bucket name	Use path-style
`PermanentRedirect` or `301`	The endpoint starts with `http://`	Use `https://`
`SignatureDoesNotMatch` only on one network	A proxy changes the request	See Signature errors
Works on the host, fails inside a Docker container	The container’s DNS, network or proxy settings	Docker

Test the connection step by step

Run these on the machine — or inside the container — that fails:

nslookup idr01.zata.ai
curl -sI https://idr01.zata.ai
openssl s_client -connect idr01.zata.ai:443 -servername idr01.zata.ai </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

For Mumbai, use bom01.zata.ai.

Result	Meaning
`nslookup` fails	DNS problem: the machine cannot resolve the name
`curl` times out	A firewall blocks outbound port 443, or traffic must go through a proxy
`curl` prints `HTTP/2 200` (or any HTTP status)	DNS, network and TLS work
The issuer is not `Let's Encrypt`	A proxy or security appliance inspects TLS — see TLS inspection
The dates are wrong, or the certificate is “not yet valid”	The machine’s clock is wrong — sync it
All three work, but the tool fails	The tool’s endpoint setting is wrong: a bucket or path in it, `http://`, or it still points at AWS — see Wrong endpoint or region

Behind a proxy

Most tools read the standard proxy variables:

Linux / macOS

Windows (PowerShell)

export HTTPS_PROXY=http://proxy.example.com:3128

Replace the address with your company’s proxy. To send Zata traffic around the proxy, list the host names (not URLs) in NO_PROXY:

export NO_PROXY=idr01.zata.ai,bom01.zata.ai

A proxy that changes requests breaks the signature (SignatureDoesNotMatch). Test once with the proxy bypassed.

TLS inspection

Some company proxies and security appliances decrypt HTTPS traffic and re-sign it with their own certificate. Tools then report a certificate error, and the openssl test above shows an issuer other than Let’s Encrypt. Either ask your network team to exclude idr01.zata.ai and bom01.zata.ai from inspection, or add the proxy’s root certificate:

Tool	Setting
Operating system	add the proxy’s root certificate to the system trust store
AWS CLI and boto3	`export AWS_CA_BUNDLE=/path/to/proxy-ca.pem`
rclone	`--ca-cert /path/to/proxy-ca.pem`

Get the root certificate file from your network team.

Never turn certificate checking off (--no-verify-ssl, verify=False, unticking “Validate SSL certificate”). It hides the real problem and exposes your keys to anyone who can intercept the connection.

Bucket names with dots

Zata accepts both URL styles:

path-style: https://idr01.zata.ai/my-bucket (recommended)
virtual-host style: https://my-bucket.idr01.zata.ai

The certificate covers one level below idr01.zata.ai. A bucket name with a dot (for example my.bucket) adds more levels, so virtual-host style fails with a certificate error. Use path-style:

Tool	Path-style setting
AWS CLI	`aws configure set s3.addressing_style path --profile zata`
rclone	`force_path_style = true` in the remote
boto3	`Config(s3={"addressing_style": "path"})`
s3fs	`-o use_path_request_style`
s3cmd	`host_bucket = idr01.zata.ai` (no bucket placeholder)

Docker

Run the same tests inside the container:

docker exec -it CONTAINER sh

Then compare with a container on the host’s network:

docker run --rm --network host curlimages/curl -sI https://idr01.zata.ai

If it works with --network host but not in the container’s own network, the problem is the container’s DNS (set it with --dns) or the firewall of the Docker network. Proxy variables are not passed into a container automatically — pass them with -e HTTPS_PROXY=....

Two networks

If a tool works on one network (for example at home) and times out on another (for example in the office), the second network blocks outbound HTTPS to Zata or needs a proxy. Run curl -sI https://idr01.zata.ai on both and compare.

See the real error

The debug output contains your access key ID — remove it before you share the output.

Tool	Run	Look for
curl	`curl -v https://idr01.zata.ai`	where the connection stops: name lookup, connect, or TLS handshake
AWS CLI	add `--debug` to the command	the last lines before the error: the URL it connects to and the exception
rclone	add `-vv --dump headers`	the `Host:` line and the error after it
s3fs	mount with `-f -o dbglevel=info`	the connection or certificate error

Still stuck?

Contact Zata support (see Get support) and include:

the output of the three test commands above
where the tool runs (your computer, a server, a container) and whether a proxy or VPN is used
the tool and its version, and the endpoint you use
the exact error message, and the debug output with access keys removed