"certificate signed by unknown authority" when verifying with Go library

Hello, I’m using the Go JWT verifier to verify an access token. I’m almost certain this is an enterprise cert issue in our server environment, but I’m having a hard time trying to figure out why it’s happening and how to fix it.

When verifying an access token, I’m getting this error:

request for metadata was not successful: Get https://dev-xxxxxx.okta.com/oauth2/xxxxxxxxxxxxx/.well-known/openid-configuration: x509: certificate signed by unknown authority

  1. I can curl to that url (https://dev-xxxxx.okta.com/oauth2…) just fine. No errors and I don’t need curl -k.

  2. I can curl to other https sites just fine from the environment. If I curl to other https sites with known SSL issues like a self-signed cert, it will error unless I pass -k.

  3. openssl s_client -showcerts -connect dev-xxxxxx.okta.com:443 shows just the Okta cert and its CA, There doesn’t appear to be any other certs along the way.

Looking at the library’s source code, I don’t see anything fancy:

func (j *JwtVerifier) getMetaData() (map[string]interface{}, error) {
    	metaDataUrl := j.Issuer + j.Discovery.GetWellKnownUrl()
    	resp, err := http.Get(metaDataUrl)

    	if err != nil {
    		return nil, fmt.Errorf("request for metadata was not successful: %s", err.Error())
}

Any idea on how to fix the unknown authority issue short of disabling SSL verification on the library?

That is really weird. I can’t think of anything else either. Does your server machine have a special SSL setup, like a custom root CA or something? Or does it require a proxy to get out to the internet?

Can you use the Go JWT Verifier on a different machine/network against the same URL successfully?

I can use the Verifier on my dev laptop just fine. There could be different network rules for the server I’m having problems with, but it should be the same as the dev laptop environment. We haven’t had problems with it before. I’ll verify it today.

The code is executing in a Kubernetes pod. All the curl tests I’m running are also in the pod. Theoretically shouldn’t curl encounter the same problems as Go’s http.Get() call?

Ok, problem solved. The problem is due to this being run inside a Kubernetes pod. Our base image is Alpine, which doesn’t include the root certs, apparently.

When I installed curl in the pod to test, it installed the ca-certificates package. This made curl work, but the Go code is an http server that doesn’t die. It won’t load the new certs unless the process is restarted, which would cause a pod restart.

Once I added apt-get install ca-certificates in the Dockerfile, the call worked. Thanks for looking at it, @nate.barbettini!

@snapetom That makes sense! Glad you figured it out.

I’ve been in that exact situation before (didn’t realize I needed to install ca-certificates in a Docker container). I didn’t think of it here, d’oh!