DocumentationExperience Cloud KCS

Resolving Adobe I/O CLI RDE deployment failures caused by certificate and proxy configuration

Last update: August 18, 2026

Adobe I/O CLI commands against Rapid Development Environments (RDE) fail in enterprise networks when corporate proxies intercept HTTPS traffic or outbound firewall rules block Adobe Cloud Manager and Azure endpoints. The failures appear as certificate validation errors, proxy authentication errors, or network blocks, because corporate proxies replace SSL certificates with internally signed ones that Node.js doesn’t trust unless told to. Providing the corporate CA to Node.js, configuring proxy environment variables, and allowlisting the required Adobe and Azure endpoints restores RDE deployments and status checks.

Description description

Issue: Adobe I/O CLI RDE commands fail with certificate or proxy errors on enterprise networks

Description

When interacting with AEM Rapid Development Environments (RDE) using the Adobe I/O CLI, commands such as aio aem:rde:status, aio cloudmanager:list-programs, or aio aem:rde:install fail. These failures occur primarily in enterprise networks where HTTPS traffic is intercepted by corporate proxies, or where outbound firewall rules block access to Adobe Cloud Manager or Azure endpoints. Common failure modes include certificate validation errors, proxy authentication failures, and network blocks when accessing Adobe RDE APIs or the Azure File Storage endpoints used during RDE deployments.

Environment:

  • Adobe Experience Manager as a Cloud Service (AEMaaCS)
  • AEM Rapid Development Environments (RDE)
  • Adobe I/O CLI (@adobe/aio-cli) on Node.js
  • Enterprise networks with SSL-inspecting proxies or outbound firewalls

Issue/Symptoms:

  • A fetch error reports that a request to the Cloud Manager programs API failed with the reason self signed certificate in certificate chain.
  • ECONNREFUSED on port 443, or connect EACCES, appears when running aio aem:rde:status.
  • UNABLE_TO_VERIFY_LEAF_SIGNATURE appears when uploading an artifact to Azure File Storage during aio aem:rde:install.
  • 403 Proxy Authentication required, or proxy CONNECT misuse, occurs during runtime deployment.
  • An App Builder template fetch fails with a 400 error due to proxy misconfiguration.

Root cause:

RDE communication depends on direct or proxy-routed HTTPS access to Adobe Cloud Manager endpoints, Adobe Developer Console endpoints, and Azure File Storage endpoints. Enterprise network proxies frequently replace SSL certificates with internally signed certificates, which Node.js doesn’t trust unless they’re provided explicitly via NODE_EXTRA_CA_CERTS. Additional causes include incomplete proxy configuration (missing HTTP_PROXY or HTTPS_PROXY), proxies that don’t support or that mishandle CONNECT tunneling, network-level blocks of domains the AIO CLI requires, and corporate machines enforcing SSL inspection that breaks TLS chain validation.

How to confirm

  1. Identify the specific error type by re-running the failing command with verbose debugging:

    code language-none 
    DEBUG=* aio aem:rde:status

The terminal then displays full network stack traces, including certificate chain evaluation and proxy handshake attempts.
2. Confirm the presence of one of these patterns: SELF_SIGNED_CERT_IN_CHAIN, UNABLE_TO_VERIFY_LEAF_SIGNATURE, ECONNREFUSED, or 403 Proxy Authentication. If no detailed error appears, re-run in Node.js debug mode:

export NODE_DEBUG=http,https

Resolution resolution

  1. If the error contains self signed certificate in certificate chain or similar, configure Node.js to trust the corporate proxy certificate. Obtain the proxy’s root CA certificate in .pem form and set the NODE_EXTRA_CA_CERTS variable.

    code language-none 
    export NODE_EXTRA_CA_CERTS=/path/to/your/corp.pem

    On Windows PowerShell:

    code language-none 
    $env:NODE_EXTRA_CA_CERTS="C:\path\corp.pem"

    Re-run the failing aio command; the certificate errors should no longer appear. If the certificate isn’t accepted, confirm it’s a Base64-encoded PEM and convert it if needed:

    code language-none 
    openssl x509 -inform der -in cert.cer -out cert.pem

  2. Configure proxy routing explicitly if the environment uses an outbound proxy. Set both environment variables, replacing the placeholders with your values:

    code language-none 
    export HTTP_PROXY="http://<user>:<pass>@<proxy>:<port>"
export HTTPS_PROXY="http://<user>:<pass>@<proxy>:<port>"

    You can also configure AIO directly with aio config:set HTTP_PROXY and aio config:set HTTPS_PROXY. Run aio info and confirm it lists non-empty proxy settings.

  3. Test access outside the corporate VPN or LAN to isolate network filtering. Switch to a home network or disable the VPN, then run:

    code language-none 
    aio cloudmanager:list-programs

    If the command succeeds off-network and returns normal JSON output, the issue is corporate filtering.

  4. Request that corporate IT allowlist the required Adobe endpoints from SSL interception: cloudmanager.adobe.io, *.adobe.io, and *.adobeioruntime.net. Once the proxy stops rewriting certificates for these domains, the command succeeds without needing NODE_TLS_REJECT_UNAUTHORIZED=0.

  5. If RDE deploy fails with the Azure File Storage error UNABLE_TO_VERIFY_LEAF_SIGNATURE, request that IT allow outbound HTTPS to *.file.core.windows.net. Re-run the deployment and confirm the artifact upload reaches Azure without SSL errors.

  6. Confirm the Cloud Manager configuration in the CLI:

    code language-none 
    aio config:list

    Ensure cloudmanager_orgid, cloudmanager_programid, and cloudmanager_environmentid exist. If any are missing, set them manually with aio config:set, then confirm aio aem:rde:status returns environment details. If authentication is the problem, re-authenticate with aio login.

  7. If proxy authentication errors persist, update the Adobe I/O CLI to the latest version, since multiple proxy bugs have been patched:

    code language-none 
    npm uninstall -g @adobe/aio-cli && npm install -g @adobe/aio-cli

    Run aio info and confirm the version reflects a recent release. If the update fails, confirm your global npm permissions allow updates.

Validation

  1. Run aio aem:rde:status and confirm the command returns RDE runtime metadata rather than certificate or proxy errors.

  2. Run a small test deployment and confirm the Azure upload and RDE install succeed without SSL or proxy failures:

    code language-none 
    aio aem:rde:install -t env-config ./folder
recommendation-more-help
experience-cloud-kcs-help-kbarticles