Điểm:0

Proxy đảo ngược Apache với chứng chỉ tự ký

lá cờ pl

Tôi chạy một thiết bị phần cứng Unifi đi kèm với chứng chỉ tự ký, được phát hành vào ngày unifi.local. Đối với thiết lập hiện tại của tôi, không có tùy chọn để nhập trực tiếp chứng chỉ trên công cụ vì một số lý do, vì vậy tôi đã cố gắng loại bỏ thông báo chứng chỉ không hợp lệ khỏi trình duyệt của mình bằng cách sử dụng proxy ngược dựa trên apache2 cung cấp quyền truy cập vào công cụ bên dưới miền khác, được bảo mật bằng chứng chỉ Letsencrypt.

Thiết lập hiện tại của tôi trông giống như sau:

Máy tính xách tay <-> Apache Reverse Proxy (2.4.48, Debian, chứng chỉ miền ký tự đại diện đáng tin cậy) <-> Thiết bị Unifi (chứng chỉ tự ký)

Ý tưởng của tôi là cung cấp một miền bảo mật có tên unifi.mydomain.tld cho phép truy cập an toàn vào thiết bị.

Trong proxy ngược apache của tôi, tôi đã tạo và kích hoạt tệp cấu hình giống như sau:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    Serveradmin [email protected]"
    ServerName unifi.mydomain.tld

    SSLProxyEngine On
    SSLProxyVerify none
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off
    SSLProxyCheckPeerExpire off

    ProxyPass "/" "https://10.0.1.1/"
    ProxyPassReverse "/" "https://10.0.1.1/"
    ProxyPreserveHost Off

    TransferLog /var/log/apache2/proxies/unifi_access.log
    ErrorLog /var/log/apache2/proxies/unifi_error.log

    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains; preload"
    </IfModule>

    SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2
    SSLCipherSuite SSL ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384
    SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
    SSLOpenSSLConfCmd DHParameters /mnt/certificates/diffie-hellman/dhparam4096.pem
    SSLHonorCipherOrder on
    SSLCompression off
    SSLSessionTickets off

    SSLCertificateFile /etc/letsencrypt/live/mydomain.tld/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/mydomain.tld/privkey.pem
</VirtualHost>

# Originally from /etc/letsencrypt/options-ssl-apache.conf
# Written directly here because otherwise SSLProtocol etc is overwritten
# Add vhost name to log entries:
SSLOptions +StrictRequire
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" vhost_combined
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common

</IfModule>

Tuy nhiên, nếu tôi truy cập unifi.mydomain.tld, trình duyệt của tôi trả lại chứng chỉ cho unifi.local và không cho unifi.mydomain.tld và do đó, nó tạo ra lỗi chứng chỉ không đáng tin cậy. Một số mẹo được đề cập để biến SSLProxyXác minh đến không ai, và SSLProxyCheckPeerName, SSLProxyCheckPeerCN, và SSLProxyCheckPeerHết hạn đến tắt, tuy nhiên, không có thủ thuật nào trong số này hiệu quả. Tôi không thể nhập chứng chỉ solidoil tự ký của Unifi trên máy chủ proxy ngược của mình.

Tôi không chắc liệu apache2 có phàn nàn về chứng chỉ hay trả lại chứng chỉ sai hay không. Làm cách nào để tôi có thể truy cập vào công cụ bằng cách duyệt qua unifi.mydomain.tld mà không nhận được lỗi chứng chỉ này?

dave_thompson_085 avatar
lá cờ jp
Đó không phải là apache, gần như chắc chắn trình duyệt của bạn đang kết nối với Unifi KHÔNG phải apache như bạn muốn. Kiểm tra độ phân giải tên cho unifi.mydomain.tld mà trình duyệt sử dụng. Tôi nói 'độ phân giải tên' không phải là DNS cụ thể; độ phân giải tên _often_ sử dụng DNS nhưng nó có thể sử dụng nhiều phương pháp khác. Nếu nghi ngờ, hãy thử chụp ảnh mạng (wireshark, tcpdump hoặc tương tự) hiển thị (các) kết nối trình duyệt và đặc biệt là địa chỉ IP và địa chỉ MAC mà nó kết nối.
Điểm:1
lá cờ us

Điều này làm việc cho tôi!

Yêu cầu:

  1. Apache Tomcat trên: 8443 với khóa tự ký
  2. Apache HTTPD với Reverse Proxy tới localhost:8443 Tomcat
  3. Apache HTTPD ĐÒI HỎI Xác thực lẫn nhau của khách hàng. Nếu đó không phải là yêu cầu đối với bạn, thì hãy đặt: SSLVerifyClient none
  4. Apache HTTPD sẽ chuyển danh tính X.509 của người gọi thông qua proxy ngược tới tomcat.



 Nhật ký ErrorLog/ssl_error_log
 Nhật ký TransferLog/ssl_access_log
 LogLevel cảnh báo
 Yêu cầu proxy đang bật
 ProxyPass /test1 https://localhost:8443/test/
 ProxyPassReverse /test1 https://localhost:8443/test/
# Cài đặt SSL cho DMZ
 Công cụ SSL bật
 Giao thức SSL TLSv1.2
 SSLCipherSuite CAO:!aNULL:!MD5:!SEED:!IDEA
 SSLCertificateKeyFile /home/jdoyle/sample_httpd_server_example_root_ca_.key
 SSLCertificateFile /home/jdoyle/sample_httpd_server_example_root_ca_.cer
 SSLCACertificateFile /home/jdoyle/consolidated_cacerts.cer
# Cài đặt SSL cho Proxy ngược
 SSLProxyEngine bật
 SSLProxyXác minh yêu cầu
 SSLProxyProtocol TLSv1.2
 SSLProxyCheckPeerName tắt
 SSLProxyCACertificateFile /home/jdoyle/consolidated_cacerts.cer
 Yêu cầu SSLVerifyClient
 SSLVerifyDepth 10
# Truyền SSL Conext cho tomcat

RequestHeader đặt SSL_CLIENT_S_DN "%{SSL_CLIENT_S_DN}s"
RequestHeader đặt SSL_CLIENT_I_DN "%{SSL_CLIENT_I_DN}s"
RequestHeader đặt SSL_SERVER_S_DN_OU "%{SSL_SERVER_S_DN_OU}s"
RequestHeader đặt SSL_CLIENT_VERIFY "%{SSL_CLIENT_VERIFY}s"
RequestHeader đã đặt SSL_CLIENT_V_START "%{SSL_CLIENT_V_START}s"
Tiêu đề yêu cầu đã đặt SSL_CLIENT_V_END "%{SSL_CLIENT_V_END}s"
Tiêu đề yêu cầu đã đặt SSL_CLIENT_M_VERSION "%{SSL_CLIENT_M_VERSION}s"
RequestHeader đã đặt SSL_CLIENT_M_SERIAL "%{SSL_CLIENT_M_SERIAL}s"
RequestHeader đặt SSL_CLIENT_VERIFY "%{SSL_CLIENT_VERIFY}s"
Tiêu đề yêu cầu đã đặt SSL_SERVER_M_VERSION "%{SSL_SERVER_M_VERSION}s"
RequestHeader đặt SSL_SERVER_I_DN "%{SSL_SERVER_I_DN}s"
....

SSLOptions +ExportCertData +StrictRequire
....




Ghi chú:

một. SSLProxyCACertificateFile dành cho kết nối httpd<->tomcat và chứa Khóa công khai của chứng chỉ tự ký của Máy chủ Tomcat.

b. SSLCACertificateFile dành cho kết nối DMZ <-> httpd và phải chứa và tất cả Chứng chỉ CA cho bất kỳ kết nối gửi đến nào.

Drudge avatar
lá cờ pl
Cảm ơn, hy vọng rằng tôi không cần cài đặt phần mềm bổ sung như Tomcat, tuy nhiên cách này hoạt động.

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