SSL certificate verification for userinfo call to the IdP with self signed cert

[dfresh613]

Hi, I have a test system I am using Vouch to perform OIDC authentication against. This system currently uses a self signed certificate. In production, it will not use self signed certificate.

Would it be beneficial to implement a flag which will allow vouch to skip verification of all certificates for self signed environments?

What is the best way to go about this? I assume we can update the httpclient with something like:

 transCfg := &http.Transport{
                 TLSClientConfig: &tls.Config{InsecureSkipVerify: true}, 
         }
    client := &http.Client{Transport: transCfg}

[bnfinet]

@dfresh613 thanks,

I do understand the use case. I have run into the same issue myself on occasion. However I do wonder if you can use http for your test environment and forego adding this feature.

If it were implemented I believe the client would need to have a properly configured context passed as shown here.. https://godoc.org/golang.org/x/oauth2#ex-Config--CustomHTTP

All of the cfg.OAuthClient.Exchange calls in handlers.go would need to be updated.

[datsabk]

@bnfinet are there plans to implement this flag? If not, can we add certificate to trust store somehow as a parameter in docker image or so?

[aaronpk]

Please do not add a flag to disable cert verification. In practice this just ends up with people enabling this flag in production environments when they really shouldn't. Being able to add a custom root cert would be a much better solution.

[bnfinet]

@datsabk can you please describe your problem in further detail? https/ssl certs are not required by Vouch Proxy

[aaronpk]

I'm assuming they mean the request Vouch Proxy makes to the OIDC token endpoint. If that endpoint is not one of the major providers but instead some custom service with a self-signed certificate the request would fail.

[bnfinet]

Oh this is the client request to the OIDC provider.

@datsabk Which provider are you struggling with?

You should be able to manipulate the certs in the Alpine docker image by extending the image in a new Dockerfile with FROM.

[datsabk]

@bnfinet This is the specific error I am talking about {"level":"error","ts":1612979528.4830308,"msg":"/auth Error while retreiving user info after successful login at the OAuth provider: Post \"https://authorize.xyz.com/oauth2/token\": x509: certificate signed by unknown authority"}

It is an internal URL using certificate signed by our organisation - Hence, we need to explicit provide the CA certificate to validate it. This error can either be provided by skipping validation or by providing a trusted CA using a configuration parameter.

[afreeman28]

I am also having a similar issue with the ": x509: certificate signed by unknown authority" message.

Although, I don't believe my issue is the same as OP, but rather an issue with the ca-certificates.crt mapping in the docker container. My URL is signed correctly but still not being trusted by Vouch. Is there something additional that needs to be mapped to the Docker container other than mounting the volume at /etc/ssl/certs ?

[bnfinet]

@datsabk what OIDC provider are you using? Would it be workable to extend the Docker image as I suggested?

[bnfinet]

@afreeman28 could you please be more specific and provide a config and log in the manner described in the README. Please do open a new issue if you feel it is distinct.

What URL? Which oauth.provider? Which CA is not trusted?

Is there something additional that needs to be mapped to the Docker container other than mounting the volume at /etc/ssl/certs

I'm not really sure. Have you tried that? I bet it would work.

[afreeman28]

@bnfinet, I am utilizing the ODIC provider with OKTA.

I have had Vouch successfully authenticating with the auto generated okta domain (i.e. dev-xxx.okta.com), however when I try to use a custom domain for OKTA (i.e sso.domain.com) with a properly sign CA, I receive 400 Bad Request x509: certificate signed by unknown authority

My custom OKTA domain is signed with Starfield Secure Certificate Authority - G2.

I have tried mounting the volume at /etc/ssl/certs into my Vouch docker container, but no luck.

vouch-config.txt

[bnfinet]

@afreeman28 is your CA file at /etc/ssl/certs/ca-certificates.crt ??

https://github.com/vouch/vouch-proxy/blob/master/Dockerfile#L22

Could you please upload your failing log to a gist along with config and other items as per the README

[afreeman28]

@bnfinet, Yes CA public CA files are at /etc/ssl/certs/ca-certificates.crt

logs: https://gist.github.com/afreeman28/18fccc8f346501448e8c603038731874

Vouch Config: https://gist.github.com/afreeman28/d52671a20e3e8191af3135502f4f4862

Vouch Docker commands: docker run -d -p 9090:9090 --name vouch-proxy -v /etc/vouch/config:/config voucher/vouch-proxy

[bnfinet]

@afreeman28 need the logs with debug and testing please as per the README

[bnfinet]

this is how Go looks for the certs... https://golang.org/src/crypto/x509/root_linux.go

[bnfinet]

@afreeman28 have you tested/verified ca-certificates.crt using openssl or in some other manner? Is the signing chain sound?

[onlookor]

@bnfinet This is the specific error I am talking about {"level":"error","ts":1612979528.4830308,"msg":"/auth Error while retreiving user info after successful login at the OAuth provider: Post "https://authorize.xyz.com/oauth2/token\": x509: certificate signed by unknown authority"}

It is an internal URL using certificate signed by our organisation - Hence, we need to explicit provide the CA certificate to validate it. This error can either be provided by skipping validation or by providing a trusted CA using a configuration parameter.

I have the same requirement, and the log reports the same quoted above.

[onlookor]

Oh this is the client request to the OIDC provider.

@datsabk Which provider are you struggling with?

You should be able to manipulate the certs in the Alpine docker image by extending the image in a new Dockerfile with FROM.

I copied out the ca-certificates.crt from container, appended my ca.crt, then copied back to container. It works for me. Could you ease the restriction of CA, provide some convenient way for this case?

[bnfinet]

@onlookor I'm glad you got it working. Could you please document your full fix including paths? I'm sure others would appreciate it.

I think @aaronpk has it right, we don't want to have a knob that allows VP to be less secure. That error is a good error. If you're using a self signed CA then you'll need to manipulate the container manually as you have. IMHO VP/golang http request is doing the right thing by relying on the operating environment to be sound. It feels easier to me to just build a new bespoke container for your org.

Feel free to let me know if you feel I'm missing something, but this feels like a docu-bug.

Once the "fix" is documented well I'll close this issue and link to it from the README.

[onlookor]

@onlookor I'm glad you got it working. Could you please document your full fix including paths? I'm sure others would appreciate it.

I think @aaronpk has it right, we don't want to have a knob that allows VP to be less secure. That error is a good error. If you're using a self signed CA then you'll need to manipulate the container manually as you have. IMHO VP/golang http request is doing the right thing by relying on the operating environment to be sound. It feels easier to me to just build a new bespoke container for your org.

Feel free to let me know if you feel I'm missing something, but this feels like a docu-bug.

Once the "fix" is documented well I'll close this issue and link to it from the README.

The full fix:

1. In CLI, run docker cp vouch:/etc/ssl/certs/ca-certificates.crt . - replace the vouch with your container name.
2. Open local ca-certificates.crt in text editor, append the content of your self-signed CA.
3. In CLI, run docker cp ca-certificates.crt vouch:/etc/ssl/certs/ca-certificates.crt - replace the vouch with your container name.

However, it's common to use self-signed CA in orgs' intranet, leave a door open is necessary.

[lerminou]

In a kubernetes environment, the full fix doesn't look good. It may be better to have a initContainer to perform this merge.

I'm starting using Vouch proxy in our cluster and I have the same error as above

I will create a PR for the helm chart version.