Common ?? (seemingly no answer) - The request was aborted: Could not create SSL/TLS secure channel

jeighsohn
jeighsohn Member Posts: 15
in NAV Three Tier
Hello, I have searched the forum for this topic and found many threads that all ultimately end with no resolution. We have a legacy NAV2013 install that is being replaced by another ERP at some point soon :( I have written a REST API call in this NAV2013 instance to call FedEx to get shipping rates. The FedEx call requires an OAUTH2 token, and everytime I try to call this OAUTH API, I get the error: The request was aborted: Could not create SSL/TLS secure channel. I have tried all the hints suggested across the very many threads I found on this topic. I specify ServicePointManager.SecurityProtocol(SecurityProtocol.Tls12); I've had our ops team install a newer .NET runtime, but cannot get past this. Fun part, this worked as of fall 2023. I can do all of the required calls just fine from Postman.

Is there something I need to configure differently on the application server or database server? We have other RESTful API calls working just fine (and those also specify TLS1.2).

Answers

  • Sean56
    Sean56 Member Posts: 4
    This is a known issue with legacy NAV versions like NAV 2013 — especially when working with modern OAuth2 APIs over TLS 1.2, like FedEx. Even if you’ve set ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12, NAV 2013 runs on .NET Framework 4.0 or earlier by default, which doesn’t fully support TLS 1.2 without additional system configuration.

    Key things to check:
    .NET Framework Upgrade:
    Make sure the NAV service tier is running on .NET Framework 4.5 or later (ideally 4.7+). Installing it isn’t enough — the NAV service must be compiled and launched using the newer version.

    Force TLS1.2 at registry level:
    Set these registry keys on both the NAV service tier and database server:

    ini
    Copy
    Edit
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
    "SchUseStrongCrypto"=dword:00000001
    "SystemDefaultTlsVersions"=dword:00000001
    Application Pool (if using Web Services):
    If your NAV REST API is hosted in IIS, ensure the App Pool is using .NET CLR v4 and has access to the TLS 1.2 stack.

    NAV’s C/AL code still may not support it properly
    Even with system-level fixes, NAV 2013’s C/AL Automation objects might still fail to negotiate modern TLS handshakes. You might need to offload the token request to an external service (like a small .NET app or Azure Function) and have NAV just call that for the token.

    Why it worked in 2023 but not now:
    FedEx may have disabled older ciphers or tightened their TLS/SSL requirements, causing NAV 2013 to fail if it can't fully meet those new handshake requirements.

    In short: try the registry tweaks and verify .NET version first. If that doesn’t work, a lightweight external service to handle OAuth2 is often the most reliable workaround in legacy NAV environments.

Categories