Primirea erorilor la încercarea de a atașa un token ua

Încerc să activez ESM pe serverul meu 16.04 VPS, dar primesc erori când încerc să mă conectez la serverul canonic. Eroarea pe care o primesc după rularea comenzii ssh # sudo ua attach C122..... este:

Nu s-a putut conecta la serverul de autentificare
Verificați conexiunea la internet și încercați din nou.
Nu s-a putut accesa adresa URL: https://contracts.canonical.com/v1/resources?kernel=4.4.0-1160.21.1.vz7.174.13&series=xenial&architecture=amd64
Nu se poate verifica certificatul serverului
Vă rugăm să verificați configurația openssl.

Am citit undeva ar putea fi iptables îl blochez, dar am DE IEȘIRE pe ACCEPTA TOATE. Și când pun ping https://canonical.com Primesc un răspuns sănătos.

Are cineva idee?

Mulțumesc pentru ajutor, @andrew-lowther. Am făcut cum ai sugerat. Nu am putut posta acest rezultat lung într-un comentariu la răspunsul tău.

Certificatele ca erau deja la cea mai recentă versiune. Testul de bucle pare bine și:

* Conectat la contracts.canonical.com (91.189.92.69) portul 443 (#0)
* au găsit 129 de certificate în /etc/ssl/certs/ca-certificates.crt
* au găsit 520 de certificate în /etc/ssl/certs
* ALPN, oferind http/1.1
* Conexiune SSL folosind TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* verificarea certificatului de server OK
* verificarea stării certificatului serverului SĂRATE
* nume comun: contracts.canonical.com (potrivit)
* data de expirare a certificatului de server OK
* data de activare a certificatului de server OK
* cheie publică certificat: RSA
* versiunea certificatului: #3
* subiect: CN=contracts.canonical.com
* data începerii: vineri, 16 iulie 2021 18:50:43 GMT
* data expirării: joi, 14 octombrie 2021 18:50:41 GMT
* emitent: C=US,O=Let's Encrypt,CN=R3
* compresie: NULL
* ALPN, server acceptat să utilizeze http/1.1
> GET / HTTP/1.1
> Gazdă: contracts.canonical.com
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 404 Nu a fost găsit
< Server: openresty/1.15.8.2
< Data: sâmbătă, 24 iulie 2021 10:10:20 GMT
< Content-Type: text/plain; set de caractere=utf-8
< Lungimea conținutului: 19
< Conexiune: păstrați-vă în viață
< Strict-Transport-Security: max-age=15724800; include SubDomains
< X-Content-Type-Options: nosniff
< X-Trace-Id: 05087364-13c5-426f-9a59-99c7384f2dde
<
404 Pagina nu a fost găsită
* Conexiunea #0 la gazdă contracts.canonical.com a rămas intactă`

Asta vă oferă alte indicii?

Multumesc din nou.

Mesajul de eroare indică că conexiunea este permisă, dar serverul dvs. VPS nu are încredere în certificatul serverului Canonical.

Un prim pas bun este să vă asigurați că certificatele rădăcină sunt actualizate pe serverul dvs. VPS.

apt-get update
apt-get install ca-certificates

Folosind răsuci este o modalitate simplă de a testa. Dacă această comandă eșuează cu o ieșire care include Problemă cu certificatul SSL atunci asta ar confirma emiterea certificatului.

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

De asemenea, puteți utiliza -k opțiunea cu răsuci pentru a ignora erorile de certificat și pentru a afla mai multe despre certificatul pe care îl primește serverul VPS.

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

EDITAȚI | ×

Ta răsuci rezultatul sugerează că certificatul serverului Canonical este de încredere. Serverul dvs. VPS poate ajunge la serverul Canonical și nimic nu pare să interfereze cu traficul.

Acestea sunt alte câteva comenzi pe care le puteți încerca, deși de obicei nu sunt necesare pentru a rula manual.

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

Cand eu strace A ua comanda care pare să caute în mod specific fișierul /usr/lib/ssl/certs/4042bcee.0. De asemenea, puteți verifica că acesta există și este un link simbolic către certificatul rădăcină. Acest link simbolic este creat de către c_rehash comanda.

# 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

EDITARE 2

Din comentariul tău sună ca /usr/lib/ssl/ directorul poate fi încurcat. Ar trebui să conțină mai multe legături simbolice

$ ls -l /usr/lib/ssl/
total 4
lrwxrwxrwx 1 root root 14 aprilie 15 2016 certs -> /etc/ssl/certs
drwxr-xr-x 2 root root 4096 19 februarie 14:10 diverse
lrwxrwxrwx 1 rădăcină rădăcină 20 februarie 17 10:21 openssl.cnf -> /etc/ssl/openssl.cnf
lrwxrwxrwx 1 root root 16 aprilie 15 2016 privat -> /etc/ssl/private

Dacă cineva vine aici cu un certificat eșuat, verifică atunci când încearcă curl -vs https://contracts.canonical.com începe cu instrucțiunile Aici

Comenzile afișate acolo sunt:

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

Asta încă nu a funcționat pentru mine. văzând Aici că folderul certs conține legăturile simbolice către fișierele de certificat. Am copiat fișierul în etc/ssl/certs și creați un link simbolic către acesta. (Copiarea a fost probabil inutilă). Apoi am rulat comanda de actualizare a certificatului pe care a menționat-o @Andrew c_rehash /etc/ssl/certs care a făcut smecheria.