Getting Errors trying to attach ua token

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.


Solution 1:

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