[Draft] Error connecting to downstream service, exception:

[Cherry542]

Expected Behavior / New Feature

When Ocelot uses HTTPS, how to disable certificate validation and avoid errors from self-signed certificates?

Actual Behavior / Motivation for New Feature

Steps to Reproduce the Problem

warn: Ocelot.Responder.Middleware.ResponderMiddleware[0]
requestId: 0HMR0SBG3UKLQ:00000002, previousRequestId: no previous request id, message: Error Code: ConnectionToDownstreamServiceError Message: Error connecting to downstream service, exception: System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure: RemoteCertificateNameMismatch
at System.Net.Security.SslStream.SendAuthResetSignal(ProtocolToken message, ExceptionDispatchInfo exception)
at System.Net.Security.SslStream.CompleteHandshake(SslAuthenticationOptions sslAuthenticationOptions)
at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean isApm)
at System.Net.Http.ConnectHelper.EstablishSslConnectionAsync(SslClientAuthenticationOptions sslOptions, HttpRequestMessage request, Boolean async, Stream stream, CancellationToken cancellationToken)

Specifications

• Version:
• Platform:
• Subsystem:

[raman-m]

Hi Cherry!

Why are you asking the Ocelot team to fix your SSL-certificate?

You have to show us the direct connection between the client and deployed service is working and your SSL-certificate is valid. After that you need to show that Ocelot breaks communication really, and we have a potential bug in Ocelot core. So, you have to show a root cause of the issue!

---

Error Code: ConnectionToDownstreamServiceError Message: Error connecting to downstream service, exception: System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure: RemoteCertificateNameMismatch

Pay attention that for https-deployment scenarios (downstream service has been deployed with downstream scheme https) you have to generate service host SSL-certificate. After that your SSL-certificate public keys must be installed at gateway host machine. If gateway host is Docker container, you must install this SSL-certificate using host OS tools. It depends on OS type, Linux or Windows. Each operating system has own procedure of SSL-certificate installation.

For localhost development scenarios I would recommend to use http-protocol first, to be able to finish development. After that you can start upgrading the solution to https communication.

Make sense?
Hope it helps!

[raman-m]

@Cherry542

Let's find some workaround in a week please!
Your issue will be accepted or declined in one week till June 7.

Please, use the issue template while creating an issue via pressing the New Issue button!
Examples of bugs: #1636, #1660, #1590. Examples of features: #1637, #1400

Because you create a bug, you need to:

• specify Expected & Actual behavior.
• share details in "Steps to Reproduce the Problem"!
• share info about the Ocelot version
• give details on environment you use, aka Specifications paragraph

After providing all this info we will decide what to do with this issue.

P.S. Start using markdown code blocks with correct language to provide nice and easy to read configs in description.

[Cherry542]

Dear Ocelot team, my intention here is not to ask you to fix my SSL certificate issues. Sometimes due to special requirements and reasons, we have to configure HTTPS. However, currently if downstream services and the gateway are both using HTTPS, HTTPS certificates must be used. However, using HTTPS certificates is quite troublesome.

1. Either download the certificates and then modify the host file to support them.
2. Or use self-signed certificates, but self-signed certificates will basically report errors in browsers, indicating that the certificate is insecure.
   Ocelot will report the errors I submitted when using insecure certificates downstream. My current solution is to use self-signed certificates and then configure "dangerousAcceptAnyServerCertificateValidator": true in Ocelot to disable certificate verification. However, this solution requires the use of HTTPS certificates. If no certificates are used, an error will be reported.
   I would like to ask the Ocelot team if you can provide a feature that can run even if HTTPS certificates do not exist. This can bring a lot of convenience to the development environment. After all, certificates are often added through Nginx, and certificates are rarely bound directly in the application.
   My purpose here is to let me know if there is such a feature. If not, this is a suggestion. Of course, I can also modify the source code to solve it myself. Thank you Ocelot team for taking the time to look at this suggestion!
   In summary, the user hopes that Ocelot can provide an option to work normally even if downstream services do not provide HTTPS certificates, to facilitate the use of the development environment. The current workaround is to configure dangerousAcceptAnyServerCertificateValidator to disable certificate verification, but this requires downstream services to have certificates to take effect.
   So the user's meaning is that it is hoped that Ocelot can provide an option to communicate normally even if downstream services do not provide any certificates, so as to simplify the configuration of the development environment. If Ocelot does not currently have this feature, this is also a suggestion, and users can modify the source code themselves to achieve it.
   The user makes a very good suggestion here to simplify Ocelot's configuration requirements in the development environment and improve development efficiency. This is an option worth considering by the Ocelot team. thank

[raman-m]

When Ocelot uses HTTPS, how to disable certificate validation and avoid errors from self-signed certificates?

Solution: SSL Errors

---

Or use self-signed certificates, but self-signed certificates will basically report errors in browsers, indicating that the certificate is insecure.

Why do you use self-signed certificates for development environment? Roll back from https to http protocol!
And your sentence is partially true. If you install self-signed certificate at your host with browser to Trusted Root Certification Authorities Certificate Store or another Trusted folder then your browser should be able to communicate without SSL-errors.

---

So the user's meaning is that it is hoped that Ocelot can provide an option to communicate normally even if downstream services do not provide any certificates, so as to simplify the configuration of the development environment.

If the downstream service doesn't have any certificates that means it is not deployed using https-protocol. No SSL errors at all. You can go with http-protocol.
If the downstream service has SSL-certificates and it is deployed with https-protocol that means you will have zero errors (no errors at all). It is mostly Production environment case for the downstream service.
If the downstream service has self-signed SSL-certificate and it is deployed with https-protocol that means you develop this service. You have everything under control. And you can switch from https to http protocol easily to eliminate all SSL errors in logs! This case is for your development environment.

Conclusion:

• Use http protocol for the DownstreamScheme option of a route for your downstream service in development environment!
• Use https protocol for the DownstreamScheme option of a route, and remote machine has valid SSL-certificates for downstream service which is in Production environment! Probably your gateway host must have installed root-certificates of signing authorities!
• Use https protocol for the DownstreamScheme option of a route, and install self-signed SSL-certificates from the remote host of downstream service. Or provide the DangerousAcceptAnyServerCertificateValidator setting in the route to eliminate all SSL Errors in your logs. This is the case for your development environment!

---

My purpose here is to let me know if there is such a feature. If not, this is a suggestion. Of course, I can also modify the source code to solve it myself. Thank you Ocelot team for taking the time to look at this suggestion!

I do not see any suggestions from your side. I see zero suggestions and feature requesting! I still see very short description of the issue. And I don't still understand either it is a feature or a bug?
From my side I've provided you Conclusion suggestion how to deal with environments and https protocol.
You should understand that Ocelot is content-based reverse proxy! We must have a content to route! To get a content we have to care about protocols of downstream services we're communicating to. We have to provide correct settings for a route with possible artifacts of communication protocol. That means if communication between the client and downstream server has failed, then communication between Ocelot gateway and downstream server will also fail.

If you will show us your feature and/or bug fix request better we will be happy to review the request and accept it after discussions.

P.S. Please, do not use Google Translate or Bing Translate online services to translate your China texts to English!

[Cherry542]

Okay, I've looked at the source code and your response, and I roughly understand your design intentions. What I'm mainly seeking is the best practice for HTTPS solutions in a development environment. Thank you for your guidance.

[raman-m]

@Cherry542
Does it mean you can close the issue after my consultancy?
Is everything clear now?