You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOOS="darwin"
What did you do?
We received a report that someone is having problem connecting from GitLab Runner to GitLab server. The GitLab Runner is application written in Go. The user when tries to connect sees the x509: a root or intermediate certificate is not authorized to sign in this domain.
We asked for full certificate chain of problematic server.
We saw that the CA certificate uses X509v3 Name Constraints with Permitted DNS limitation set.
The DNS specified in certificate are of format: .domain.com (leading .).
This is excerpt from RFC 5280 describing the expected implementation of name constraints:
For URIs, the constraint applies to the host part of the name. The
constraint MUST be specified as a fully qualified domain name and MAY
specify a host or a domain. Examples would be "host.example.com" and
".example.com". When the constraint begins with a period, it MAY be
expanded with one or more labels. That is, the constraint
".example.com" is satisfied by both host.example.com and
my.host.example.com. However, the constraint ".example.com" is not
satisfied by "example.com". When the constraint does not begin with
a period, it specifies a host. If a constraint is applied to the
uniformResourceIdentifier name form and a subsequent certificate
includes a subjectAltName extension with a uniformResourceIdentifier
that does not include an authority component with a host name
specified as a fully qualified domain name (e.g., if the URI either
does not include an authority component or includes an authority
component in which the host name is specified as an IP address), then
the application MUST reject the certificate.
According to implementation checked here: https://golang.org/src/crypto/x509/verify.go#L160 the leading . is not correctly handled by Go crypto library. The constraint .domain.com should be satisfied by host.domain.com and my.host.domain.com.
We expected to see a trusted connect to server, signed by the CA with Name Constraints set. The implementation should support DNS constraints that starts with .
What did you see instead?
The error when connecting the server: x509: a root or intermediate certificate is not authorized to sign in this domain.
The text was updated successfully, but these errors were encountered:
What version of Go are you using (
go version
)?1.4.3
What operating system and processor architecture are you using (
go env
)?What did you do?
We received a report that someone is having problem connecting from GitLab Runner to GitLab server. The GitLab Runner is application written in Go. The user when tries to connect sees the
x509: a root or intermediate certificate is not authorized to sign in this domain
.We asked for full certificate chain of problematic server.
We saw that the CA certificate uses X509v3 Name Constraints with Permitted DNS limitation set.
The DNS specified in certificate are of format:
.domain.com
(leading.
).This is excerpt from RFC 5280 describing the expected implementation of name constraints:
According to implementation checked here: https://golang.org/src/crypto/x509/verify.go#L160 the leading
.
is not correctly handled by Go crypto library. The constraint.domain.com
should be satisfied byhost.domain.com
andmy.host.domain.com
.Here's the example app: https://play.golang.org/p/tIa1m313_M
What did you expect to see?
We expected to see a trusted connect to server, signed by the CA with Name Constraints set. The implementation should support DNS constraints that starts with
.
What did you see instead?
The error when connecting the server:
x509: a root or intermediate certificate is not authorized to sign in this domain
.The text was updated successfully, but these errors were encountered: