Apache не обслуживает Django на 443 (AWS) - PullRequest
2 голосов
/ 16 мая 2019

У меня есть приложение django, которое я пытаюсь обслуживать по протоколу HTTPS и изо всех сил. Я не силен в конфигах Apache и пытаюсь собрать это воедино. Надеюсь, кто-то может указать на то, что кажется простым упущением.

Мой сертификат настроен, и когда я захожу на мой сайт по адресу http://, он перенаправляется на https:// с действительным сертификатом, выданным Amazon. Так что это кажется правильным.

МОЯ ПРОБЛЕМА

Я просто вижу страницу с:

Индекс /

РЕДАКТИРОВАТЬ # 1:

Дополнительные эксперименты показывают, что без каких-либо дополнительных файлов .conf я получаю django на http и https, как и ожидалось. Если я включаю только перенаправление *.80, я всегда получаю https, как задумано, но только индексную страницу apache, как упомянуто выше, без django.

Вот мои конфиги, написанные с помощью команд контейнера:

/ etc / httpd / conf.d / wsgi.conf (который переписывается aws при каждом развертывании)

LoadModule wsgi_module modules/mod_wsgi.so
WSGIPythonHome /opt/python/run/baselinenv
WSGISocketPrefix run/wsgi
WSGIRestrictEmbedded On

<VirtualHost *:80>

Alias /static/ /opt/python/current/app/www/static/
<Directory /opt/python/current/app/www/static/>
Order allow,deny
Allow from all
</Directory>


WSGIScriptAlias / /opt/python/current/app/proof/proof/wsgi.py


<Directory /opt/python/current/app/>
  Require all granted
</Directory>

WSGIDaemonProcess wsgi processes=3 threads=20 display-name=%{GROUP} \
  python-home=/opt/python/run/venv/ \
  python-path=/opt/python/current/app user=wsgi group=wsgi \
  home=/opt/python/current/app
WSGIProcessGroup wsgi
</VirtualHost>

LogFormat "%h (%{X-Forwarded-For}i) %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

/ и т.д. / HTTPD / conf.d / virtualhost_http.conf

<VirtualHost *:80>
  RewriteEngine On
  RewriteCond %{HTTP:X-Forwarded-Proto} =http
  RewriteRule .* https://%{HTTP:Host}%{REQUEST_URI} [L,R=permanent]
</VirtualHost>

/ etc / httpd / conf.d / virtualhost_https.conf (необязательно. Я получаю один и тот же результат с этим файлом или без него)

<VirtualHost *:443>
Alias /static/ /opt/python/current/app/www/static/
<Directory /opt/python/current/app/www/static/>
Order allow,deny
Allow from all
</Directory>

WSGIScriptAlias / /opt/python/current/app/proof/proof/wsgi.py process-group=wsgi

<Directory /opt/python/current/app/>
  Require all granted
</Directory>

</VirtualHost>

РЕДАКТИРОВАТЬ # 2:

Вот лучшее из имеющихся у меня свидетельств того, что происходит с VHosts

[ec2-user@ip-000-00-00-000 conf.d]$ ls -l
total 16
-rw-r--r-- 1 root root 1024 May 16 06:56 enable_mod_deflate.conf
-rw-r--r-- 1 root root  162 May 15 23:10 healthd.conf
-rw-r--r-- 1 root root  104 May 15 23:10 mod_reqtimeout.conf
-rw-r--r-- 1 root root  783 May 16 06:56 wsgi.conf
[ec2-user@ip-000-00-00-000 conf.d]$ apachectl -S
[Thu May 16 07:22:36.788065 2019] [so:warn] [pid 24579] AH01574: module wsgi_module is already loaded, skipping
VirtualHost configuration:
*:80                   is a NameVirtualHost
         default server ip-000-00-00-000.us-west-2.compute.internal (/etc/httpd/conf.d/virtualhost_http.conf:1)
         port 80 namevhost ip-000-00-00-000.us-west-2.compute.internal (/etc/httpd/conf.d/virtualhost_http.conf:1)
         port 80 namevhost ip-000-00-00-000.us-west-2.compute.internal (/etc/httpd/conf.d/wsgi.conf:7)
ServerRoot: "/etc/httpd"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/etc/httpd/logs/error_log"
Mutex authdigest-opaque: using_defaults
Mutex watchdog-callback: using_defaults
Mutex proxy-balancer-shm: using_defaults
Mutex rewrite-map: using_defaults
Mutex authdigest-client: using_defaults
Mutex lua-ivm-shm: using_defaults
Mutex proxy: using_defaults
Mutex authn-socache: using_defaults
Mutex default: dir="/var/run/httpd/" mechanism=default 
Mutex mpm-accept: using_defaults
Mutex cache-socache: using_defaults
PidFile: "/var/run/httpd/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="apache" id=48 not_used
Group: name="apache" id=48 not_used

А вот свидетельство того, что сертификат работает, но не подключается к Django

(v-env) My-MacBook-Pro$ curl -v https://www.proofapp.io
* Rebuilt URL to: https://www.proofapp.io/
*   Trying 50.112.160.41...
* TCP_NODELAY set
* Connected to www.proofapp.io (50.112.160.41) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=www.proofapp.io
*  start date: May 15 00:00:00 2019 GMT
*  expire date: Jun 15 12:00:00 2020 GMT
*  subjectAltName: host "www.proofapp.io" matched cert's "www.proofapp.io"
*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: www.proofapp.io
> User-Agent: curl/7.54.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html;charset=ISO-8859-1
< Date: Thu, 16 May 2019 07:28:17 GMT
< Server: Apache/2.4.39 (Amazon) mod_wsgi/3.5 Python/3.6.8
< Vary: Accept-Encoding,User-Agent
< Content-Length: 161
< Connection: keep-alive
< 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
 <head>
  <title>Index of /</title>
 </head>
 <body>
<h1>Index of /</h1>
<ul></ul>
</body></html>
* Connection #0 to host www.proofapp.io left intact

1 Ответ

0 голосов
/ 11 июня 2019

Скотт, не уверен, что с тех пор вы решили эту проблему, но я поделюсь дополнительной перспективой и стратегиями на случай, если у вас ее нет - или для будущих читателей.

Удобный способ решения этой проблемыиспользовать балансировщик нагрузки для вашего SSL-терминации.Это будет означать отсутствие сложных настроек на уровне приложений, а также обеспечит повышение производительности (и возможную экономию затрат) за счет разгрузки процессов шифрования / дешифрования HTTPS на другие ресурсы AWS.

Подробнее об этих стратегиях и реализациях можно прочитать нассылки ниже.Если у вас есть дополнительные вопросы, я с удовольствием предоставлю дополнительную информацию о конкретных действиях.

Рекомендации по балансировке нагрузки AWS

Документы AWS по прекращению SSL

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...