я использую nginx
с codeigniter
обслуживать мой сайт.
Когда нет прокси, я могу правильно загрузить сайт ssl.
Но когда компьютер за прокси-сервером пытается получить к нему доступ, 409
конфликт.
Он может правильно загружать не-ssl-сайт за прокси-сервером.
Вот кодовый блок ssl в conf nginx:
Вот заголовки ответа + запроса возвращаемого актива 409
Конфликт.
Заголовки запроса:
Accept:text/css,*/*;q=0.1
Accept-Encoding:gzip,deflate
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:ci_session=ca41f4c9930b678f07acb9a45c839b63
Host:www.mywebsite.com
If-Modified-Since:Wed, 24 Sep 2014 01:13:00 GMT
If-None-Match:"54221a9c-1da51"Referer:https://www.mywebsite.com/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36
Заголовки ответа:
Cache-Control:no-cache
Connection:close
Content-Length:1256
Content-Type:text/html; charset=utf-8
Pragma:no-cache
Proxy-Connection:close
При просмотре в FF это бросает это:
An error occurred during a connection to www.mywebsite.com. Certificate type not approved for application. (Error code: sec_error_inadequate_cert_type)
Обслуживание статических активов не сработало ..
И документация nginx, и документация w3, возможно, позволят вам лучше понять проблему. Кажется, что проблема может быть связана с конфликтом при передаче запроса через прокси. Это означает, что прокси-сервер изменяет параметры запросов. Без просмотра и сравнения журналов обоих запросов трудно сказать, в чем разница.
Посмотрите на эти ссылки:
http://nginx.com/resources/admin-guide/nginx-ssl-termination/
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Также убедитесь, что ваши CSS и JS-запросы могут отличаться с точки зрения кэша, поэтому опять-таки прокси-сервер может сохранять запросы в том виде, как они есть.
Кэширование, похоже, не является проблемой, потому что не похоже, что вы устанавливаете кеш вообще. Чтобы установить кеш, вам нужно что-то вроде:
location ~ *. (ico | css | js | gif | jpe? g | png) (\? [0-9] +)? $ {
истекает максимум;
log_not_found off;
}
Если вы посмотрите на пример конфигурации CI на вики nginx вы увидите, что она немного отличается.
Это также может быть проблемой с вашим $config['base_url']
установка в CI. Опять же, больше информации на той же вики-странице nginx.
Обновленный ответ:
Во-первых, вы можете получить больше информации, если поместите журналы в блок:
access_log /var/log/nginx/mywebserver.com_access.log;
error_log /var/log/nginx/mywebserver.com_error.log;
Или измените пути на что угодно.
Но, похоже, что мы можем иметь дело с двумя разными ошибками между 409
и sec_error_inadequate_cert_type
,
Итак, давайте сначала посмотрим на возможные причины ошибки 409:
Ошибка 409 может исходить из разных мест, но вот краткое утверждение о том, что это значит:
Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса. Этот код разрешен только в ситуациях, когда ожидается, что пользователь сможет разрешить конфликт и повторно отправить запрос.
Странно, это часто случается с запросами PUT (здесь думайте об этом как РЕДАКТИРОВАТЬ КОНФЛИКТ). Таким образом, одна проблема может заключаться в том, что запрос на создание CI переписывает эти файлы, вызывая тем самым 409. Вы также можете часто находить эту ошибку в Web Dav, что имеет смысл.
Он также может быть связан с частью keep-alive в том смысле, что он может генерировать активы по-другому из-за этого и, таким образом, запрашивает более старую версию актива при написании новой. Вы могли бы быть в состоянии исправить
что, добавив keepalive_timeout 75 75;
к блоку сервера. Это также может быть связано с заголовками Connection / Proxy-Connection. Вот еще немного чтения на Connection
и Proxy-Connection
заголовки.
Может быть проблема с прокси при переписывании обычного запроса. Лучше использовать:
return 301 $scheme:/$server_name$request_uri;
по нескольким причинам, некоторые из которых связаны с SEO,
но это мог также потерять некоторую информацию о безопасности во время передачи прокси.
Итак, FF имеет историю появления этой ошибки (на основе отчетов об ошибках), когда некоторые другие браузеры этого не делают. Это делает то же самое с Chrome?
Код sec_error_inadequate_cert_type также может указывать на много разных вещей:
Оказывается ли, что статические ресурсы обслуживаются в поддомене, который не распространяется на SSL-сертификат? Кроме того, вы можете указать конкретный ssl_protocols
и ssl_ciphers
в блоке сервера.
Они могут не применяться:
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:! aNULL:! MD5;
Я исследовал некоторые другие возможности, и я включил их в пример конфигурации nginx ниже, в котором есть еще несколько директив, которые могут помочь, поэтому посмотрите, может ли работать приведенный ниже conf.
Если вы нашли что-то в журналах ошибок после их реализации или если есть другая информация, полученная из другого браузера, то сообщите мне.
server{
listen 80;
server_name www.mywebserver.com;
return 301 $scheme:/$server_name$request_uri;
}
server {
listen 443 ssl;
ssl on;
ssl_certificate /etc/nginx/ssl/www.mysite.com.SSL.crt;
ssl_certificate_key /etc/nginx/ssl/www.mysite.com.key;
server_name www.mysite.com;
index index.php;
root /home/user/workspace/;
## Access and error logs.
access_log /var/log/nginx/mywebserver.com_access.log;
error_log /var/log/nginx/mywebserver.com_error.log;
## Keep alive timeout set to a greater value for SSL/TLS.
keepalive_timeout 75 75;
## Strict Transport Security header for enhanced security. See
## http://www.chromium.org/sts.
add_header Strict-Transport-Security "max-age=7200";
location / {
try_files $uri $uri/ /index.php;
}
location ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /usr/home/user/public_html$fastcgi_script_name;
include fastcgi_params;
}
location ~* .(ico|css|js|gif|jpe?g|png)(\?[0-9]+)?$ {
gzip_static on;
expires max;
add_header ETag '';
add_header Last-Modified '';
add_header Cache-Control "max-age=290304000, no-transform, public";
add_header Accept-Ranges '';
tcp_nodelay off;
log_not_found off;
## Set the OS file cache.
open_file_cache max=3000 inactive=120s;
open_file_cache_valid 45s;
open_file_cache_min_uses 2;
open_file_cache_errors off;
}
}