Allow specify custom signed certs & insecure mode

[credmond]

The tool may not work well in corporate environments.

There doesn't seem to be an "insecure" more like curl's --insecure, allowing _ssl.c to effectively trust untrusted certs:

PS C:\dev\tmp\atlassian> atls jira issue search "project=PROJ AND status=Open"
Error: Connection error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1082)

Nor does there seem to be away to a) include certs or b) tell it to use system certs.

Additionally, the upgrade option which leads to "uv tool upgrade" might need --system-certs too or it will fail (as I've observed).

[eunsanMountain]

Partly addressed in 0.3.1, and I want to check with you on the remaining part.

Shipped:

• ca_bundle in the profile config actually already worked, but it was documented nowhere. It is now in the README, and it no longer passes a plain string to httpx (0.28 deprecated that form, so it would have broken silently later). A missing or non-PEM bundle now fails with a clear validation error instead of a raw ssl.SSLError.
• SSL_CERT_FILE / SSL_CERT_DIR are honoured — this also already worked and was undocumented. Note that SSL_CERT_DIR needs an OpenSSL hashed layout (c_rehash), not a plain folder of PEM files; a plain folder is accepted silently and adds no trust, then fails at handshake time. atls doctor now warns about that and shows which trust store is actually in effect.
• atls upgrade --system-certs for the case you observed, where the download itself fails verification. It is opt-in because older uv builds reject the flag; on failure every install path now prints the hint.
• README covers exporting a corporate root CA as PEM on Windows. (Export-Certificate writes DER, or SST for multiple certs — not PEM. Use certmgr.msc → Base-64 encoded X.509, or certutil -encode.)

Not shipped: --insecure. Disabling certificate verification means anyone on the network path can intercept the traffic and take the PAT, and since this tool is often driven automatically by an agent, a flag like that tends to stay on once enabled. I would rather not ship it until we know the CA path is genuinely insufficient.

So: with ca_bundle or SSL_CERT_FILE pointing at your corporate root, does your setup work? atls doctor --check-auth should tell you quickly. If it does not work, I will reconsider — please leave the failure here and I will open a focused issue for it.

Leaving this open until you have had a chance to try.

[credmond]

Hi @eunsanMountain
It seems that a bunch of things are now broken.

Jira, previously working, has now stopped working (does not use self-signed cert in this example), with this error:

Auth probe (profile: default):
  jira: connection failed — Connection error: Error -3 while decompressing data: incorrect header check

Regarding the overall solution of specifying certs, etc. Most tools like Node, UV, etc., just allow you to specify whether to use system certs. Some tools just do it by default. Having to point to, and/or convert files, etc., isn't ideal.

E.g., look at these (node, pip):

UV_SYSTEM_CERTS=true
NODE_TLS_REJECT_UNAUTHORIZED=0
NODE_USE_ENV_PROXY=1
NODE_USE_SYSTEM_CA=1
REQUESTS_CA_BUNDLE=C:\dev\certs\xyz.abcsha-256.crt <-- PIP understands this format

Finally, "SSL_CERT_FILE" is conflicting. The command uv obviously looks at this env variable too, and expects it in p12/crt format. Not PEM. So if you follow your README, then you're breaking uv like this:

C:\>uv tool install atlassian-skills
warning: Ignoring `SSL_CERT_FILE`. No valid certificates found in: c:\dev\certs\xyz.abc.sha-256.pem.
Resolved 31 packages in 43ms
Installed 31 packages in 631ms
 + annotated-doc==0.0.4
 + annotated-types==0.8.0
...
...

Additionally, when I DO specify an SSL_CERT_FILE (a valid PEM), even a simple atls doctor totally fails until SSL_CERT_FILE is removed:

C:\dev\code>atls doctor
Error: Unexpected internal error
Hint:  Retry with a minimal command and report the failure type if it persists.

C:\dev\code>set SSL_CERT_FILE=

C:\dev\code>atls doctor
atls 0.3.1  (couldn't reach PyPI — update check skipped)

Platform: windows (shell: powershell)
  Attachment writer: native

Paths:
  Claude config dir   : C:\Users\xxx\.claude
  Claude skill target : C:\Users\xxx\.claude\skills\atls\SKILL.md
  CLAUDE.md path      : C:\Users\xxx\.claude\CLAUDE.md
  Codex config dir    : C:\Users\xxx\.codex
  Codex AGENTS.md path: C:\Users\xxx\.codex\AGENTS.md
  Codex skill target  : C:\Users\xxx\.codex\skills\atls\SKILL.md  (canonical)
  Copilot config dir  : C:\Users\xxx\.copilot
  Copilot skill target: C:\Users\xxx\.copilot\skills\atls\SKILL.md
  Copilot instructions: C:\Users\xxx\.copilot\copilot-instructions.md

Skill installation status:
  Claude skill: not installed (C:\Users\xxx\.claude\skills\atls\SKILL.md)
  Codex skill: not installed (C:\Users\xxx\.codex\skills\atls\SKILL.md)
  Copilot skill: not installed (C:\Users\xxx\.copilot\skills\atls\SKILL.md)
  Codex AGENTS.md: ATLS block v0.3.1 at C:\Users\xxx\.codex\AGENTS.md
  CLAUDE.md: ATLS block v0.3.1 at C:\Users\xxx\.claude\CLAUDE.md
  Copilot instructions: ATLS block v0.3.1 at C:\Users\xxx\.copilot\copilot-instructions.md

Auth:
Profile: default
  Jira URL:         https://xxx.xxx.xxx.ie/  (config)
  Confluence URL:   https://xxx.xxx.xxx.ie/  (config)
  Bitbucket URL:    https://xxx.xxx.xxx/  (config)
  Auth method:    pat (jira) / pat (confluence) / pat (bitbucket)
  Storage:        keyring
  [jira] storage=keyring (configured — run with --resolve to verify)
  [confluence] storage=keyring (configured — run with --resolve to verify)
  [bitbucket] storage=keyring (configured — run with --resolve to verify)
  TLS verify:     certifi (bundled default)

C:\dev\code>

I'd again request to log more information -- much more -- in all error cases.

Another couple of thing:

• --check-auth always requires a --resolve-credentials (you should just include that).
• When there is a TLS error, please log more information rather than stating there's just some TLS error. E.g., what error / why? Having looked a the code a little, I see a lot of swallowing useful data/exceptions. I think maybe AI is assisting too quickly here.

[eunsanMountain]

Fixed in 0.3.2. Both of these reproduced from your report within minutes — thank you for the detail, and particularly for the exact error strings.

The decompression error was ours, and it was a 0.3.0 regression. The streaming rewrite in that release rebuilds each response from bytes that have already been decoded, but it copied the original headers wholesale — so the rebuilt response still claimed content-encoding: gzip, and httpx ran the decoder a second time. Your instance compresses responses, as Jira normally does; our test fixtures never did, which is how it survived review. This one is independent of anything certificate-related, so your Jira commands should work again on 0.3.2 whatever state the TLS configuration is in. There is compressed coverage in the unit suite and in the release smoke test now.

The SSL_CERT_FILE crash. ssl.SSLError was escaping from two places our error boundary never covered: building the HTTP client, and the PyPI update check that runs at the top of doctor. Both are handled now — a bad trust store fails with the actual OpenSSL message, and doctor checks whether the file loads as PEM and says why when it doesn't.

On system certificates, you were right. 0.3.2 verifies against the OS trust store by default, using truststore — the same mechanism pip adopted. A corporate root already installed in the Windows store needs no configuration at all. One thing worth knowing before you try it: explicit configuration still takes precedence over the system store, so while SSL_CERT_FILE is set it keeps being used instead — and in your case it points at a file OpenSSL rejects. Clearing that variable is what puts you on the Windows store. If it slips your mind, the error now says exactly that instead of Unexpected internal error.

That file may be worth a second look, incidentally. On 0.3.1 a valid PEM does not crash doctor — I checked specifically; only a file OpenSSL cannot parse does. Combined with uv reporting No valid certificates found on the same path, two independent tools are rejecting it. On Windows the usual causes are UTF-16 encoding (PowerShell redirection writes UTF-16 by default) or a DER file saved with a .pem extension. atls doctor on 0.3.2 prints exactly what OpenSSL makes of it.

The README no longer leads with SSL_CERT_FILE either. As you found, it is process-global — uv and pip read it too, and a file they cannot parse breaks them as well. ca_bundle in the profile is the first suggestion now, since it only affects atls.

--check-auth resolves credentials on its own now. The flag is the opt-in; there is no second one to remember.

On swallowing exceptions, and AI assisting too quickly — that is fair. The redaction and classification layers were written to keep secrets and server-controlled text out of agent transcripts, and they over-reached into hiding diagnostic information from the person who needs it. 0.3.2 keeps the underlying OpenSSL and zlib detail in every TLS and probe failure, and the redacted internal-error path at least names the exception type.

One thing I could not verify: my testing of the truststore path ran on Linux and in the unit suite, so the Windows CryptoAPI backend went unexercised. If 0.3.2 still misbehaves on your machine, the atls doctor --check-auth output would be the most useful thing to paste — it carries considerably more detail than it used to.

[credmond]

The PR seems to have worked -- thanks. Maybe leave this ticket open for a few more hours and I'll give it a good try.