GRPC not working with https #7248

AdrianoAE · 2024-04-06T20:14:14Z

Expected Behavior

Be able to call GRPC server with https endpoint.

Actual Behavior

When running GRPC server in .NET the endpoint will be https://localhost:XXXX, the current parser does not allow to specify https and the connection fails.

Error invoking remote method 'grpc.loadMethodsFromReflection': Error: 14 UNAVAILABLE: Name resolution failed for target dns:https://localhost:51811

The server is running properly since Postman has no issues, insomnia can't connect at all. Replacing https with grpcs does not work.

Reproduction Steps

No response

Is there an existing issue for this?

I have searched the issue tracker for this problem.

Additional Information

No response

Insomnia Version

8.6.1

What operating system are you using?

Windows

Operating System Version

Windows 11

Installation method

insomnia.rest

Last Known Working Insomnia version

No response

The text was updated successfully, but these errors were encountered:

subnetmarco · 2024-04-12T15:09:46Z

This seems to be more of a DNS problem that a TLS problem. Can you try to consume https://127.0.0.1:51811 ?

AdrianoAE · 2024-04-12T17:39:55Z

I've tried that, but gave it another try

AdrianoAE · 2024-04-25T20:42:21Z

any update on this?

jackkav · 2024-04-26T07:26:48Z

AFAIK it's atypical to use a http protocol to connect to a grpc server. Without a proxy, a regular gRPC server is expecting grpc://.

Please provide screenshots of both postman and insomnia including the request and response panes

AdrianoAE · 2024-04-26T21:46:45Z

There isn't much to show, it simply works with Postman

The implementation is done by Microsoft under https://github.com/grpc/grpc-dotnet

Tried with
127.0.0.1:51811
Error: 1 CANCELLED: Call cancelled

https://127.0.0.1:51811
Error: 14 UNAVAILABLE: Name resolution failed for target dns:https://127.0.0.1:51811

grpcs://127.0.0.1:51811
Error: 14 UNAVAILABLE: No connection established. Last error: unable to verify the first certificate (2024-04-26T21:44:31.816Z)

modestotech · 2024-05-14T12:51:45Z

Same problem. I'm exposing a .NET Web API on 5002 (HTTP) and (5052 (HTTPS), after creating a project from the .NET GRPC service template.

HTTP works.
HTTPS doesn't.

In Postman both just works.

Setup:

HTTP response:

HTTPS response:

jackkav · 2024-05-19T18:07:23Z

Postman is a closed source project. So I can't compare their implementation to insomnia, if you could try grpcurl or grpcui and let us know if it works for you that would be a huge help for us to solve this for you.

@modestotech could you take a look at the .NET logs and see if this comment looks familar grpc/grpc-node#2340 (comment)

rizanzaky · 2024-07-08T10:08:55Z

here's the endpoint tried via grpcurl

here's the endpoint tried via postman,

here's the error in insomnia,

Gradlon · 2024-08-26T09:07:19Z

I have the same issue.
It tries to resolve https:// as far as I understand this.
There is no setting to change to TLS in insomnia.

After some testing: use grpcs:// insted of https!
This solved my problem.

subnetmarco · 2024-08-30T14:37:56Z

@jackkav any feedback based on the last comments?

darnley · 2024-09-21T19:03:00Z

Same here.

jackkav · 2024-09-23T08:00:25Z

You must provide grpcs:// in order to use gRPC TLS.

gRPC's use of HTTP/2 is considered complex. It makes it impossible to implement a gRPC client in the browser, instead requiring a proxy. - wikipedia

gRPC/S is not reachable over HTTP/S. From your screenshot I see that in postman you don't provide a protocol fragment in your url and it is assuming you have TLS enabled. Insomnia works similarly but we assume you are not using TLS if you don't provide the protocol.

export const parseGrpcUrl = (grpcUrl: string): { url: string; enableTls: boolean } => {
  if (!grpcUrl) {
    return { url: '', enableTls: false };
  }
  const lower = grpcUrl.toLowerCase();
  if (lower.startsWith('grpc://')) {
    return { url: lower.slice(7), enableTls: false };
  }
  if (lower.startsWith('grpcs://')) {
    return { url: lower.slice(8), enableTls: true };
  }
  return { url: lower, enableTls: false };
};

As you can see TLS is only enabled when grpcs is provided. gRPC doesn't gracefully downgrade, so insomnia needs to know if your server has TLS enabled or not and the grpcs:// prefix implicitly tells it that.

I'm not sure changing this default will be desirable for our existing users. I'm also unsure of any UX that would make this clearer without introducing more inconsistency between various request types.

As in the case of @Gradlon providing the protocol is the solution here.

AdrianoAE · 2024-09-23T19:12:27Z

Thanks for your answer @jackkav but as I mentioned previously it also does not work with grpcs:

grpcs://127.0.0.1:51811
Error: 14 UNAVAILABLE: No connection established. Last error: unable to verify the first certificate (2024-04-26T21:44:31.816Z)

jackkav · 2024-09-25T07:32:53Z

@AdrianoAE were you able to get it to work with the two other open source grpc clients I listed above?

Last error: unable to verify the first certificate
How are you configuring the TLS "first certificate"? Is it automatically provided by your API framework?

According to this issue, and the linked article, there are 2 forms of gRPC TLS. Insomnia only currently supports insecure and service side TLS. It is possible your server is expecting a mutual TLS connection. If that were the case, we would need to wire up a cert config to both HTTP and gRPC requests and you would need to provide insomnia with a 3 certificate files to pass to the server.

I can take a look and see if we can add mTLS support in #8002 but I'm still not sure this is the issue you are facing since its not clear if you have implemented server side TLS or mutual TLS.

darnley · 2024-09-25T22:54:28Z

Hello, @jackkav.

I am trying to do the same as the others above.
I created a gRPC endpoint that is exposed using HTTPS. There is a greet.proto file:

syntax = "proto3";

service Greeter {
    rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
    string name = 1;
}

message HelloReply {
    string message = 1;
}

I tried using grpccurl in a Docker container with the following command, but I encountered an error:

$ docker run fullstorydev/grpcurl host.docker.internal:5001 Greeter/SayHello
Failed to dial target host "host.docker.internal:5001": tls: failed to verify certificate: x509: certificate is valid for localhost, Riddle, not host.docker.internal

This is expected because I had not added "host.docker.internal" to the self-signed certificate.

After adding it, I ran the same command again and received the following error:

$ docker run fullstorydev/grpcurl host.docker.internal:5001 Greeter/SayHello
Failed to dial target host "host.docker.internal:5001": tls: failed to verify certificate: x509: certificate signed by unknown authority

This is correct because the CA is not trusted. Since I wanted to make an insecure request, I configured grpccurl to bypass certificate validation by adding the -insecure argument, and IT WORKED:

$ docker run fullstorydev/grpcurl -insecure host.docker.internal:5001 "Greeter/SayHello"
{
  "message": "Olá"
}

Then, I went to grpcui to try the same and it worked as well.

$ .\grpcui.exe -insecure localhost:5001

Then, I went to Postman, disabled server certificate validation in the settings, and it worked as well.

Next, I went to Insomnia, and in Application > Preferences, I unchecked the "Validate certificates" checkbox to disable certificate validation.

When calling the same host and port, but adding grpcs:// at the beginning, I received a certificate error:

Error: Error invoking remote method 'grpc.loadMethodsFromReflection': Error: 14 UNAVAILABLE: No connection established. Last error: unable to verify the first certificate (2024-09-25T23:14:37.056Z)
    at IpcRenderer.invoke (node:electron/js2c/renderer_init:2:6995)
    at async onClick (file:///C:/Users/darnl/AppData/Local/insomnia/app-10.0.0/resources/app.asar/debug-h7Vgub6r.js:4:46578)

Since adding -insecure to grpccurl worked to skip server certificate verification, I believe Insomnia is not properly respecting this configuration.

darnley · 2024-09-26T00:53:39Z

Additionally, I saw in .NET console that when a request WORKS, I get the following logs:

dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[39]
      Connection id "0HN6TOO3KAD5D" accepted.
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[1]
      Connection id "0HN6TOO3KAD5D" started.
dbug: Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware[3]
      Connection 0HN6TOO3KAD5D established using the following protocol: Tls13
trce: Microsoft.AspNetCore.Server.Kestrel.Http2[49]
      Connection id "0HN6TOO3KAD5D" sending SETTINGS frame for stream ID 0 with length 18 and flags NONE.
trce: Microsoft.AspNetCore.Server.Kestrel.Http2[49]
      Connection id "0HN6TOO3KAD5D" sending WINDOW_UPDATE frame for stream ID 0 with length 4 and flags 0x0.
trce: Microsoft.AspNetCore.Server.Kestrel.Http2[37]
      Connection id "0HN6TOO3KAD5D" received SETTINGS frame for stream ID 0 with length 0 and flags NONE.
trce: Microsoft.AspNetCore.Server.Kestrel.Http2[49]
      Connection id "0HN6TOO3KAD5D" sending SETTINGS frame for stream ID 0 with length 0 and flags ACK.
trce: Microsoft.AspNetCore.Server.Kestrel.Http2[37]
      Connection id "0HN6TOO3KAD5D" received SETTINGS frame for stream ID 0 with length 0 and flags ACK.
trce: Microsoft.AspNetCore.Server.Kestrel.Http2[37]
      Connection id "0HN6TOO3KAD5D" received HEADERS frame for stream ID 1 with length 85 and flags END_HEADERS.
trce: Microsoft.AspNetCore.Server.Kestrel.Http2[37]
      Connection id "0HN6TOO3KAD5D" received DATA frame for stream ID 1 with length 5 and flags END_STREAM.
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/2 POST https://localhost:5001/Greeter/SayHello application/grpc -
trce: Microsoft.AspNetCore.HostFiltering.HostFilteringMiddleware[2]
      All hosts are allowed.
dbug: Microsoft.AspNetCore.Routing.Matching.DfaMatcher[1001]
      3 candidate(s) found for the request path '/Greeter/SayHello'
dbug: Microsoft.AspNetCore.Routing.Matching.DfaMatcher[1005]
      Endpoint 'gRPC - /Greeter/SayHello' with route pattern '/Greeter/SayHello' is valid for the request path '/Greeter/SayHello'
dbug: Microsoft.AspNetCore.Routing.Matching.DfaMatcher[1005]
      Endpoint 'gRPC - Unimplemented method for Greeter' with route pattern 'Greeter/{unimplementedMethod:grpcunimplemented}' is valid for the request path '/Greeter/SayHello'
dbug: Microsoft.AspNetCore.Routing.Matching.DfaMatcher[1005]
      Endpoint 'gRPC - Unimplemented service' with route pattern '{unimplementedService}/{unimplementedMethod:grpcunimplemented}' is valid for the request path '/Greeter/SayHello'
dbug: Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware[1]
      Request matched endpoint 'gRPC - /Greeter/SayHello'
dbug: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[15]
      Static files was skipped as the request already matched an endpoint.
info: Microsoft.AspNetCore.Routing.EndpointMiddleware[0]
      Executing endpoint 'gRPC - /Greeter/SayHello'
dbug: Grpc.AspNetCore.Server.ServerCallHandler[10]
      Reading message.
dbug: Microsoft.AspNetCore.Server.Kestrel[25]
      Connection id "0HN6TOO3KAD5D", Request id "0HN6TOO3KAD5D:00000001": started reading request body.
dbug: Microsoft.AspNetCore.Server.Kestrel[26]
      Connection id "0HN6TOO3KAD5D", Request id "0HN6TOO3KAD5D:00000001": done reading request body.
trce: Grpc.AspNetCore.Server.ServerCallHandler[12]
      Deserializing 0 byte message to 'HelloRequest'.
trce: Grpc.AspNetCore.Server.ServerCallHandler[13]
      Received message.
trce: Microsoft.AspNetCore.Server.Kestrel.Http2[49]
      Connection id "0HN6TOO3KAD5D" sending HEADERS frame for stream ID 1 with length 59 and flags END_HEADERS.
dbug: Grpc.AspNetCore.Server.ServerCallHandler[15]
      Sending message.
trce: Grpc.AspNetCore.Server.ServerCallHandler[18]
      Serialized 'HelloReply' to 6 byte message.
trce: Grpc.AspNetCore.Server.ServerCallHandler[16]
      Message sent.
info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1]
      Executed endpoint 'gRPC - /Greeter/SayHello'
trce: Microsoft.AspNetCore.Server.Kestrel.Http2[49]
      Connection id "0HN6TOO3KAD5D" sending DATA frame for stream ID 1 with length 11 and flags NONE.
trce: Microsoft.AspNetCore.Server.Kestrel.Http2[49]
      Connection id "0HN6TOO3KAD5D" sending HEADERS frame for stream ID 1 with length 15 and flags END_STREAM, END_HEADERS.
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/2 POST https://localhost:5001/Greeter/SayHello application/grpc - - 200 - application/grpc 71.3262ms
trce: Microsoft.AspNetCore.Server.Kestrel.Http2[37]
      Connection id "0HN6TOO3KAD5D" received WINDOW_UPDATE frame for stream ID 0 with length 4 and flags 0x0.
trce: Microsoft.AspNetCore.Server.Kestrel.Http2[37]
      Connection id "0HN6TOO3KAD5D" received PING frame for stream ID 0 with length 8 and flags NONE.
trce: Microsoft.AspNetCore.Server.Kestrel.Http2[49]
      Connection id "0HN6TOO3KAD5D" sending PING frame for stream ID 0 with length 8 and flags ACK.

However, when I call from Insomnia and it DOES NOT WORK, I got these logs.

dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[39]
      Connection id "0HN6TOO3KAD5E" accepted.
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[1]
      Connection id "0HN6TOO3KAD5E" started.
dbug: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[6]
      Connection id "0HN6TOO3KAD5E" received FIN.
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[39]
      Connection id "0HN6TOO3KAD5F" accepted.
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[1]
      Connection id "0HN6TOO3KAD5F" started.
dbug: Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware[1]
      Failed to authenticate HTTPS connection.
      System.IO.IOException:  Received an unexpected EOF or 0 bytes from the transport stream.
         at System.Net.Security.SslStream.<FillHandshakeBufferAsync>g__InternalFillHandshakeBufferAsync|189_0[TIOAdapter](TIOAdapter adap, ValueTask`1 task, Int32 minSize)
         at System.Net.Security.SslStream.ReceiveBlobAsync[TIOAdapter](TIOAdapter adapter)
         at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean isApm)
         at System.Net.Security.SslStream.ProcessAuthenticationWithTelemetryAsync(Boolean isAsync, Boolean isApm, CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware.OnConnectionAsync(ConnectionContext context)
dbug: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[6]
      Connection id "0HN6TOO3KAD5F" received FIN.
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[2]
      Connection id "0HN6TOO3KAD5E" stopped.
dbug: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[7]
      Connection id "0HN6TOO3KAD5E" sending FIN because: "The Socket transport's send loop completed gracefully."
dbug: Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware[1]
      Failed to authenticate HTTPS connection.
      System.IO.IOException:  Received an unexpected EOF or 0 bytes from the transport stream.
         at System.Net.Security.SslStream.<FillHandshakeBufferAsync>g__InternalFillHandshakeBufferAsync|189_0[TIOAdapter](TIOAdapter adap, ValueTask`1 task, Int32 minSize)
         at System.Net.Security.SslStream.ReceiveBlobAsync[TIOAdapter](TIOAdapter adapter)
         at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean isApm)
         at System.Net.Security.SslStream.ProcessAuthenticationWithTelemetryAsync(Boolean isAsync, Boolean isApm, CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware.OnConnectionAsync(ConnectionContext context)
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[2]
      Connection id "0HN6TOO3KAD5F" stopped.
dbug: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[7]
      Connection id "0HN6TOO3KAD5F" sending FIN because: "The Socket transport's send loop completed gracefully."
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[39]
      Connection id "0HN6TOO3KAD5G" accepted.
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[1]
      Connection id "0HN6TOO3KAD5G" started.
dbug: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[6]
      Connection id "0HN6TOO3KAD5G" received FIN.
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[39]
      Connection id "0HN6TOO3KAD5H" accepted.
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[1]
      Connection id "0HN6TOO3KAD5H" started.
dbug: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[6]
      Connection id "0HN6TOO3KAD5H" received FIN.
dbug: Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware[1]
      Failed to authenticate HTTPS connection.
      System.IO.IOException:  Received an unexpected EOF or 0 bytes from the transport stream.
         at System.Net.Security.SslStream.<FillHandshakeBufferAsync>g__InternalFillHandshakeBufferAsync|189_0[TIOAdapter](TIOAdapter adap, ValueTask`1 task, Int32 minSize)
         at System.Net.Security.SslStream.ReceiveBlobAsync[TIOAdapter](TIOAdapter adapter)
         at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean isApm)
         at System.Net.Security.SslStream.ProcessAuthenticationWithTelemetryAsync(Boolean isAsync, Boolean isApm, CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware.OnConnectionAsync(ConnectionContext context)
dbug: Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware[1]
      Failed to authenticate HTTPS connection.
      System.IO.IOException:  Received an unexpected EOF or 0 bytes from the transport stream.
         at System.Net.Security.SslStream.<FillHandshakeBufferAsync>g__InternalFillHandshakeBufferAsync|189_0[TIOAdapter](TIOAdapter adap, ValueTask`1 task, Int32 minSize)
         at System.Net.Security.SslStream.ReceiveBlobAsync[TIOAdapter](TIOAdapter adapter)
         at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean isApm)
         at System.Net.Security.SslStream.ProcessAuthenticationWithTelemetryAsync(Boolean isAsync, Boolean isApm, CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware.OnConnectionAsync(ConnectionContext context)
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[2]
      Connection id "0HN6TOO3KAD5H" stopped.
dbug: Microsoft.AspNetCore.Server.Kestrel.Connections[2]
      Connection id "0HN6TOO3KAD5G" stopped.
dbug: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[7]
      Connection id "0HN6TOO3KAD5H" sending FIN because: "The Socket transport's send loop completed gracefully."
dbug: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[7]
      Connection id "0HN6TOO3KAD5G" sending FIN because: "The Socket transport's send loop completed gracefully."

darnley · 2024-09-26T01:52:14Z

I got the logs from Insomnia logs folder. Holpe it helps.

[2024-09-25 22:42:43.265] [info]  [gRPC] connecting to url=localhost:5001 with TLS
[2024-09-25 22:42:43.731] [error] Error occurred in handler for 'grpc.loadMethodsFromReflection': Error: 14 UNAVAILABLE: No connection established. Last error: connect ECONNREFUSED 127.0.0.1:5001 (2024-09-26T01:42:43.731Z)
    at callErrorFromStatus (C:\Users\darnl\AppData\Local\insomnia\app-10.0.0\resources\app.asar\node_modules\@grpc\grpc-js\build\src\call.js:31:19)
    at Object.onReceiveStatus (C:\Users\darnl\AppData\Local\insomnia\app-10.0.0\resources\app.asar\node_modules\@grpc\grpc-js\build\src\client.js:421:73)
    at Object.onReceiveStatus (C:\Users\darnl\AppData\Local\insomnia\app-10.0.0\resources\app.asar\node_modules\@grpc\grpc-js\build\src\client-interceptors.js:323:181)
    at C:\Users\darnl\AppData\Local\insomnia\app-10.0.0\resources\app.asar\node_modules\@grpc\grpc-js\build\src\resolving-call.js:129:78
    at processTicksAndRejections (node:internal/process/task_queues:77:11)
    at runNextTicks (node:internal/process/task_queues:64:3)
    at process.processImmediate (node:internal/timers:454:9)
for call at
    at ServiceClientImpl.makeBidiStreamRequest (C:\Users\darnl\AppData\Local\insomnia\app-10.0.0\resources\app.asar\node_modules\@grpc\grpc-js\build\src\client.js:405:32)
    at ServiceClientImpl.serverReflectionInfo (C:\Users\darnl\AppData\Local\insomnia\app-10.0.0\resources\app.asar\node_modules\@grpc\grpc-js\build\src\make-client.js:105:19)
    at C:\Users\darnl\AppData\Local\insomnia\app-10.0.0\resources\app.asar\node_modules\grpc-reflection-js\build\src\client.js:55:46
    at new Promise (<anonymous>)
    at Client.listServices (C:\Users\darnl\AppData\Local\insomnia\app-10.0.0\resources\app.asar\node_modules\grpc-reflection-js\build\src\client.js:36:16)
    at getMethodsFromReflection (C:\Users\darnl\AppData\Local\insomnia\app-10.0.0\resources\app.asar\main.min.js:68538:35)
    at loadMethodsFromReflection (C:\Users\darnl\AppData\Local\insomnia\app-10.0.0\resources\app.asar\main.min.js:68586:25)
    at C:\Users\darnl\AppData\Local\insomnia\app-10.0.0\resources\app.asar\main.min.js:68390:71
    at WebContents.<anonymous> (node:electron/js2c/browser_init:2:83553)
    at WebContents.emit (node:events:519:28)

darnley · 2024-09-26T02:00:54Z

Just a thought...

Since I am seeing the log ... with TLS, the gRPC client is being generated using credentials.createSsl() instead of credentials.createInsecure().

https://github.com/Kong/insomnia/blob/08e20b65d03d213eb2cee275de0

insomnia/packages/insomnia/src/main/ipc/grpc.ts

Lines 362 to 365 in 08e20b6

    
           console.log(`[gRPC] connecting to url=${url} ${enableTls ? 'with' : 'without'} TLS`); 
        
           // @ts-expect-error -- TSCONVERSION second argument should be provided, send an empty string? Needs testing 
        
           const Client = makeGenericClientConstructor({}); 
        
           const client = new Client(url, enableTls ? credentials.createSsl() : credentials.createInsecure());

@jackkav, is it possible that we should use credentials.createInsecure() when configured to not validate certificates? The enableTls variable is set based on whether the URL starts with grpcs:// (here), but if I have configured it to not validate certificates, I would not want to use credentials.createSsl().

The createSsl function validates all the things...
https://github.com/grpc/grpc-node/blob/3c9436be8eb3788173796d4c90d2abe036d0f798/packages/grpc-js/src/channel-credentials.ts#L122-L148

While the createInsecure appear to skip everything...
https://github.com/grpc/grpc-node/blob/3c9436be8eb3788173796d4c90d2abe036d0f798/packages/grpc-js/src/channel-credentials.ts#L170-L193

I saw this PR on grpc/grpc-node adding reject authorization for TLS 2 days ago. Maybe this is also an alternative to be passed in createSsl as a value of verifyOptions argument.
grpc/grpc-node#2812

jackkav · 2024-09-26T12:32:19Z

@darnley Nice catch, thanks for sharing. I think we could just wire up this skip verification argument to the insomnia general preferences and it should unblock this. I think we need to wait a week or two for the next grpc-js to go out.

I tried to use createInsecure with a local gRPC tls server and got the same Error 14 UNAVAILABLE, so I guess we can just wait.

darnley · 2024-09-27T00:36:35Z

@darnley Nice catch, thanks for sharing. I think we could just wire up this skip verification argument to the insomnia general preferences and it should unblock this. I think we need to wait a week or two for the next grpc-js to go out.

I tried to use createInsecure with a local gRPC tls server and got the same Error 14 UNAVAILABLE, so I guess we can just wait.

Good! I think that the fix on grpc/grpc-node#2812 and grpc/grpc-node#2811 that enable us to configure reject unauthorized will fix this issue. I setup my PC to set environment variable NODE_TLS_REJECT_UNAUTHORIZED to 0...

Then I did the same request in Insomnia and IT WORKED!

jackkav · 2024-10-04T11:50:40Z

grpc-js 1.12.0 landed! So I'll be upgrading grpc-js in #8044 and wiring up reject unauthorized in a follow up PR so expect this to be coming next week. A little later I'll try to add mTLS support too.

AdrianoAE added B-bug Bug: general classification S-unverified Status: Unverified by maintainer labels Apr 6, 2024

jackkav mentioned this issue Sep 24, 2024

Adds support for gRPC mTLS #8002

Draft

5 tasks

jackkav closed this as completed Oct 4, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GRPC not working with https #7248

GRPC not working with https #7248

AdrianoAE commented Apr 6, 2024

subnetmarco commented Apr 12, 2024

AdrianoAE commented Apr 12, 2024

AdrianoAE commented Apr 25, 2024

jackkav commented Apr 26, 2024 •

edited

Loading

AdrianoAE commented Apr 26, 2024

modestotech commented May 14, 2024

jackkav commented May 19, 2024 •

edited

Loading

rizanzaky commented Jul 8, 2024

Gradlon commented Aug 26, 2024 •

edited

Loading

subnetmarco commented Aug 30, 2024

darnley commented Sep 21, 2024

jackkav commented Sep 23, 2024

AdrianoAE commented Sep 23, 2024

jackkav commented Sep 25, 2024

darnley commented Sep 25, 2024 •

edited

Loading

darnley commented Sep 26, 2024 •

edited

Loading

darnley commented Sep 26, 2024

darnley commented Sep 26, 2024 •

edited

Loading

jackkav commented Sep 26, 2024 •

edited

Loading

darnley commented Sep 27, 2024 •

edited

Loading

jackkav commented Oct 4, 2024 •

edited

Loading

GRPC not working with https #7248

GRPC not working with https #7248

Comments

AdrianoAE commented Apr 6, 2024

Expected Behavior

Actual Behavior

Reproduction Steps

Is there an existing issue for this?

Additional Information

Insomnia Version

What operating system are you using?

Operating System Version

Installation method

Last Known Working Insomnia version

subnetmarco commented Apr 12, 2024

AdrianoAE commented Apr 12, 2024

AdrianoAE commented Apr 25, 2024

jackkav commented Apr 26, 2024 • edited Loading

AdrianoAE commented Apr 26, 2024

modestotech commented May 14, 2024

jackkav commented May 19, 2024 • edited Loading

rizanzaky commented Jul 8, 2024

Gradlon commented Aug 26, 2024 • edited Loading

subnetmarco commented Aug 30, 2024

darnley commented Sep 21, 2024

jackkav commented Sep 23, 2024

AdrianoAE commented Sep 23, 2024

jackkav commented Sep 25, 2024

darnley commented Sep 25, 2024 • edited Loading

darnley commented Sep 26, 2024 • edited Loading

darnley commented Sep 26, 2024

darnley commented Sep 26, 2024 • edited Loading

jackkav commented Sep 26, 2024 • edited Loading

darnley commented Sep 27, 2024 • edited Loading

jackkav commented Oct 4, 2024 • edited Loading

jackkav commented Apr 26, 2024 •

edited

Loading

jackkav commented May 19, 2024 •

edited

Loading

Gradlon commented Aug 26, 2024 •

edited

Loading

darnley commented Sep 25, 2024 •

edited

Loading

darnley commented Sep 26, 2024 •

edited

Loading

darnley commented Sep 26, 2024 •

edited

Loading

jackkav commented Sep 26, 2024 •

edited

Loading

darnley commented Sep 27, 2024 •

edited

Loading

jackkav commented Oct 4, 2024 •

edited

Loading