-
Notifications
You must be signed in to change notification settings - Fork 619
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TLS handshake error: failed to verify client's certificate #108
Comments
@simonsparks without trying this myself I'd say this looks like this problem. When I generate a test certificate I always have to set |
@magiconair Yes, that's a fair comment. I agree it can't be assumed that all client certs would require this conversion. |
Lets first see whether this works. I'll push a patch in a minute for testing. Are you comfortable building a fabio binary yourself or do you rely on a pre-built or docker image? |
I'm building Amazon AMIs with Packer. p.s. really appreciate your support! |
I can upload a binary to github and you could replace |
or can you ssh into your AMI instance and replace the binary? Sorry, I'm a total AWS noob. |
I can log in to the deployed servers and manually update fabio for the time being. |
BTW, I've just created https://fabiolb.slack.com/ . Might be a good use case to test this. |
That would be good. I'd be happy to test. |
AWS API Gateway certficates are self-signed but don't have the IsCA flag set to true and also don't mark the certificate as to be used for certificate signing. This prevents Go to accept the certificate for client-cert authentication. Since it isn't possible to use a custom certificate for client authentication in the AWS API Gateway we need to patch the certificate on the fly. This is a preliminary patch to verify that the approach works but has the the certificate detection hard-coded and permanent. This should be configurable and off by default.
AWS API Gateway certficates are self-signed but don't have the IsCA flag set to true and also don't mark the certificate as to be used for certificate signing. This prevents Go to accept the certificate for client-cert authentication. Since it isn't possible to use a custom certificate for client authentication in the AWS API Gateway we need to patch the certificate on the fly. This is a preliminary patch to verify that the approach works but has the the certificate detection hard-coded and permanent. This should be configurable and off by default.
AWS API Gateway certficates are self-signed but don't have the IsCA flag set to true and also don't mark the certificate as to be used for certificate signing. This prevents Go to accept the certificate for client-cert authentication. Since it isn't possible to use a custom certificate for client authentication in the AWS API Gateway we need to patch the certificate on the fly. This is a preliminary patch to verify that the approach works but has the the certificate detection hard-coded and permanent. This should be configurable and off by default.
I am a bit torn about the slack channel since it splits the discussions across multiple mediums. Now others don't see the discussion we had there. OTOH, chat provides a mechanism for others to participate. I've added a Gitter (https://gitter.im/eBay/fabio) link to the README. Someone has used that before but I forgot about it Lets see whether that picks up. So far I'm OK with responding to issues but I'm curious what others think. |
AWS API Gateway certficates are self-signed but don't have the IsCA flag set to true and also don't mark the certificate as to be used for certificate signing. This prevents Go to accept the certificate for client-cert authentication. Since it isn't possible to use a custom certificate for client authentication in the AWS API Gateway we need to patch the certificate on the fly.
@simonsparks I've pushed an updated patch which introduces a new config option |
@magiconair I can confirm that these latest changes, with the configurable option, do work for our scenario. |
AWS API Gateway certficates are self-signed but don't have the IsCA flag set to true and also don't mark the certificate as to be used for certificate signing. This prevents Go to accept the certificate for client-cert authentication. Since it isn't possible to use a custom certificate for client authentication in the AWS API Gateway we need to patch the certificate on the fly.
@simonsparks I've merged the change to master. I agree that the new config name |
That sounds reasonable @magiconair. Thanks again for your support with this issue. |
Hi,
when i try to update fabio to 1.1.5 i run into this error:
|
@raben2 this is on master but I did not create a new release yet. Please run |
Thanks that helped. |
Rebased with master and integrated the change for issue #108 which allows upgrading of client auth certificates to CA certificates. This is a workaround for the AWS API GW client auth certificates which don't have the flags set to work with Go. The configuration for 1.2 differs that the aws.apigw.cert.cn property was dropped in favor of a caupgcn parameter for the newly introduced certificate sources.
@raben2 @simonsparks BTW, I'm going to drop the parameter |
Hi, I've been trying to set up client authentication, as discussed previously in #106, and have managed to successfully authenticate a local self signed certificate via Firefox browser interaction.
However, my primary use case is to restrict access to calls from AWS API Gateway which may include it's own generated client certificates. In this case, when attempting to make a call via the gateway, Fabio logs the following error:
2016/06/07 12:56:01 http: TLS handshake error from 52.30.177.125:47122: tls: failed to verify client's certificate: x509: certificate signed by unknown authority (possibly because of "x509: invalid signature: parent certificate cannot sign this kind of certificate" while trying to verify candidate authority certificate "ApiGateway")
This looks similar to the problem described in this SO post where the client certificate had to be marked as
IsCA
.Is there a way of achieving this in Fabio through configuration, if this is in fact the same problem?
The text was updated successfully, but these errors were encountered: