1

Since today, I am receiving the following error message when sending a package:

Error calling Login: The request was aborted: Could not create SSL/TLS secure channel.

My code

StringBuilder authHeader = new StringBuilder(
                $"{{\"Username\":\"{userId}\", \"Password\":\"" +
                $"{password}\", \"IntegratorKey\":\"{IntegratorKey}\"");

            authHeader.Append(
                string.IsNullOrEmpty(senderEmail)
                    ? "}}"
                    : $",\"SendOnBehalfOf\": \"{senderEmail}\"}}");

            Configuration.Default.AddDefaultHeader(
                "X-DocuSign-Authentication",
                authHeader.ToString());

            AuthenticationApi api = new AuthenticationApi();
            return api.Login();

Coincidently, today is THE day where TLS1.0 was disables on the demo site of DocuSign. (source) enter image description here While I was aware of that, my application uses the .NET 4.7 framework which will uses TLS1.2 by default. Hence, it should not be a problem As I use the DocuSign NuGet package found here, I looked in the source code and it uses .NET 4.5 (which uses TLS1.0 unless told otherwise)

I understand that I could implement this solution but, shouldn't it work since my application uses .NET 4.7 ?

Frederic
  • 2,015
  • 4
  • 20
  • 37
  • I don't think the community can help you here. It seems that you need to wait until that library is updated – Camilo Terevinto May 29 '18 at 21:45
  • Sure, but I would have thought that DocuSign would have upgraded the library before removing the TLS1.0 support, at least that's what makes sense to me.... – Frederic May 29 '18 at 21:52
  • What .Net 4.7 offers in terms of TLS options is one thing. What `ServicePointManager` defaults to is another. `ServicePointManager` (up to .Net 4.7.1) negotiates SSL3 and TLS 1.0. You have to explicitly enable the protocol (excluding the others in the process, setting `ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12`) if you want to be sure that TLS 1.2 is negotiated. Then, it depends on the Server what it can agree upon in the handshake. But if TLS1.2 is not enabled, it will not be negotiated . – Jimi May 29 '18 at 23:39
  • I forgot to mention, you can check what SSL protocol version was negotiated using this: [Which TLS version was negotiated?](https://stackoverflow.com/questions/48589590/which-tls-version-was-negotiated?answertab=active#tab-top) – Jimi May 30 '18 at 01:30
  • @Jimi: Thanks but in case you didn't notice, I am the one who originally asked for this question "Which Tls version was negotiated" so I am aware of that. The answer would work only if I were to modify the DocuSign SDK which I am not interested to do as I want to use the official one – Frederic May 30 '18 at 03:37
  • HA! That's hilarious! Sorry, I didn't check the "OP" nick before commenting :). Have you verified this, setting and non-setting the ServicePointManager protocol? – Jimi May 30 '18 at 03:42
  • Yeah no worries :-) Yep I tried setting the ServicePointManagerProtocol and while it worked well, I originally thought that having my program use .NET 4.7 would lead to use TLS1.2 automatically. And it seems to be bad practice as it means that I will have to change my code again when I want to use TLS 1.3 – Frederic May 30 '18 at 03:44
  • Yes, well, we all thought that. TLS 1.3 should be different in many ways. More self-aware (hoping that the implementation will be as well). – Jimi May 30 '18 at 03:45
  • Btw, if you haven't noticed, I've updated the "linked answer", because it wasn't getting right the compressed streams (`GzipStream` and `DeflateStream`). And, sadly, I haven't found any other way to get to the SSLProtocol without reflection. In a way or another, you always bang your head against a non-public .Net class. – Jimi May 30 '18 at 04:00

1 Answers1

1

TLS 1.1 or above is required for all DocuSign APIs and endpoints. All our libraries now support TLS 1.2 including the the DocuSign eSign C# Nuget package. See here - https://support.docusign.com/en/articles/End-of-TLS-1-0-and-weak-cipher-support

Inbar Gazit
  • 12,566
  • 1
  • 16
  • 23