snapcraft cannot connect through a transparent SSL proxy
Metadata
Current evaluation
Snapcraft 7.5.5/8.3.1 was reported to reject a system-trusted MITM proxy CA for host commands such as whoami; it remains untriaged and unanswered.
Suggested action: needs triage
Reason: The report provides a concrete CERTIFICATE_VERIFY_FAILED error, affected versions, and a working REQUESTS_CA_BUNDLE workaround. There are no labels, and the only maintainer comment asks about certificate injection into build containers, which the reporter could not confirm, leaving the separate host-side failure unassessed. The current tree uses Requests but contains no internal system-CA default or explicit CA-bundle handling.
Evaluated by: mr-cal-bot
Impact:
55
Quick Win:
22
Complexity:
48
Confidence:
86
Actionability:
76
Issue body
### What needs to get done
I filed a LP [bug](https://bugs.launchpad.net/snapcraft/+bug/2073910), but was told this would be a better place for tracking.
If there is a transparent MITM proxy between the client machine and the Snapcraft servers, the snapcraft binary is unable to connect and complains of a certificate error:
```
[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1007)
```
This is after the CA for the proxy is trusted by the system, and picked up by other system tools, eg. apt.
Currently, there is no flag to instruct snapcraft to use the system's CA certificate store to connect through that transparent proxy.
The workaround is to set an environment variable for python `requests` that forces the use of the system trusted certificate bundle.
`export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt`
Snapcraft should have an option (or default) to pick up this CA bundle, without needing to use such a large hammer that can affect other software on the system as well.
```
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04 LTS
Release: 24.04
Codename: noble
$ snapcraft --version
snapcraft 8.3.1
```
Also seen on 7.5.5
### Why it needs to get done
Forcing this option in the `requests` library affects all other software on the system that also uses it.
Snapcraft should have it's own option for this, or pick up the system default. The trusted certificate can be passed into build environments, but there's no way for something like `snapcraft whoami` to connect through such a proxy.
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
55
Quick Win:
22
Complexity:
48
Confidence:
86
Actionability:
76
|
needs triage | Snapcraft 7.5.5/8.3.1 was reported to reject a system-trusted MITM proxy CA for host commands such as whoami; it remains untriaged and unanswered. | |
| stealth/space-bunny-alpha |
Impact:
48
Quick Win:
23
Complexity:
38
Confidence:
87
Actionability:
76
|
keep open | Valid, acknowledged SSL trust issue affecting host-side Store operations behind enterprise MITM proxies; still unresolved, with REQUESTS_CA_BUNDLE as the only reported workaround. | |
| qwen/qwen3.6-35b-a3b |
Impact:
65
Quick Win:
25
Complexity:
45
Confidence:
65
Actionability:
70
|
keep open | snapcraft CLI cannot connect through transparent SSL/MITM proxies; no option to specify custom CA bundle for store API calls | |
| qwen/qwen3.8-27b |
Impact:
55
Quick Win:
30
Staleness:
75
Complexity:
45
Confidence:
55
Support Request:
10
|
needs triage | snapcraft fails with SSL CERTIFICATE_VERIFY_FAILED behind a transparent MITM proxy because it does not use the system CA store; workaround is REQUESTS_CA_BUNDLE. Reported on 8.3.1/7.5.5; maintainer asked a clarifying question, no labels or fix yet. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
90
Complexity:
45
Confidence:
85
Support Request:
20
|
needs triage | Feature request for native system CA bundle support to work through transparent SSL proxies. Currently fails certificate verification. Unlabeled, no assignee, and stuck over a year after a maintainer follow-up question. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
85
Complexity:
55
Confidence:
75
Support Request:
25
|
needs triage | Feature request to add built-in system CA bundle support for transparent SSL proxies. Open for over two years with no labels, assignee, or maintainer triage. |
Update history
No update history recorded yet.
Related work
-
Related To:
snapcraft (launchpad)#2073910
(confidence 99%)
The reporter explicitly linked this Launchpad bug as the original report of the same failure.
-
Related To:
snapcraft#3252
(confidence 86%)
This historical change was titled 'use system certificates by default for HTTPS requests'; failures in later 7.x and 8.x releases suggest a regression or a different trust path.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #2073910 snapcraft cannot connect through a transparent SSL proxy | snapcraft (launchpad) | open | Snapcraft 7.5.5/8.3.1 rejects a system-trusted MITM proxy CA; setting REQUESTS_CA_BUNDLE works, but the report remains untriaged. | |
| #34 Snapcraft cannot authenticate proxy.golang.org | snapcraft-rocks | open | Go builds via Snapcraft fail TLS verification against proxy.golang.org in the 7_core22 container. Maintainers traced it to CA certificates and two merged snapcraft PRs addressed it; issue left open since Apr 2024. |