The problem you’re experiencing is caused by the self-signed certificate 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) 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:
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 found in the integration repository which you can use for replacing the old one:
# 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).
