Generic ("*") wildcard certificates aren't accepted #663
Comments
|
Change { checkServerIdentity() {} },to { checkServerIdentity() { return true } },You're injecting your own callback for checking the server's ssl certificate, without any body in the function, which is quite nonsensical. In JavaScript, such nop function is going to be evaluated as |
|
change it to I am using an empty function as documented, this function is supposed to return Error only, or otherwise
@nicolasnoble could you confirm the documentation is correct? I have complained the doc site in another issue, and then people are telling me the doc site is somewhat deprecated, and it's not updated since August |
|
Right... I stand corrected. That's right, this API was always a bit odd to me, and I wish to amend it at some point so it makes a bit more sense. I don't know why it would refuse to verify then. That'd work properly. |
|
If you provide us with a fully reproducible repository that demonstrates the issue, we could better help you there. |
|
I am feeling this could be related to https://github.com/c0b/grpc-helloworld/tree/the-problem/cfssl-certs because I just tried similar openssl generted certs which indeed work with grpc-node client, $ go run -- ./greeter_server/ -ca-path ./cfssl-certs/ca.pem -server-cert ./cfssl-certs/server.pem -server-key ./cfssl-certs/server-key.pem
listening &{{0xc00000e080 <nil> <nil> <nil> <nil> <nil> <nil> <nil> 0 4194304 2147483647 <nil> {0 0 0 0 0} {0 false} 0 0 32768 32768 120000000000 <nil>} {0 0} map[] map[] false false 0xc00003c400 map[helloworld.Greeter:0xc00016a540 grpc.reflection.v1alpha.ServerReflection:0xc00016a5d0] <nil> 0xc0000302a0 0xc000030300 {{0 0} 0} {{0 0} 0} {{0 0} 0} {{} [0 0 0]} 0 0xc00002b0c0}
...The Go client has no problem to use this cfssl certs: $ go run -- ./greeter_client/ -ca-path ./cfssl-certs/ca.pem -client-cert ./cfssl-certs/client.pem -client-key ./cfssl-certs/client-key.pem
2018/11/29 15:59:31 Greeting: Hello world
2018/11/29 15:59:31 Greeting: Hello again worldbut grpc-node client is not working: $ node --trace-warnings ./greeter_client.js
{ helloworld:
{ Greeter:
{ [Function: ServiceClient]
super_: [Function: Client],
service:
{ SayHello:
{ path: '/helloworld.Greeter/SayHello',
requestStream: false,
responseStream: false,
requestSerialize: [Function: serialize],
requestDeserialize: [Function: deserialize],
responseSerialize: [Function: serialize],
responseDeserialize: [Function: deserialize],
originalName: 'sayHello' },
SayHelloAgain:
{ path: '/helloworld.Greeter/SayHelloAgain',
requestStream: false,
responseStream: false,
requestSerialize: [Function: serialize],
requestDeserialize: [Function: deserialize],
responseSerialize: [Function: serialize],
responseDeserialize: [Function: deserialize],
originalName: 'sayHelloAgain' } } } } }
ServiceClient {
'$interceptors': [],
'$interceptor_providers': [],
'$callInvocationTransformer': undefined,
'$channel': Channel {} }
E1129 08:32:50.889773363 12165 ssl_transport_security.cc:1526] Invalid wildchar entry.
E1129 08:32:51.911793960 12165 ssl_transport_security.cc:1526] Invalid wildchar entry. |
|
the js client code is in https://github.com/c0b/grpc-helloworld/blob/the-problem/greeter_client.js const api = grpc.loadPackageDefinition(packageDefinition);
const client = new api.helloworld.Greeter(
'localhost:50051',
// grpc.credentials.createInsecure(),
grpc.credentials.createSsl(
// fs.readFileSync('./openssl-certs/ca.crt'),
fs.readFileSync('./cfssl-certs/ca.pem'),
// ca, key, cert,
fs.readFileSync('./cfssl-certs/client-key.pem'),
// fs.readFileSync('./openssl-certs/client.key'),
fs.readFileSync('./cfssl-certs/client.pem'),
// fs.readFileSync('./openssl-certs/client.crt'),
// { checkServerIdentity() {} },
),
// { 'grpc.ssl_target_name_override' : 'example', 'grpc.default_authority': 'localhost', },
);
client.SayHello({ name: 'abc' }, (err, resp) => {
console.log(new Date, 'ERROR:', err, resp);
});
client.SayHelloAgain({ name: 'abc2' }, (err, resp) => {
console.log(new Date, 'ERROR:', err, resp);
});as comments indicated, I have tried all kinds of constructor options with |
|
Ooooh, this is an interesting smoking gun: @jboeuf, @jiangtaoli2016, this may be a corner case with the C/C++ core's SSL certificate parser. I'm going to try to fully reproduce your issue still, but that may be a problem with all the implementations based off the native core, not just nodejs. Meanwhile it could be useful to see if it also reproduces when using the C++ API. |
|
Yes, I'm fairly certain there's a bug somewhere in the core: The C/C++ core thinks that the peer certificate doesn't match the subject name "example", whereas both a static inspection of the certificate, and an actual connection with openssl's s_client are showing that the certificate is valid and proper. This isn't a bug on grpc-node, and I now strongly believe this is a bug on all the grpc implementations that are based off the C/C++ implementation. Beautiful. |
nicolasnoble
changed the title
|
Also, one minor edit: what you're having isn't a self-signed certificate. You DO have a root CA, which is used to sign your server certificate. A self-signed certificate is a certificate which acts as its own CA. That's not the case here - the CA is separate, therefore no "self-signed" override is needed, as long as you're properly providing the CA on both ends, which you do. |
|
Including full dump of openssl's s_client output. There IS a warning from OpenSSL that the certificate is bad, but that's a red herring. Looking at OpenSSL's errors, it simply means we aren't providing the client certificate. |
|
@c0b alternatively, it might be possible to try with @grpc/grpc-js, the pure javascript client. If this is indeed a bug in the native code as I'm suspecting it is, then this implementation wouldn't have that problem, hopefully. Depending on what you want to do ultimately, the pure javascript client may or may not fit your requirements, but it may be worth evaluating it while the core bug is investigated and fixed. |
nicolasnoble
changed the title
|
I just reproduced and traced the code. The SAN in the cfssl generated certificate is '*' and being rejected by gRPC SSL. SAN '*' (wildcard without domain) shall be rejected is because it is too general Let me see whether I can find RFC that allows or disallows wildcard without domain. We can revise gRPC code if needed. |
|
By the way, the reason the certificate generated by openssl works is because CN in cert is |
|
certificate generated by openssl certificate generated by cfssl from https://github.com/c0b/grpc-helloworld/tree/the-problem/cfssl-certs |
|
It seems that grpc-go accepts wildcard without domain SAN. I need to verify by the source code. If so, we probably want to have consistent behavior across grpc languages. |
|
After consulting with our internal TLS expert, the wildcard without any domain '*' in SAN is not acceptable.
|
nicolasnoble
changed the title
|
@jiangtaoli2016 now, that being said, the normal Subject should be working in this case, right? With Are we simply rejecting the whole certificate because it contains a wildcard that's too generic? Or should we rather ignore the overly-wide SAN but still validate the Subject? |
|
gRPC core is not rejecting TLS certificate with wildcard without domain. The ssl_transport_security just log error and treats this as mismatch. If CN matches peer hostname, it shall still work. |
|
Okay, so the wildcard warning is a red herring. But we're still rejecting this peer, even though the CN matches. Hmm... |
|
For what it's worth, I had a similar problem and solved it by leaving the SSL credentials blank e.g. |
No, I tried an empty |
|
We are also facing a similar issue, we are able to connect to the server via CURL (REST API Call) using the cert (having CN=*.sample.com) and OpenSSL version library 1.0.2. But, when we use the same cert and same OpenSSL version library 1.0.2 with GRPC C++ client the connection is failing with below error: We are getting GRPC error code 14, please guide on this issue? |
|
Hi! I have similar issue. I have wildcard san ssl certificate for OKD and his apps. So, when i use: UPD: Error was in NGINX |
|
So, what is the proper way to generate a certificate for an edge server, whose domain is not known (controlled by the customer during future deployment) when the certificate is generated? |
|
Is there a resolution to this issue ? |
|
This still seems to be a problem, as I'm encountering the same problem. There's no way to validate a certificate and skip only hostname validation. The |
|
Workaround: Instead of setting You can download it with |
The [Node.js gRPC client has a bug](grpc/grpc-node#663) that requires downloading the TLS certificate before initiating the gRPC connection [as a workaround](grpc/grpc-node#663 (comment)). When that's done, `transportAttrs` is `null` (a behaviour that's undocumented), so it led to unhandled exceptions.
The [Node.js gRPC client has a bug](grpc/grpc-node#663) that requires downloading the TLS certificate before initiating the gRPC connection [as a workaround](grpc/grpc-node#663 (comment)). When that's done, `transportAttrs` is `null` (a behaviour that's undocumented), so it led to unhandled exceptions.
As a workaround for grpc/grpc-node#663 Fixes #22.
* wip * fix: Download TLS certificate upfront when connecting to a courier As a workaround for grpc/grpc-node#663 Fixes #22. * Fix formatting issue * refactor
|
Here's an MIT-licensed implementation of the workaround I described above, in case it helps anyone: https://github.com/relaycorp/relaynet-cogrpc-js/blob/6c04ac9777ffafbbcc428b3d855e1b81db3dd866/src/lib/client.ts#L143-L176 |
does not work on my end |
|
still no solution yet? im facing same issue when using nginx as reverse grpc, even with certificate and key set on server and client. when connecting directly to my server instance with certificate, it works |
this is a duplication of #157 ( it wasn't resolved but author gave up, I don't understand why need to lock it )
it is duplicated here, grpc Server was written in Golang deployed with self signed certificates, our existing Go based grpc Client has been working with this Go based grpc Server perfectly (for a long time already);
Now I am trying to write another gRPC client in NodeJS, just enjoy JS fast prototyping, testing feasibility of grpc-node
but it didn't run till my console.log line, has failed with this log:
I have tried
NODE_TLS_REJECT_UNAUTHORIZED=0orgrpc.credentials.createInsecure()or some other env variables, seems not use; all failedfrom #160 (comment) I got
from @jboeuf is this accurate? is there any workaround like
NODE_TLS_REJECT_UNAUTHORIZED=0to self-certs https site? To not enforce cert validation? Or would you guys say grpc-node library is not the same stable/mature as grpc Go is more nativeThe text was updated successfully, but these errors were encountered: