Điểm:0

Nginx đảo ngược chứng chỉ ghi đè proxy

lá cờ cn

Tôi gặp sự cố khi ghi đè chứng chỉ bằng NGINX làm Proxy ngược chuyển tiếp tất cả yêu cầu tới Máy chủ Apache bằng và chứng chỉ cũ (TLS 1.0)

Đây là đầu ra cho tệp .conf của tôi:

người phục vụ {
nghe 80;
server_name cung cấp.metrotel.com.ar;
trả lại 301 https://provision.metrotel.com.ar$request_uri;
}

người phục vụ {
nghe 443 ssl http2;
server_name cung cấp.metrotel.com.ar;
ssl_certificate /etc/nginx/certs/metrotel.crt;
ssl_certificate_key /etc/nginx/certs/metrotel.key;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error_prov.log;
địa điểm / {
proxy_pass http://prov.metrotel.com.ar/;
proxy_ssl_certificate /etc/nginx/certs/metrotel.crt;
proxy_ssl_certificate_key /etc/nginx/certs/metrotel.key;

}
}

http://prov.metrotel.com.ar/ là máy chủ nơi đặt trang web và nó có chứng chỉ cũ. Có cách nào để ghi đè lên chứng chỉ đó không, bằng cách sử dụng chứng chỉ tôi có trong proxy ngược nginx của mình.

Tôi đã thử một số tùy chọn mà tôi luôn nhận được "NET::ERR_SSL_OBSOLETE_VERSION"


Máy khách Chrome bật (172.20.1.4)

Proxy (Nginx trên srv-nginx-a.metrotel.local -192.168.151.112)

Phụ trợ (prov.metrotel.com.ar) 192.168.59.20

tcpdump: đầu ra dài dòng bị chặn, sử dụng -v hoặc -vv để giải mã giao thức đầy đủ
nghe trên ens192, loại liên kết EN10MB (Ethernet), kích thước ghi 262144 byte

11:50:59.260014 IP 172.20.1.4.19710 > srv-nginx-a.metrotel.local.https: Flags [S], seq 979144705, win 29200, tùy chọn [mss 1460,nop,nop,sackOK,nop,wscale 4 ], chiều dài 0

11:50:59.260165 IP srv-nginx-a.metrotel.local.https > 172.20.1.4.19710: Flags [S.], seq 3107298579, ack 979144706, win 29200, tùy chọn [mss 1460,nop,nop,sackOK, nop,wscale 7], chiều dài 0

11:50:59.260397 IP 172.20.1.4.19710 > srv-nginx-a.metrotel.local.https: Flags [.], ack 1, win 1825, độ dài 0

11:50:59.282128 IP 172.20.1.4.19710 > srv-nginx-a.metrotel.local.https: Flags [P.], seq 1:536, ack 1, win 1825, độ dài 535

11:50:59.282204 IP srv-nginx-a.metrotel.local.https > 172.20.1.4.19710: Flags [.], ack 536, win 237, chiều dài 0

11:50:59.282659 IP srv-nginx-a.metrotel.local.https > 172.20.1.4.19710: Flags [P.], seq 1:153, ack 536, win 237, chiều dài 152

11:50:59.282869 IP 172.20.1.4.19710 > srv-nginx-a.metrotel.local.https: Flags [.], ack 153, win 1892, độ dài 0

11:50:59.293101 IP 172.20.1.4.19710 > srv-nginx-a.metrotel.local.https: Flags [P.], seq 536:587, ack 153, win 1892, độ dài 51

11:50:59.332644 IP srv-nginx-a.metrotel.local.https > 172.20.1.4.19710: Flags [.], ack 587, win 237, chiều dài 0

11:50:59.332935 IP 172.20.1.4.19710 > srv-nginx-a.metrotel.local.https: Flags [P.], seq 587:1300, ack 153, win 1892, độ dài 713

11:50:59.332967 IP srv-nginx-a.metrotel.local.https > 172.20.1.4.19710: Flags [.], ack 1300, win 248, chiều dài 0

11:50:59.333185 IP srv-nginx-a.metrotel.local.53190 > 192.168.59.20.http: Flags [S], seq 1924765737, win 29200, tùy chọn [mss 1460,sackOK,TS val 
180831520 ecr 0,nop,wscale 7], độ dài 0

11:50:59.333584 IP 192.168.59.20.http > srv-nginx-a.metrotel.local.53190: Flags [S.], seq 4244116336, ack 1924765738, win 5792, tùy chọn [mss 1460,sackOK,TS val 355823885 180831520,nop,wscale 7], độ dài 0

11:50:59.333605 IP srv-nginx-a.metrotel.local.53190 > 192.168.59.20.http: Flags [.], ack 1, win 229, tùy chọn [nop,nop,TS val 180831521 ecr 3558238853], độ dài 0

11:50:59.333639 IP srv-nginx-a.metrotel.local.53190 > 192.168.59.20.http: Flags [P.], seq 1:757, ack 1, win 229, tùy chọn [nop,nop,TS
val 180831521 ecr 3558238853], chiều dài 756: HTTP: GET / HTTP/1.0

11:50:59.333915 IP 192.168.59.20.http > srv-nginx-a.metrotel.local.53190: Flags [.], ack 757, win 58, tùy chọn [nop,nop,TS val 3558238854 ecr 180831521], độ dài 0

11:50:59.334144 IP 192.168.59.20.http > srv-nginx-a.metrotel.local.53190: Flags [P.], seq 1:520, ack 757, win 58, tùy chọn [nop,nop,TS val 3558238854 ecr 180831521], độ dài 519: HTTP: HTTP/1.1 302 Đã tìm thấy

11:50:59.334157 IP srv-nginx-a.metrotel.local.53190 > 192.168.59.20.http: Flags [.], ack 520, win 237, tùy chọn [nop,nop,TS val 180831521 ecr 3558238854], độ dài 0

11:50:59.334169 IP 192.168.59.20.http > srv-nginx-a.metrotel.local.53190: Flags [F.], seq 520, ack 757, win 58, tùy chọn [nop,nop,TS val 3558238854 ecr 180831521 ], chiều dài 0

11:50:59.334236 IP srv-nginx-a.metrotel.local.53190 > 192.168.59.20.http: Flags [F.], seq 757, ack 521, win 237, tùy chọn [nop,nop,TS
val 180831521 ecr 3558238854], độ dài 0

11:50:59.334272 IP srv-nginx-a.metrotel.local.https > 172.20.1.4.19710: Flags [P.], seq 153:1048, ack 1300, win 248, chiều dài 895

11:50:59.334438 IP 192.168.59.20.http > srv-nginx-a.metrotel.local.53190: 
Flags [.], ack 758, win 58, tùy chọn [nop,nop,TS val 3558238854 ecr 180831521], độ dài 0

11:50:59.373720 IP 172.20.1.4.19710 > srv-nginx-a.metrotel.local.https: Flags [.], ack 1048, win 2004, độ dài 0

11:50:59.407267 IP 172.20.1.4.19710 > srv-nginx-a.metrotel.local.https: Flags [P.], seq 1300:2013, ack 1048, win 2004, độ dài 713

11:50:59.407531 IP srv-nginx-a.metrotel.local.53192 > 192.168.59.20.http: Flags [S], seq 3919551832, win 29200, tùy chọn [mss 1460,sackOK,TS val 180831594 ecr 0,nop, wscale 7], độ dài 0

11:50:59.407867 IP 192.168.59.20.http > srv-nginx-a.metrotel.local.53192: Flags [S.], seq 2604868674, ack 3919551833, win 5792, tùy chọn [mss 1460,sackOK,TS val 3558238928 ecr928 180831594,nop,wscale 7], độ dài 0

11:50:59.407897 IP srv-nginx-a.metrotel.local.53192 > 192.168.59.20.http: Flags [.], ack 1, win 229, tùy chọn [nop,nop,TS val 180831595 ecr 3558238928], độ dài 0

11:50:59.407950 IP srv-nginx-a.metrotel.local.53192 > 192.168.59.20.http: Flags [P.], seq 1:757, ack 1, win 229, tùy chọn [nop,nop,TS
val 180831595 ecr 3558238928], chiều dài 756: HTTP: GET / HTTP/1.0

11:50:59.408211 IP 192.168.59.20.http > srv-nginx-a.metrotel.local.53192: Flags [.], ack 757, win 58, tùy chọn [nop,nop,TS val 3558238928 ecr 180831595], độ dài 0

11:50:59.408605 IP 192.168.59.20.http > srv-nginx-a.metrotel.local.53192: Flags [P.], seq 1:520, ack 757, win 58, tùy chọn [nop,nop,TS val 3558238928 ecr 180831595], độ dài 519: HTTP: HTTP/1.1 302 Đã tìm thấy

11:50:59.408627 IP srv-nginx-a.metrotel.local.53192 > 192.168.59.20.http: Flags [.], ack 520, win 237, tùy chọn [nop,nop,TS val 180831596 ecr 3558238928], độ dài 0

11:50:59.408642 IP 192.168.59.20.http > srv-nginx-a.metrotel.local.53192: Flags [F.], seq 520, ack 757, win 58, tùy chọn [nop,nop,TS val 3558238928 ecr 180831595 ], chiều dài 0

11:50:59.408711 IP srv-nginx-a.metrotel.local.53192 > 192.168.59.20.http: Flags [F.], seq 757, ack 521, win 237, tùy chọn [nop,nop,TS
val 180831596 ecr 3558238928], chiều dài 0

11:50:59.408748 IP srv-nginx-a.metrotel.local.https > 172.20.1.4.19710: Flags [P.], seq 1048:1943, ack 2013, win 259, độ dài 895

11:50:59.408974 IP 192.168.59.20.http > srv-nginx-a.metrotel.local.53192: Flags [.], ack 758, win 58, tùy chọn [nop,nop,TS val 3558238929 ecr 180831596], độ dài 0

11:50:59.408994 IP 172.20.1.4.19710 > srv-nginx-a.metrotel.local.https: Flags [.], ack 1943, win 2116, độ dài 0
Steffen Ullrich avatar
lá cờ se
Tôi không rõ bạn đang thực sự làm gì và không có gì có thể sao chép ở đây (tên miền không phân giải trong DNS). Bạn gặp lỗi này chính xác ở đâu, bạn đang cố truy cập chính xác URL nào, bằng công cụ nào? Ngoài ra TLS 1.0 không phải là chứng chỉ cũ mà là phiên bản giao thức TLS cũ. Và trong cấu hình của bạn, bạn thậm chí không truy cập trang web nội bộ bằng HTTPS, chỉ cần `http://...` .
Julian Rios avatar
lá cờ cn
Steffen, những miền đó là miền cục bộ, chúng không thể truy cập được từ Internet. Điều tôi muốn làm là sử dụng nginx làm proxy để nhập cung cấp.metrotel.com.ar trong trình duyệt của mình và khi nginx đọc URL đó, nó sẽ gửi URL tới prov.metrotel.com.ar. Thật tệ khi chỉ ra TLS 1.0 là một chứng chỉ cũ, đó là một giao thức cũ, bạn nói đúng. Tôi gặp lỗi đó trong prov.metrotel.com.ar (máy chủ lưu trữ) Ig Tôi thay đổi proxy_pass thành https://prov.metrotel.com.ar/ Tôi nhận được cùng một NET::ERR_SSL_OBSOLETE_VERSION. Câu hỏi của tôi là liệu có cách nào để "ghi đè" TLS 1.0 bằng TLS 1.2 bằng proxy không
Steffen Ullrich avatar
lá cờ se
*"Nếu tôi thay đổi proxy_pass thành prov.metrotel.com.ar, tôi sẽ nhận được cùng một NET::ERR_SSL_OBSOLETE_VERSION."* - một lần nữa, không rõ bạn gặp phải lỗi này ở đâu (máy khách, nhật ký nginx ...) và URL và khách hàng của bạn đang sử dụng chính xác để thử nghiệm. Tất nhiên, URL được khách hàng sử dụng phải là URL được cung cấp bởi nginx (`provision...`), không phải URL ban đầu được cung cấp bởi Apache (`prov...`).
dave_thompson_085 avatar
lá cờ jp
Nó không thực sự là 'ghi đè'. Với bất kỳ proxy nào, kể cả nginx, có hai kết nối TLS-trước đây là SSL khác nhau, một từ máy khách (trình duyệt, v.v.) đến proxy, một từ proxy đến máy chủ phụ trợ. Hai kết nối này và các thuộc tính của chúng là hoàn toàn riêng biệt, mặc dù dữ liệu cấp độ HTTP nhận được trên một kết nối được chuyển tiếp đến kết nối kia. Bạn có thể chụp ảnh bằng Wireshark hoặc tương tự, tốt nhất là trên hoặc càng gần càng tốt với máy proxy (nginx) không?
Julian Rios avatar
lá cờ cn
Hi guys, cảm ơn por sự giúp đỡ của bạn. Ngày mai tôi sẽ gỡ lỗi và đăng nó ở đây. Sử dụng TLS 1.2 và TLS 1.3 trong ssl nghe 443, tiếp tục hiển thị NET::ERR_SSL_OBSOLETE_VERSION. Thông báo hiển thị trong trình duyệt được gửi từ Máy chủ phụ trợ (prov.metrotel.com.at). Đó là cùng một lỗi trong Chrome, Firefox và Opera. Tôi sử dụng provision.metrotel.com.ar làm URL trong ứng dụng khách, vì vậy chuyển hướng hoạt động tốt, nhưng tôi không thể kết xuất TLS v1.0 và "nâng cấp" nó lên TLS v1.2 1.- Client to Proxy là TLS v1.2 2.- Proxy cho Backend là TLS v1.0 3.- Client to Backend cuối cùng là TLS v1.0 :(
dave_thompson_085 avatar
lá cờ jp
Theo tcpdump nginx đang nhận (rõ ràng) hai chuyển hướng 302, mặc dù nó không hiển thị các URL. **Có thể việc chuyển hướng khiến ứng dụng khách truy cập trực tiếp vào phần phụ trợ chứ không phải proxy?** Nếu bạn có (hoặc có thể có) curl, hãy thử `curl -vL https://proxy/desired_URL` để xem nó ở đâu/như thế nào đang chuyển hướng hoặc trong Chrome bật công cụ dành cho nhà phát triển (F12) và chọn tab mạng. Hoặc sử dụng Wireshark (như lần đầu tiên tôi đề xuất) để xem giải mã hoàn chỉnh; nếu bạn không thể cài đặt nó, hãy sử dụng `tcpdump -w` để chụp vào một tệp và di chuyển tệp đó đến một nơi nào đó mà bạn có thể sử dụng Wireshark.
dave_thompson_085 avatar
lá cờ jp
Đã thêm: với `curl -vL`, bạn cũng có thể chuyển hướng đầu ra dữ liệu sang một tệp, có thể là `/dev/null` (hoặc Windows `NUL:`), để dễ dàng tập trung vào các tiêu đề.
Điểm:1
lá cờ uz

Hãy thử bật TLS1.2 và 1.3 bằng cách thêm ssl_protocols TLSv1.2 TLSv1.3; cho bạn người phục vụ phần, như thế này:

người phục vụ {
    nghe 80;
    server_name cung cấp.metrotel.com.ar;
    trả lại 301 https://provision.metrotel.com.ar$request_uri;
    ssl_protocols TLSv1.2 TLSv1.3;
}
dave_thompson_085 avatar
lá cờ jp
Trong một http (nghe 80) `máy chủ` sẽ không làm gì cả. Nó sẽ chỉ có tác dụng trong https (nghe 443) `máy chủ`, nhưng mặc định đã bao gồm tối đa 1,2, điều này sẽ khiến Chrome hài lòng.
Điểm:0
lá cờ cn

Trên Wireshark pcap Kết nối giữa Máy khách (Chrome) và Proxy (Nginx) là TLS 1.2. Phần khác (TLS cũ của Nginx-Apache) chỉ là HTTP. Proxy đang hoạt động tốt, không có kết nối "không" giữa Máy khách và Máy chủ, proxy luôn ở giữa.

Đă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.