> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.zata.prathamchopde.site/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.zata.prathamchopde.site/_mcp/server. # 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](#test-the-connection-step-by-step) | | Connection times out | A firewall blocks outbound HTTPS (port 443), or traffic must go through a proxy | [Use the proxy](#behind-a-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](#tls-inspection) | | Certificate "not yet valid" or "expired" | The computer's clock is wrong | Sync the clock — see [Clock and credentials](/help/troubleshooting/clock-and-credentials) | | Certificate error, and the bucket name contains a dot | Virtual-host style with a dotted bucket name | [Use path-style](#bucket-names-with-dots) | | `PermanentRedirect` or `301` | The endpoint starts with `http://` | Use `https://` | | `SignatureDoesNotMatch` only on one network | A proxy changes the request | See [Signature errors](/help/troubleshooting/signature-errors#a-proxy-changes-the-request) | | Works on the host, fails inside a Docker container | The container's DNS, network or proxy settings | [Docker](#docker) | ## Test the connection step by step Run these on the machine — or inside the container — that fails: ```bash nslookup idr01.zata.ai curl -sI https://idr01.zata.ai openssl s_client -connect idr01.zata.ai:443 -servername idr01.zata.ai /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](#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](/help/troubleshooting/endpoint-and-region) | ## Behind a proxy Most tools read the standard proxy variables: #### Linux / macOS ```bash export HTTPS_PROXY=http://proxy.example.com:3128 ``` #### Windows (PowerShell) ```powershell $env: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`: ```bash 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. > **Warning** > > 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: ```bash docker exec -it CONTAINER sh ``` Then compare with a container on the host's network: ```bash 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](/help/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