go: crypto/x509: Verify on macOS does not return typed errors

What version of Go are you using (`go version`)?

$ go version
go version go1.19.3 darwin/arm64

(But the issue apparently started in 1.18)

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (`go env`)?

Darwin arm64

go env Output

$ go env
GO111MODULE=“”
GOARCH=“arm64”
GOBIN=“”
GOCACHE=“/Users/wneessen/Library/Caches/go-build”
GOENV=“/Users/wneessen/Library/Application Support/go/env”
GOEXE=“”
GOEXPERIMENT=“”
GOFLAGS=“”
GOHOSTARCH=“arm64”
GOHOSTOS=“darwin”
GOINSECURE=“”
GOMODCACHE=“/Users/wneessen/go/pkg/mod”
GONOPROXY=“”
GONOSUMDB=“”
GOOS=“darwin”
GOPATH=“/Users/wneessen/go”
GOPRIVATE=“”
GOPROXY=“https://proxy.golang.org,direct”
GOROOT=“/opt/homebrew/Cellar/go/1.19.3/libexec”
GOSUMDB=“sum.golang.org”
GOTMPDIR=“”
GOTOOLDIR=“/opt/homebrew/Cellar/go/1.19.3/libexec/pkg/tool/darwin_arm64”
GOVCS=“”
GOVERSION=“go1.19.3”
GCCGO=“gccgo”
AR=“ar”
CC=“clang”
CXX=“clang++”
CGO_ENABLED=“1”
GOMOD=“/Users/wneessen/go/src/dev-to-example/go.mod”
GOWORK=“”
CGO_CFLAGS=“-g -O2”
CGO_CPPFLAGS=“”
CGO_CXXFLAGS=“-g -O2”
CGO_FFLAGS=“-g -O2”
CGO_LDFLAGS=“-g -O2”
PKG_CONFIG=“pkg-config”
GOGCCFLAGS=“-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/lw/f2psdp2s5fg4z_jw0q58rdgm0000gn/T/go-build119423787=/tmp/go-build -gno-record-gcc-switches -fno-common”

What did you do?

package main

import (
	"crypto/x509"
	"errors"
	"fmt"
	"net/http"
	"net/url"
	"reflect"
)

func main() {
	_, err := http.Get("https://expired.badssl.com/")
	if err != nil {
		switch {
		case errors.As(err, &x509.CertificateInvalidError{Reason: x509.Expired}):
			fmt.Printf("Certificate is expired...\n")
		default:
			if ue, ok := err.(*url.Error); ok {
				fmt.Printf("Unwrapped error is type: %s\n", reflect.TypeOf(ue.Err))
			}
		}
	}
}

What did you expect to see?

I expect to see the “Certificate is expired…” output

What did you see instead?

I received this: Unwrapped error is type: *errors.errorString

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 17 (12 by maintainers)

Commits related to this issue

[release-branch.go1.18] crypto/x509: return typed verification errors on macOS On macOS return the error code from SecTrustEvaluateWithError, and use it to create typed errors that can be returned fr... — committed to golang/go by rolandshoemaker 2 years ago
[release-branch.go1.19] crypto/x509: return typed verification errors on macOS On macOS return the error code from SecTrustEvaluateWithError, and use it to create typed errors that can be returned fr... — committed to golang/go by rolandshoemaker 2 years ago
Assert on typed x509 error first before macOS-specific fallback Only falls back to macOS-specific x509 error assertion if the initial typed assertion failed. Fixes test failure when running with Go ... — committed to couchbase/sync_gateway by bbrks a year ago
Assert on typed x509 error first before macOS-specific fallback (#6011) Only falls back to macOS-specific x509 error assertion if the initial typed assertion failed. Fixes test failure when runni... — committed to couchbase/sync_gateway by bbrks a year ago
Assert on typed x509 error first before macOS-specific fallback (#6011) Only falls back to macOS-specific x509 error assertion if the initial typed assertion failed. Fixes test failure when running ... — committed to couchbase/sync_gateway by bbrks a year ago
CBG-2608: [3.0.5] Update websocket implementation (#6060) * CBG-2608: update websocket implementation * CBG-1901: Update ISGR/Blip to nhooyr.io/websocket (#5421) * Update ISGR/Blip to nhooyr.io... — committed to couchbase/sync_gateway by gregns1 a year ago

Most upvoted comments

@golang/release requesting a freeze exception for this. It’s a relatively minor change which simply changes error return types and as such is not very high risk, but should fix a regression that was present in 1.19 that makes macOS behave differently from all other platforms.

rolandshoemaker on Nov 22, 2022

Oh hah, we actually already do this on Windows 🤦.

rolandshoemaker on Nov 21, 2022

This will also be an issue on Windows.

Probably reasonable that we should try to convert to a Go style CertificateInvalidError if we can. I know macOS does provide relatively good insight into trust failures (i.e. https://developer.apple.com/documentation/security/certificate_key_and_trust_services/trust/discovering_why_a_trust_evaluation_failed), not entirely sure about Windows (I assume there is probably something, but 🤷).