Mender Client not authorising when using GO 1.15

General Discussions
1

Hi,

I’m seeing the following error in the Mender Client

Dec 07 18:52:00 dlink-g300-mt7688an mender[362]: time="2020-12-07T18:52:00Z" level=error msg="Failure occurred while executing authorization request: &url.Error{Op:\"Post\", URL:\"[https://rufilla.octopus.mender.com/api/devices/v1/authentication/auth_requests\"](https://rufilla.octopus.mender.com/api/devices/v1/authentication/auth_requests\%22), Err:x509.HostnameError{Certificate:(*x509.Certificate)(0x2862dc0), Host:\"rufilla.octopus.mender.com\"}}"
Dec 07 18:52:00 dlink-g300-mt7688an mender[362]: time="2020-12-07T18:52:00Z" level=error msg="Failure occurred while executing authorization request: &url.Error{Op:\"Post\", URL:\"[https://rufilla.octopus.mender.com/api/devices/v1/authentication/auth_requests\"](https://rufilla.octopus.mender.com/api/devices/v1/authentication/auth_requests\%22), Err:x509.HostnameError{Certificate:(*x509.Certificate)(0x2862dc0), Host:\"rufilla.octopus.mender.com\"}}"
Dec 07 18:52:00 dlink-g300-mt7688an mender[362]: time="2020-12-07T18:52:00Z" level=error msg="Authorization request error: x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0"
Dec 07 18:52:00 dlink-g300-mt7688an mender[362]: time="2020-12-07T18:52:00Z" level=error msg="Authorize failed: transient error: authorization request failed: generic error occurred while executing authorization request: Post \"[https://rufilla.octopus.mender.com/api/devices/v1/authentication/auth_requests\":](https://rufilla.octopus.mender.com/api/devices/v1/authentication/auth_requests\%22:) x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0"
Dec 07 18:52:00 dlink-g300-mt7688an mender[362]: time="2020-12-07T18:52:00Z" level=info msg="State transition: authorize [Sync] -> authorize-wait [Idle]"
Dec 07 18:52:00 dlink-g300-mt7688an mender[362]: time="2020-12-07T18:52:00Z" level=error msg="Authorization request error: x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0"
Dec 07 18:52:00 dlink-g300-mt7688an mender[362]: time="2020-12-07T18:52:00Z" level=error msg="Authorize failed: transient error: authorization request failed: generic error occurred while executing authorization request: Post \"[https://rufilla.octopus.mender.com/api/devices/v1/authentication/auth_requests\":](https://rufilla.octopus.mender.com/api/devices/v1/authentication/auth_requests\%22:) x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0"

I’m using Yocto version gatesgarth and the go version is

2.3.1-r0$ ./recipe-sysroot-native/usr/bin/go version
go version go1.15.2 linux/amd64

And looking on the internet I see that support for CN is dropped in this version of GO.

https://github.com/golang/go/issues/39568

Are there plans to update the keygen script to use SAN instead of the CN?

Best Regards,
Martin.

2

It does look like we should update the keygen script, and I assume this is only a problem when using self-signed certificates.

Tagging some people who might have additional comments. @eystein @kacf

3

Pretty much what Mirza said. This will probably come up naturally when we move to the next LTS Yocto branch (I’m not quite clear on whether this is 0.5 or 1.5 years from now), but it would be good to have this fixed before then anyway. Less stuff that can bite us later. Feel free to create a ticket for it.

4

I tried the instructions on letsencrypt

using this configuration file

[dn]
CN=rufilla.octopus.mender.com

[req]
distinguished_name = dn

[EXT]
subjectAltName=DNS:rufilla.octopus.mender.com
keyUsage=digitalSignature
extendedKeyUsage=serverAuth

and updating keygen to use it

cd api-gateway
openssl req -x509 -sha256 -nodes -days $CERT_VALID_DAYS -newkey ec:<(openssl ecparam -name prime256v1) -ke
yout $FILE_NAME_PRIVATE_KEY -out $FILE_NAME_CERT -subj /CN="$CERT_API_CN" -extensions EXT -config /ws/rufi
lla/octopus/mender-server/ssl.conf
cd ..

cd storage-proxy
openssl req -x509 -sha256 -nodes -days $CERT_VALID_DAYS -newkey ec:<(openssl ecparam -name prime256v1) -ke
yout $FILE_NAME_PRIVATE_KEY -out $FILE_NAME_CERT -subj /CN="$CERT_STORAGE_CN" -extensions EXT -config /ws/
rufilla/octopus/mender-server/ssl.conf
cd ..

And it now works :slight_smile:

Probably best to create a temporary file with mktemp to create the configuration file but it will do for now.

5

@martin thanks for the report

If you have the chance it would be awesome if you could create a PR against this script with your improvements: https://github.com/mendersoftware/integration/blob/master/keygen

Is a separate file required now to specify what used to be the CN? I suppose we could move it to a subdirectory in that case (and update path in docs), but ideally avoiding manually editing files (rather take parameters to the keygen script).

6

Will do, I’ve updated the keygen script to create temporary config files which it populates and then removes once finished, would this be ok?

7

Thank you, perfect!

That sounds great to me, perhaps also do it with mktmp to avoid conflicts. :+1:

8

@eystein: How do I raise a PR? I can’t seem to find anything on Github even when logging into my account.

9

@martin we’re using the normal Github fork and PR workflow.

Are you not able to create a fork when logged in here? https://github.com/mendersoftware/integration

Then create a local branch, push to your fork and visit it on github create a PR from there?