Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Common ?? (seemingly no answer) - The request was aborted: Could not create SSL/TLS secure channel
jeighsohn
Member Posts: 15
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).
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).
0
Answers
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.