> For the complete documentation index, see [llms.txt](https://inflight.dope.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://inflight.dope.security/dope.console/dope.swg-policy/dopamine-dlp/claude-ssl-certificate-workaround.md).

# Claude SSL Certificate Workaround

#### Claude SSL Certificate Workaround — IT Help Guide​

#### Background

Some applications do not support direct import of a custom root certificate through their own settings. In these cases, the root certificate used by the network security agent must instead be added to the system via environment variables so that the application can establish trusted, inspected connections.

#### Windows Steps

1. ​Press Win + R
2. ​Type sysdm.cpl and press Enter
3. ​Navigate to Advanced → Environment Variables
4. ​Under System Variables, click New and add each of the following:

| Variable Name          | Variable Value                                                         |
| ---------------------- | ---------------------------------------------------------------------- |
| NODE\_EXTRA\_CA\_CERTS | Windows: C:\ProgramData\dope.security\res\certs\dope.security.root.crt |
| SSL\_CERT\_FILE        | Windows: C:\ProgramData\dope.security\res\certs\dope.security.root.crt |

1. ​Click OK to save, then restart the affected application (a full reboot may be required for the changes to take effect).​

#### macOS Steps (zsh)

1. ​Open the shell configuration file:

nano \~/.zshrc

1. ​Add the following line:

export NODE\_EXTRA\_CA\_CERTS=Mac: /Library/ApplicationSupport/dope.security/res/certs/dope.security.root.crt

1. ​Reload the configuration:

source \~/.zshrc

1. ​Restart the affected application from a terminal session for the variable to take effect.

Note: This method only applies environment variables to processes launched from a shell session. Applications launched normally (via Finder, Dock, or Spotlight) will not inherit this variable. A system-wide deployment method should be used to apply this consistently across all users and launch methods.​

#### Deploying at Scale

Applying this manually on each machine does not scale well. For a fleet-wide rollout, IT teams should instead:

1. ​Distribute the certificate file first. Push the root certificate file to a consistent, identical path on every machine using existing endpoint management tooling (e.g., a configuration management platform, device management solution, or scripted software deployment system). The certificate should also be added to the system-wide trusted root store where possible, in addition to the environment variable method described above.
2. ​Set the environment variable centrally, not per-user.

* ​Windows: Use a policy-based configuration management tool to set the two environment variables as system-level (machine-wide) variables, rather than instructing each user to set them individually. This ensures the setting applies regardless of which user is logged in and survives across reboots.
* ​macOS: A per-user shell configuration file (like \~/.zshrc) will not reach applications launched outside of a terminal session. To cover all launch methods (Dock, Finder, Spotlight), the variable must instead be set at the system/login level using a device management profile or system-level login script, so it applies to every user session on the machine — not just interactive shell sessions.

1. ​Force or schedule application of the policy. Depending on the management tooling in use, changes may apply immediately, at next check-in, or may require a policy refresh to be triggered manually.
2. ​Require a restart. Environment variable changes typically only take effect for new processes. Affected applications — and in many cases the machine itself — need to be restarted before the fix takes effect. Communicate this requirement clearly, or automate a restart prompt as part of the deployment.
3. ​Validate on a pilot group first. Before pushing to the full fleet, test on a small representative set of machines (covering both operating systems and any relevant application versions) to confirm the certificate is trusted and any dependent security detection is functioning as expected. This is especially important given the known issue below, where the fix alone has not fully resolved detection behavior.
4. ​Monitor and confirm. After rollout, use endpoint reporting/compliance tooling to confirm the certificate and environment variables are correctly present across the fleet, rather than relying on manual spot checks alone.

#### Expected Result

Data loss prevention (DLP) detection should trigger correctly across all integrations once the certificate is trusted.

#### Known Issue

DLP detection is not currently triggering for the affected application's integrations, even after the certificate workaround has been applied and SSL errors are resolved.

#### Outstanding Items

1. ​Testing for two additional third-party integrations is still pending and will be validated separately.
2. ​This certificate workaround is required only in environments where the network security agent is active.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://inflight.dope.security/dope.console/dope.swg-policy/dopamine-dlp/claude-ssl-certificate-workaround.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
