Điểm:1

Gặp lỗi khi cố đính kèm mã thông báo ua

lá cờ cn

Tôi đang cố kích hoạt ESM trên máy chủ VPS 16.04 của mình, nhưng tôi gặp lỗi khi cố kết nối với máy chủ chuẩn. Lỗi tôi gặp phải sau khi chạy lệnh ssh # sudo ua đính kèm C122..... Là:

Không thể kết nối với máy chủ xác thực
Kiểm tra kết nối Internet của bạn và thử lại.
Không thể truy cập URL: https://contracts.canonical.com/v1/resources?kernel=4.4.0-1160.21.1.vz7.174.13&series=xenial&architecture=amd64
Không thể xác minh chứng chỉ của máy chủ
Vui lòng kiểm tra cấu hình openssl của bạn.

Tôi đã đọc ở đâu đó nó có thể là iptables chặn nó, nhưng tôi có HƯỚNG NGOAỊ trên CHẤP NHẬN TẤT CẢ. Và khi tôi ping https://canonical.com Tôi nhận được một phản ứng lành mạnh.

Có ai có ý kiến ​​gì không?


Cảm ơn sự giúp đỡ của bạn, @andrew-lowther. Tôi đã làm như bạn đề nghị. Tôi không thể đăng kết quả dài này trong nhận xét cho câu trả lời của bạn.

Ca-chứng chỉ đã có ở phiên bản mới nhất. Kiểm tra độ cong cũng có vẻ ổn:

* Đã kết nối với contract.canonical.com (91.189.92.69) cổng 443 (#0)
* đã tìm thấy 129 chứng chỉ trong /etc/ssl/certs/ca-certificates.crt
* đã tìm thấy 520 chứng chỉ trong /etc/ssl/certs
* ALPN, cung cấp http/1.1
* Kết nối SSL sử dụng TLS1.2/ECDHE_RSA_AES_256_GCM_SHA384
* xác minh chứng chỉ máy chủ OK
* xác minh trạng thái chứng chỉ máy chủ ĐÃ BỎ QUA
* tên chung: hợp đồng.canonical.com (khớp)
* ngày hết hạn chứng chỉ máy chủ OK
* ngày kích hoạt chứng chỉ máy chủ OK
* khóa công khai chứng chỉ: RSA
* phiên bản chứng chỉ: #3
* chủ đề: CN=contracts.canonical.com
* ngày bắt đầu: Thứ Sáu, ngày 16 tháng 7 năm 2021 18:50:43 GMT
* ngày hết hạn: Thứ năm, ngày 14 tháng 10 năm 2021 18:50:41 GMT
* nhà phát hành: C=US,O=Let's Encrypt,CN=R3
* nén: NULL
* ALPN, máy chủ được chấp nhận sử dụng http/1.1
> NHẬN / HTTP/1.1
> Máy chủ: hợp đồng.canonical.com
> Tác nhân người dùng: curl/7.47.0
> Chấp nhận: */*
>
< HTTP/1.1 404 Không tìm thấy
< Máy chủ: openresty/1.15.8.2
< Ngày: Thứ bảy, ngày 24 tháng 7 năm 2021 10:10:20 GMT
< Loại nội dung: văn bản/đồng bằng; bộ ký tự = utf-8
< Độ dài nội dung: 19
< Kết nối: giữ nguyên
< An ninh vận tải nghiêm ngặt: max-age=15724800; bao gồm tên miền phụ
< X-Content-Type-Options: nosniff
< X-Trace-Id: 05087364-13c5-426f-9a59-99c7384f2dde
<
Lôi 404 Không Tim Được Trang
* Kết nối #0 với máy chủ hợp đồng.canonical.com còn nguyên vẹn`

Điều này có cung cấp cho bạn bất kỳ manh mối nào khác không?

Cảm ơn một lần nữa.

guiverc avatar
lá cờ cn
[Ubuntu 16.04 LTS đã hết thời hạn hỗ trợ *chuẩn*](https://fridge.ubuntu.com/2021/03/13/extended-security-maintenance-for-ubuntu-16-04-xenial-xerus -begins-april-30-2021/) do đó hiện không có chủ đề ở đây trừ khi câu hỏi của bạn dành riêng cho việc giúp bạn chuyển sang bản phát hành Ubuntu được hỗ trợ. Hỗ trợ Ubuntu 16.04 ESM có sẵn, nhưng không thuộc chủ đề ở đây, xem https://askubuntu.com/help/on-topic Xem thêm https://ubuntu.com/blog/ubuntu-16-04-lts-transitions- to-extend-an ninh-bảo trì-esm
Điểm:1
lá cờ jp

Thông báo lỗi cho biết kết nối được cho phép nhưng máy chủ VPS của bạn không tin cậy chứng chỉ của máy chủ Canonical.

Bước đầu tiên tốt là đảm bảo chứng chỉ gốc được cập nhật trên máy chủ VPS của bạn.

cập nhật apt-get
apt-get cài đặt chứng chỉ ca

sử dụng Xoăn là một cách đơn giản để kiểm tra. Nếu lệnh này không thành công với đầu ra bao gồm Sự cố chứng chỉ SSL thì điều đó sẽ xác nhận vấn đề chứng chỉ.

cuộn tròn -vs https://contracts.canonical.com

Bạn cũng có thể sử dụng -k tùy chọn với Xoăn để bỏ qua lỗi chứng chỉ và tìm hiểu thêm về chứng chỉ mà máy chủ VPS đang nhận.

cuộn tròn -vsk https://contracts.canonical.com -o /dev/null

CHỈNH SỬA

Của bạn Xoăn đầu ra gợi ý rằng chứng chỉ của máy chủ Canonical được tin cậy. Máy chủ VPS của bạn có thể kết nối với máy chủ Canonical và dường như không có gì cản trở lưu lượng truy cập.

Đây là một vài lệnh khác mà bạn có thể thử, mặc dù chúng thường không cần thiết phải chạy thủ công.

cập nhật-ca-chứng chỉ
c_rehash /etc/ssl/certs

Khi tôi bước đi một ua lệnh có vẻ như nó đang tìm kiếm tệp cụ thể /usr/lib/ssl/certs/4042bcee.0. Bạn cũng có thể xác minh điều này tồn tại và là một liên kết tượng trưng đến chứng chỉ gốc. Liên kết tượng trưng này được tạo bởi c_rehash chỉ huy.

# ls -l /usr/lib/ssl/certs/4042bcee.0
lrwxrwxrwx 1 gốc gốc 16 ngày 19 tháng 2 14:09 /usr/lib/ssl/certs/4042bcee.0 -> ISRG_Root_X1.pem

CHỈNH SỬA 2

Từ bình luận của bạn có vẻ như /usr/lib/ssl/ thư mục có thể bị rối tung lên. Nó sẽ chứa một số liên kết tượng trưng

$ ls -l /usr/lib/ssl/
tổng cộng 4
lrwxrwxrwx 1 gốc gốc 14 ngày 15 tháng 4 năm 2016 chứng chỉ -> /etc/ssl/certs
drwxr-xr-x 2 root root 4096 ngày 19 tháng 2 14:10 linh tinh
lrwxrwxrwx 1 gốc gốc 20 ngày 17 tháng 2 10:21 openssl.cnf -> /etc/ssl/openssl.cnf
lrwxrwxrwx 1 gốc gốc 16 ngày 15 tháng 4 năm 2016 riêng tư -> /etc/ssl/private
lá cờ cn
Cảm ơn, @andrew-lowther. Tôi đã thực hiện hai lệnh, không thay đổi. Tôi đã kiểm tra tệp /usr/lib/ssl/certs/4042bcee.0, nhưng nó không tồn tại.
lá cờ cn
@andrew-lowther, tệp tồn tại tại /etc/ssl/certs/4042bcee.0. Tôi đã sao chép nó vào /usr/lib/ssl/certs/.., và thực thi lệnh ua và bây giờ nó đã hoạt động :) Không biết liệu đó có phải là quy trình đúng hay không. Nhưng cảm ơn :)
Andrew Lowther avatar
lá cờ jp
@Tezalsec rất vui vì nó đang hoạt động. Tôi đã thực hiện một chỉnh sửa nữa để hiển thị những liên kết tượng trưng nào nên tồn tại trong `/usr/lib/ssl` để tệp chỉ thực sự cần tồn tại trong `/etc/ssl/certs`
Điểm:0
lá cờ us

Nếu ai đó đến đây với chứng chỉ không thành công, hãy kiểm tra khi thử cuộn tròn -vs https://contracts.canonical.com bắt đầu với các hướng dẫn đây

Các lệnh hiển thị ở đó là:

cd /usr/share/ca-chứng chỉ
sudo mkdir letencrypt.org
cd letencrypt.org/
quên "https://letsencrypt.org/certs/isrgrootx1.pem"
Sudo update-ca-chứng chỉ

Điều đó vẫn không làm việc cho tôi. nhìn thấy đây rằng thư mục certs chứa các liên kết tượng trưng đến các tệp chứng chỉ. Tôi đã sao chép tập tin vào vv/ssl/certs và tạo một liên kết tượng trưng cho nó. (Việc sao chép có lẽ là không cần thiết). Sau đó, tôi chạy lệnh cập nhật chứng chỉ @Andrew đã đề cập c_rehash /etc/ssl/certs đó đã làm các trick.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.