Score:1

Getting Errors trying to attach ua token

cn flag

I am trying to enable ESM on my 16.04 VPS server, but I am getting errors trying to connect to the canonical server. The error I am getting after running the ssh command # sudo ua attach C122..... is:

Failed to connect to authentication server
Check your Internet connection and try again.
Failed to access URL: https://contracts.canonical.com/v1/resources?kernel=4.4.0-1160.21.1.vz7.174.13&series=xenial&architecture=amd64
Cannot verify certificate of server
Please check your openssl configuration.

I read somewhere it could be iptables blocking it, but I have OUTGOING on ACCEPT ALL. And when I ping https://canonical.com I get a healthy response.

Anybody have any idea?


Thank you for your help, @andrew-lowther. I did as you suggested. I could not post this lengthy result in a comment to your answer.

The ca-certicates were already at the latest version. The curl test seems fine also:

* Connected to contracts.canonical.com (91.189.92.69) port 443 (#0)
* found 129 certificates in /etc/ssl/certs/ca-certificates.crt
* found 520 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
*        server certificate verification OK
*        server certificate status verification SKIPPED
*        common name: contracts.canonical.com (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: CN=contracts.canonical.com
*        start date: Fri, 16 Jul 2021 18:50:43 GMT
*        expire date: Thu, 14 Oct 2021 18:50:41 GMT
*        issuer: C=US,O=Let's Encrypt,CN=R3
*        compression: NULL
* ALPN, server accepted to use http/1.1
> GET / HTTP/1.1
> Host: contracts.canonical.com
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Server: openresty/1.15.8.2
< Date: Sat, 24 Jul 2021 10:10:20 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 19
< Connection: keep-alive
< Strict-Transport-Security: max-age=15724800; includeSubDomains
< X-Content-Type-Options: nosniff
< X-Trace-Id: 05087364-13c5-426f-9a59-99c7384f2dde
<
404 page not found
* Connection #0 to host contracts.canonical.com left intact`

Does this give you any other clues?

Thanks again.

guiverc avatar
cn flag
[Ubuntu 16.04 LTS has reached the end of it's *standard* support life](https://fridge.ubuntu.com/2021/03/13/extended-security-maintenance-for-ubuntu-16-04-xenial-xerus-begins-april-30-2021/) thus is now off-topic here unless your question is specific to helping you move to a supported release of Ubuntu. Ubuntu 16.04 ESM support is available, but not on-topic here, see https://askubuntu.com/help/on-topic See also https://ubuntu.com/blog/ubuntu-16-04-lts-transitions-to-extended-security-maintenance-esm
Score:1
jp flag

The error message indicates the connection is allowed but your VPS server does not trust the Canonical server's certificate.

A good first step is to make sure the root certificates are up to date on your VPS server.

apt-get update
apt-get install ca-certificates

Using curl is a simple way to test. If this command fails with output that includes SSL certificate problem then that would confirm the certificate issue.

curl -vs https://contracts.canonical.com

You can also use the -k option with curl to ignore certificate errors and learn more about what certificate the VPS server is receiving.

curl -vsk https://contracts.canonical.com -o /dev/null

EDIT

Your curl output does suggest that the Canonical server's certificate is trusted. Your VPS server can reach the Canonical server and nothing appears to be interfering with the traffic.

These are a couple of other commands you can try, although they usually are not necessary to run manually.

update-ca-certificates
c_rehash /etc/ssl/certs

When I strace a ua command it appears to be specifically looking for the file /usr/lib/ssl/certs/4042bcee.0. You can also verify this exists and is a symlink to the root certificate. This symlink gets created by the c_rehash command.

# ls -l /usr/lib/ssl/certs/4042bcee.0
lrwxrwxrwx 1 root root 16 Feb 19 14:09 /usr/lib/ssl/certs/4042bcee.0 -> ISRG_Root_X1.pem

EDIT 2

From your comment it sounds like the /usr/lib/ssl/ directory may be messed up. It should contain several symlinks

$ ls -l /usr/lib/ssl/
total 4
lrwxrwxrwx 1 root root   14 Apr 15  2016 certs -> /etc/ssl/certs
drwxr-xr-x 2 root root 4096 Feb 19 14:10 misc
lrwxrwxrwx 1 root root   20 Feb 17 10:21 openssl.cnf -> /etc/ssl/openssl.cnf
lrwxrwxrwx 1 root root   16 Apr 15  2016 private -> /etc/ssl/private
cn flag
Thanks, @andrew-lowther. I executed the two commands, no change. I checked for the file /usr/lib/ssl/certs/4042bcee.0, but it does not exist.
cn flag
@andrew-lowther, the file does exist at /etc/ssl/certs/4042bcee.0. I copied it to /usr/lib/ssl/certs/.., and executed the ua command and now it worked :) Don't know if that is the right procedure though. But thanks :)
Andrew Lowther avatar
jp flag
@Tezalsec glad it is working. I made one more edit to show what symlinks should exist in `/usr/lib/ssl` so that it the file only really needs to exist in `/etc/ssl/certs`
Score:0
us flag

If someone comes here with a failed certificate check when trying curl -vs https://contracts.canonical.com start with the instructions here

The commands shown there are:

cd /usr/share/ca-certificates
sudo mkdir letsencrypt.org
cd letsencrypt.org/
wget "https://letsencrypt.org/certs/isrgrootx1.pem"
sudo update-ca-certificates

That still didn't work for me. Seeing here that the certs folder holds the symlinks to the certificate files. I copied the file into etc/ssl/certs and create a symlink to it. (The copying was probably unnecessary). Then I ran the update certificate command @Andrew had mentioned c_rehash /etc/ssl/certs which did the trick.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.