openapi-generator
openapi-generator copied to clipboard
[BUG][C#][csharp] Use RestClient.RemoteCertificateValidationCallback for SSL validation
The RestSharp library is used to call methods.
The RestClient class has a RemoteCertificateValidationCallback method that works similar to HttpWebRequest.ServerCertificateValidationCallback.
Why can't I use it?
I think it would be logical to be able to process this delegate through IReadableConfiguration
I have seen this problem with both csharp
and csharp-netcore
generators.
What is more frightening is that as far as I can tell, by default no SSL certificate verification is done, which opens up all C# generated clients to man-in-the-middle attacks.
Another thing I'll note, I wonder if the csharp
(not csharp-netcore
) generator is effectively deprecated/unmaintained? The first time I used it I ran into multiple glaring issues that have been fixed in csharp-netcore
but not backported to csharp
:
- #11488
- #11489
I think it is not deprecated, but there is a feeling that csharp generators in general are given less time
@RomanSoloweow In your testing, do you also observe that no SSL certificate verification is happening in the RestSharp generated client?
For example if you point your C# REST client at a server with a self-signed certificate, or point it at the IP address of the server rather than its hostname (e.g. https://10.0.0.1
) that no SSL verification errors are thrown?
It was I who tried to specify both the URL and the IP. In both cases, I can't control the verification of the certificate
It was I who tried to specify both the URL and the IP. In both cases, I can't control the verification of the certificate
And just to be clear, does it silently succeed without throwing an error, or does it fail and you can't control the verification to allow it to succeed?
I just want to make sure we are seeing the same behavior, thanks.
This causes an error because in my case, need to ignore the verification .
Due to the lack of control over verification, I cannot fully use the generator
Interesting. I see the opposite behavior with (C# 7.3, .NET Framework 4.7.2), all connections succeed even when they shouldn't.
You could try this solution:
- https://stackoverflow.com/a/56351003
Disregard my comments about validation always succeeding. I dug in deeper and a different framework I'm also using is messing with the global ServerCertificateValidationCallback
.
Yes, I also mentioned this callback.
I suggest the following solution: add a callback to IReadableConfiguration for csharp, which will then be added to RestClient. RemoteCertificateValidationCallback.
A little later I can issue this decision in the form of a PR. Or do it you if you have time now
I'm curious to see if there is any activity or a workaround available for this issue. I too need to ignore self-signed certs for testing purposes.
I suggest the following solution: add a callback to IReadableConfiguration for csharp, which will then be added to RestClient. RemoteCertificateValidationCallback.
I did exactly this in my generated client. Im open to make a PR but im never done one here.
Is this a breaking change with fallback if the RemoteCertificateValidationCallback
is implementet with a default null
?
Can go in to the next release (no beaking changes) or does it have to go in the next minor release (breaking changes with fallback)?
@dlange-hima Thank you for adding the property in the IReadableConfiguration
. It seems you forgot to pass the callback to the RestClientOptions
in the ApiClient.ExecAsync<T>()
method.
You only passed the callback in the the synchronous version (ApiClient.Exec<T>()
) .
I will try to add it, but I'm not sure how much time I have this and next week. I hope that I can squeeze it in somehow.
I just saw that it was already fixed in https://github.com/OpenAPITools/openapi-generator/pull/16886