Sitelet https://github.com/npgsql/npgsql/issues/3718
Skip to content

Specified SSL Protocol Type is not Valid #3718

Closed
Bug
#3766
Closed
Specified SSL Protocol Type is not Valid#3718
Bug
#3766
Assignees
vonzshik
Milestone
6.0.0

Description

@TorsionTools
TorsionTools
opened on May 11, 2021

I am using an application that is imbedded within Autodesk Revit levering their open API. I have worked inside this context for a couple years and connected to other industry DB platform without any issues.

1. I have the application that makes a call to another dll (pgRDG)

using Autodesk.Revit.Attributes;
using Autodesk.Revit.DB;
using Autodesk.Revit.UI;

namespace RDG_Revit_2022.Testing
{
	[Transaction(TransactionMode.Manual)]
	class Test : IExternalCommand
	{
		public Result Execute(ExternalCommandData commandData, ref string message, ElementSet elements)
		{
			UIApplication uiapp = commandData.Application;
			Document doc = uiapp.ActiveUIDocument.Document;

			//This is the external reference call
			pg.RDG.Connection.Testing();
			return Result.Succeeded;
		}
	}
}

2. Then here is the Testing() method.

using System;
using System.Windows;
using Npgsql;

namespace pgRDG
{
	public class Connection
    {
        public static void Testing()
		{
			string ConnString = "Server=name.postgres.database.azure.com;Database=dbName;Port=5432;User Id=uid;Password=pw;Trust Server Certificate=true;Ssl Mode=Require";
			using(NpgsqlConnection conn = new NpgsqlConnection(ConnString))
			{
				try
				{
					conn.Open();
					NpgsqlCommand cmd = new NpgsqlCommand("SELECT * FROM tableName", conn);
					NpgsqlDataReader reader = cmd.ExecuteReader();
					while(reader.Read())
					{
						MessageBox.Show(reader.GetString(reader.GetOrdinal("command")));
					}
				}
				catch(Exception ex)
				{
					MessageBox.Show(ex.ToString());
				}
			}
		}
    }
}

The issue

  1. When I run this I receive the following error:
    image

If I run this exact same code from a desktop application it connects fine, but always produces this error within the Revit context.

I have also created a request on the Autodesk forums thinking someone there may have an idea as well.
https://forums.autodesk.com/t5/revit-api-forum/revit-2022-environment-preventing-ssl-handshake-with-postgresql/td-p/10304990

Further technical details

Npgsql version: 6.0.0-preview2
PostgreSQL version: Azure version 11
Operating system: Window 10 x64 - Visual Studio Pro 19 - v16.8.4
Autodesk Revit 2022

Activity

  1. vonzshik commented on May 11, 2021

    @vonzshik
    vonzshik
    on May 11, 2021
    Contributor

    Hello! Could you please try with 6.0.0-preview3? There actually was a small change with the SslProtocols just before we've released the third preview (2d3c2dc), which I believe should help you.

  2. TorsionTools commented on May 11, 2021

    @TorsionTools
    TorsionTools
    on May 11, 2021
    Author

    My apologies on the typo, but I am using preview3 currently.
    image

    Should I perhaps try to go the other way and downgrade?

  3. vonzshik commented on May 11, 2021

    @vonzshik
    vonzshik
    on May 11, 2021
    Contributor

    Yes, please. At the very least it will answer whether the problem is with Revit not supporting SslProtocols.None for some reason.

  4. TorsionTools commented on May 11, 2021

    @TorsionTools
    TorsionTools
    on May 11, 2021
    Author

    Thank you for the replies thus far.

    I went ahead and downgraded to preview2 and then to 5.0.4 (stable) and I am getting one dependency issue after another.

    This is what I got when I tried preview2. So, then I downgraded to version 5.0 for Json, but then the version of Bcl.Async was wrong.
    image

    Downgraded to 5.0.4 and now having issues with Threading.Tasks.Extensions, which is the reference I was fighting when I initially upgraded to preview3 because I couldn't get it to see the reference correctly.
    image

    Here are my configurations
    image

    image

    And here is an image of what my directory looks like with file versions to show I do have the files requested.
    image

  5. roji commented on May 11, 2021

    @roji
    roji
    on May 11, 2021
    Member

    @TorsionTools which version of .NET Framework are you targeting?

  6. roji commented on May 11, 2021

    @roji
    roji
    on May 11, 2021
    Member

    Regardless, unfortunately if you're targeting .NET Framework, you indeed must deal with binding redirects to make sure all versions are aligned and correct. IIRC nuget is supposed to update your binding redirects when you add a dependency, but I'm not sure exactly when/how that happens (plus you seem to be using the old packages.config system - consider changing to the new csproj with PackageReferences).

  7. TorsionTools commented on May 11, 2021

    @TorsionTools
    TorsionTools
    on May 11, 2021
    Author

    I am targeting 4.8.

    @roji I will upgrade and try again, but I had also tried that when I first ran into the issue, and changed back so I could make sure I know which packages / configurations were being targeted easier. I will try again. Thank you.

  8. TorsionTools commented on May 11, 2021

    @TorsionTools
    TorsionTools
    on May 11, 2021
    Author

    I went back around and tried using the packages.config approach but no such luck. Essentially preview3 is the only one that gets me past all the reference issues described in #2677 but then I am back to having the invalid SSL Protocol. I am going to follow a couple of the examples and see if I can build the npgsl from source using the local references. Thanks for all the responses, I will circle back if I can get it to work.

  9. TorsionTools commented on May 12, 2021

    @TorsionTools
    TorsionTools
    on May 12, 2021
    Author

    I wanted to circle back on this and I am back to where I started. I either have the reference issues or an SslProtocol that won't work. Is there any way to allow us to set this as a part of the connection parameters as referenced by
    @vonzshik above in 2d3c2dc ?

  10. vonzshik commented on May 13, 2021

    @vonzshik
    vonzshik
    on May 13, 2021
    Contributor

    @TorsionTools I've found this thread (robinrodricks/FluentFTP#452), which suggests that there are cases when SslProtocol.None might not be supported on .NET Framework due to it being disabled in OS.

    In light of this, I think it's easier to just revert 2d3c2dc, as adding a new connection string param just to fix this particular issue (note, that there is no such issue with .net core) seems to me a little bit overkill.

  11. roji commented on May 13, 2021

    @roji
    roji
    on May 13, 2021
    Member

    I definitely agree with @vonzshik that a connection string param doesn't make sense here.

    However, another option is to do runtime detection and select SslProtocol as a function of that (or even conditional compilation for .NET Standard 2.0). I still think it's better for us to specify SslProtocol.None, and it would be a shame to not do that because of .NET Framework...

  12. vonzshik commented on May 13, 2021

    @vonzshik
    vonzshik
    on May 13, 2021
    Contributor

    However, another option is to do runtime detection and select SslProtocol as a function of that (or even conditional compilation for .NET Standard 2.0). I still think it's better for us to specify SslProtocol.None, and it would be a shame to not do that because of .NET Framework...

    Sure, works for me.

  13. TorsionTools commented on May 13, 2021

    @TorsionTools
    TorsionTools
    on May 13, 2021
    Author

    Thanks @roji and @vonzshik for looking into this and any support you can offer is greatly appreciated in future releases!

  14. vonzshik
    self-assigned this
    on May 21, 2021
  15. vonzshik
    added
    bug
    on May 21, 2021
  16. vonzshik
    added this to the 6.0.0 milestone on May 21, 2021
  17. vonzshik
    closed this as completedin #3766on May 21, 2021
  18. vonzshik
    added a commit that references this issue on May 21, 2021

    Fixed ssl protocols for .net framework (#3766)

    65d0a3c

  19. TorsionTools commented on May 21, 2021

    @TorsionTools
    TorsionTools
    on May 21, 2021
    Author

    I appreciate you all working on this. Preview3 (6.0.0) was the first install that got past the missing reference for Text.JSON but it was throwing this SSL Protocol error for me. I have downloaded the latest unstable version (20210521T094529 which doesn't throw the SSL Protocol warning or at least doesn't get there because its back missing references for Text.JSON 5.0.0.0 even with redirects for 5.0.0.2.

  20. TorsionTools commented on Aug 11, 2021

    @TorsionTools
    TorsionTools
    on Aug 11, 2021
    Author

    I know this issue is closed, but I wanted to circle back around and give a report on how I got it all working in case it can help someone else.

    1. The SSLProtocol was fixed when with the edits from the team.
    2. My secondary issues were based on getting the correct assemblies referenced using Assembly.LoadFrom() context for nearly every referenced library.
    3. The TypeMapper was fixed by also loading the Npgsql.Json.Net NuGet and specifically labeling the Mapper to use that in lieu of System.Text.Json I guess. Seems like this should have worked without having to set it, but I just may not fully grasp what its doing either.

    AppDomain Assembly Resolver

    //Us a Resolver to locate and pass assemblies when not found
AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;

//Check for the name of the assembly as not to pass the wrong one and only when its one specific
private Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
		{
			string filename = Path.Combine(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), "References");

			if(args.Name.Contains("Azure.Core"))
			{
				filename = Path.Combine(filename, "Azure.Core.dll");
				if(File.Exists(filename))
				{
					return Assembly.LoadFrom(filename);
				}
			}
			else if(args.Name.Contains("Azure.Identity"))
			{
				filename = Path.Combine(filename, "Azure.Identity.dll");
				if(File.Exists(filename))
				{
					return Assembly.LoadFrom(filename);
				}
			}
			else if(args.Name.Contains("Dapper"))
			{
				filename = Path.Combine(filename, "Dapper.dll");
				if(File.Exists(filename))
				{
					return Assembly.LoadFrom(filename);
				}
			}
			else if(args.Name.Contains("System.Threading.Tasks.Extensions"))
			{
				filename = Path.Combine(filename, "System.Threading.Tasks.Extensions.dll");
				if(File.Exists(filename))
				{
					return Assembly.LoadFrom(filename);
				}
			}
			else if(args.Name.Contains("Npgsql"))
			{
				filename = Path.Combine(filename, "Npgsql.dll");
				if(File.Exists(filename))
				{
					return Assembly.LoadFrom(filename);
				}
			}
			else if(args.Name.Contains("Microsoft.Bcl.AsyncInterfaces"))
			{
				filename = Path.Combine(filename, "Microsoft.Bcl.AsyncInterfaces.dll");
				if(File.Exists(filename))
				{
					return Assembly.LoadFrom(filename);
				}
			}

			return null;
		}

    GlobalTypeMapper for System.Text.Json

    //Set the Type Mapper in a method or on the connection
NpgsqlConnection.GlobalTypeMapper.UseJsonNet();

//Include the Npgsql.Json.NET package
    </PackageReference>
    <PackageReference Include="Npgsql.Json.NET">
      <Version>5.0.7</Version>
    </PackageReference>

    Here are the redirects as of 5.0.7

    <configuration>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
    </dependentAssembly>
    <dependentAssembly>
      <assemblyIdentity name="System.Text.Json" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
    </dependentAssembly>
  </assemblyBinding>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Identity.Client" publicKeyToken="0a613f4dd989e8ae" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.30.1.0" newVersion="4.30.1.0" />
      </dependentAssembly>
    </assemblyBinding>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Buffers" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.3.0" newVersion="4.0.3.0" />
      </dependentAssembly>
    </assemblyBinding>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Memory" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.1.1" newVersion="4.0.1.1" />
      </dependentAssembly>
    </assemblyBinding>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.5.0" newVersion="4.0.5.0" />
      </dependentAssembly>
    </assemblyBinding>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Text.Encodings.Web" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.5.1" newVersion="4.0.5.1" />
      </dependentAssembly>
    </assemblyBinding>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
      </dependentAssembly>
    </assemblyBinding>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.ValueTuple" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.3.0" newVersion="4.0.3.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

  21. roji commented on Sep 4, 2024

    @roji
    roji
    on Sep 4, 2024
    Member

    Note that we're merging #5823, which for .NET Standard 2.0 attempts to auto-detect whether the operating system supports SslProtocols.None or not, and uses None when it is - this unblocks people from using TLS1.3 (which can't be specified in SslProtocols in .NET Standard).

  22. roji
    added the
    Bug
    issue type on Jun 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

Bug

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions