# \[Demo installation\] Certificate: "certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0" error
**URL:** https://hub.mender.io/t/demo-installation-certificate-certificate-relies-on-legacy-common-name-field-use-sans-or-temporarily-enable-common-name-matching-with-godebug-x509ignorecn-0-error/4019
**Category:** General Discussions
**Created:** [August 19, 2021, 12:28pm UTC](https://hub.mender.io/t/demo-installation-certificate-certificate-relies-on-legacy-common-name-field-use-sans-or-temporarily-enable-common-name-matching-with-godebug-x509ignorecn-0-error/4019 "2021-08-19T12:28:30Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@hwbslr](https://hub.mender.io/u/hwbslr)
#### Post date: [August 19, 2021, 12:28pm UTC](https://hub.mender.io/t/demo-installation-certificate-certificate-relies-on-legacy-common-name-field-use-sans-or-temporarily-enable-common-name-matching-with-godebug-x509ignorecn-0-error/4019/1 "2021-08-19T12:28:30Z")
Hi,
I was testing the mender docker demo and came along the error
> certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0
when our device tries to update the inventory data.
I hope I followed the installation guide correctly: [https://docs.mender.io/development/server-installation/demo-installation](https://docs.mender.io/development/server-installation/demo-installation)
I added
```auto
127.0.0.1 s3.docker.mender.io
127.0.0.1 docker.mender.io
```
to /etc/hosts on the host that is hosting the docker container and I added
```auto
192.168.55.100 s3.docker.mender.io
192.168.55.100 docker.mender.io
```
on the target, otherwise the mender client can not resolve those host names.
When I ping [docker.mender.io](http://docker.mender.io) on the host and on the target the name [docker.mender.io](http://docker.mender.io) is resolved correctly.
But I get the error mentioned above. AFAIK the common name is fully qualified host name - [docker.mender.io](http://docker.mender.io).
Can anyone give me a hint where my mistake is?
Thanks!
---
### Author:  [@alfrunes](https://hub.mender.io/u/alfrunes)
#### Post date: [August 20, 2021, 9:33am UTC](https://hub.mender.io/t/demo-installation-certificate-certificate-relies-on-legacy-common-name-field-use-sans-or-temporarily-enable-common-name-matching-with-godebug-x509ignorecn-0-error/4019/2 "2021-08-20T09:33:57Z")
Hi @hwbslr,
The problem you’re experiencing is caused by [the self-signed certificate](https://github.com/mendersoftware/integration/blob/3.0.0/certs/api-gateway/cert.crt) used in the Docker composition. Starting with go1.15, the default behavior is to reject certificate relying on the common name (CN) field for hostname validation when initializing a tls connection. We have a ticket ([MEN-4986](https://tracker.mender.io/browse/MEN-4986)) in progress for replacing the certificate for the demo setup, but in the meantime I propose two temporary solutions for getting your demo setup fully functional:
1. Compile the Mender client using [go1.14](https://golang.org/dl/go1.14.15.linux-amd64.tar.gz).
2. Replace the certificates in the demo setup with a certificate providing correct Subject Alternative Names (SAN) for hostname validation. I created a slightly modified version of the [keygen script](https://github.com/mendersoftware/integration/blob/3.0.0/keygen) found in the integration repository which you can use for replacing the old one:
```auto
# MAKE SURE YOU'RE RUNNING THIS IN THE ROOT OF THE INTEGRATION GIT REPOSITORY
# cd ~/src/integration
wget https://gist.githubusercontent.com/alfrunes/34cf645ad45a84d07e90afe0eaca99e3/raw/0cd5ae1c3d730aeaad94f86b5c93ded1c1999e9b/keygen -O keygen.new
# Generate new keys using the demo hostname
CERT_API_CN="docker.mender.io" bash keygen.new
# Replace the existing certificates
mv ./certs ./certs.bak && cp -r ./keys-generated/certs ./certs
# Restart the server
./demo stop
./demo up
```
Finally you’ll need to add the newly generated certificate (`certs/server.crt` in the integration repo) to the device’s CA trust store. If your device is using debian you can install the `ca-certificates` package and use the `update-ca-certificates(8)` command.
NOTE: You can choose whether you want to do 1 or 2 (you don’t have to do both).
Sorry for the inconvenience.
---
### Author:  [@hwbslr](https://hub.mender.io/u/hwbslr)
#### Post date: [August 25, 2021, 12:26pm UTC](https://hub.mender.io/t/demo-installation-certificate-certificate-relies-on-legacy-common-name-field-use-sans-or-temporarily-enable-common-name-matching-with-godebug-x509ignorecn-0-error/4019/3 "2021-08-25T12:26:51Z")
Hi @alfrunes
thanks for your reply - I had no time yet to try one of your solutions…
It is just shifted. 😉
---
### Author:  [@hwbslr](https://hub.mender.io/u/hwbslr)
#### Post date: [September 7, 2021, 7:08am UTC](https://hub.mender.io/t/demo-installation-certificate-certificate-relies-on-legacy-common-name-field-use-sans-or-temporarily-enable-common-name-matching-with-godebug-x509ignorecn-0-error/4019/4 "2021-09-07T07:08:13Z")
Hi @alfrunes
> [@alfrunes](#):
>
> 1. Replace the certificates in the demo setup with a certificate providing correct Subject Alternative Names (SAN) for hostname validation. I created a slightly modified version of the [keygen script](https://github.com/mendersoftware/integration/blob/3.0.0/keygen) found in the integration repository which you can use for replacing the old one:
I chose the second option and it worked right away.
Thank you for your help!