nginx là proxy ngược với SSL ngược dòng


18

Tôi đang xây dựng proxy cho API nội bộ để cho phép khách hàng kết nối mà không cần phải cài đặt chứng chỉ tự ký.

Các khách hàng (được xây dựng, sở hữu và chỉ sử dụng nội bộ) sẽ kết nối qua SSL với hộp nginx, nơi tôi đang sử dụng XSendfile để xác thực thông tin đăng nhập ở cấp ứng dụng (ứng dụng rails). Nếu thông tin đăng nhập hợp lệ, kết nối sẽ được gửi lại cho nginx nơi nó sử dụng proxy_pass để gửi kết nối đến máy chủ ngược dòng.

Bây giờ điều này hoạt động rất tốt cho các kết nối http tiêu chuẩn, nhưng tôi đang cố gắng tìm ra cách thêm chứng chỉ của chúng tôi vào hỗn hợp.

Câu hỏi này gần giống với câu hỏi này , nhưng với yêu cầu chứng chỉ vụng về.

Điều này thậm chí có thể với nginx? Có một giải pháp tốt hơn?

Tôi cũng sẽ giải quyết http từ khách hàng -> nginx và chứng chỉ tự ký từ nginx đến API.

Câu trả lời:


19

Đối với bất kỳ ai vấp phải câu hỏi này muốn sử dụng nginx, bạn có thể thiết lập câu hỏi này như bất kỳ proxy thông thường nào và để chấp nhận chứng chỉ tự ký từ phụ trợ, bạn cần cung cấp chứng chỉ pem đã xuất (và có lẽ là khóa) và đặt xác minh ssl tắt. Ví dụ:

...

server {
    listen       10.1.2.3:80;
    server_name  10.1.2.3 myproxy.mycompany.com;

    location / {
         proxy_pass                    https://backend.server.ip/;
         proxy_ssl_trusted_certificate /etc/nginx/sslcerts/backend.server.pem;
         proxy_ssl_verify              off;

         ... other proxy settings
    }

Nếu mặt sau an toàn của bạn đang sử dụng SNI Nhận dạng Tên Máy chủ với nhiều máy chủ được phục vụ cho mỗi cặp IP / Cổng, bạn cũng có thể cần đưa proxy_ssl_server_name on;vào cấu hình. Điều này hoạt động trên nginx 1.7.0 trở lên.


1
proxy_ssl_server_name on;là tất cả những gì tôi cần để làm việc này khi ủy quyền lưu lượng truy cập đến máy chủ lưu trữ trên Google App Engine bằng SSL được quản lý bởi Google! (Đây không phải là chứng chỉ tự ký hoặc bất cứ điều gì, vì vậy nó chỉ cần một dòng đó). Cám ơn về tiền bo nhiều.
XP84

Tôi nhận được 'không "ssl_cert ve" được định nghĩa cho chỉ thị "lắng nghe ... ssl" nếu tôi không sử dụng ssl_cert ve. Có thể proxy SSL mà không cần cung cấp chứng chỉ ngược dòng?
Damien

Nhận xét không đúng chủ đề vì đây là về việc ủy ​​quyền http kết nối với https ngược dòng. Nếu bạn muốn proxy https thì có lẽ nên giải quyết tốt hơn dưới dạng một câu hỏi riêng biệt. Câu trả lời nhanh và ngắn gọn là Không Nginx không thể "nghe" cổng https mà không có chứng chỉ và khóa riêng.
người dùng linux shonky

5

Tôi nghĩ rằng bạn có thể muốn một cái gì đó như thế này (rõ ràng đơn giản hóa cho ví dụ này):

worker_processes  1;
events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;
    keepalive_timeout  65;

    upstream backend {
        server mybackendserver:443;
    }

    server {
        server_name localhost;
        listen 443 ssl;
        ssl_certificate /etc/nginx/server.crt;
        ssl_certificate_key /etc/nginx/server.key;
        ssl_verify_client off;
        location / {
            proxy_pass  https://backend;
            proxy_set_header Host $http_host;
            proxy_set_header X_FORWARDED_PROTO https;
        }
    }
}

Điều duy nhất bạn có thể phải thay đổi là làm cho "Máy chủ" rõ ràng - ví dụ, nếu, tên máy chủ được ủy quyền của bạn không giống với tên máy chủ được sử dụng trên máy chủ proxy nginx.


Theo hiểu biết của tôi, các tham số ssl_certert và ssl_cert ve_key đề cập đến kết nối máy khách , không phải kết nối ngược dòng. Có phải vậy không?
simonmaddox

1
Từ những gì tôi hiểu, vâng. Trong ví dụ này, chứng chỉ mà khách hàng nhìn thấy là chứng chỉ do nginx cung cấp. nginx thấy (và xác minh? Tôi không chắc chắn ...) cái được cung cấp bởi máy chủ, nhưng không chuyển qua máy khách.
Mứt

3

Đối với bất kỳ ai gặp phải điều này trong tương lai, cuối cùng tôi đã không sử dụng nginx cho việc này.

Thay vào đó, tôi đã kết thúc bằng cách sử dụng stunnel trong "chế độ máy khách". Rất dễ dàng để thiết lập, và làm chính xác những gì tôi cần.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.