Не удается получить сайт SSL для правильной загрузки JS + CSS. Бросок 409 (конфликт)

я использую nginx с codeigniter обслуживать мой сайт.
Когда нет прокси, я могу правильно загрузить сайт ssl.

Но когда компьютер за прокси-сервером пытается получить к нему доступ, 409 конфликт.

Он может правильно загружать не-ssl-сайт за прокси-сервером.

Вот кодовый блок ssl в conf nginx:

Pastie Nginx Conf

Что странно, когда я непосредственно открываю файл css или js (например, набираю URL css в браузере), он загружается правильно.

Вот заголовки ответа + запроса возвращаемого актива 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)

Обслуживание статических активов не сработало ..

1

Решение

И документация nginx, и документация w3, возможно, позволят вам лучше понять проблему. Кажется, что проблема может быть связана с конфликтом при передаче запроса через прокси. Это означает, что прокси-сервер изменяет параметры запросов. Без просмотра и сравнения журналов обоих запросов трудно сказать, в чем разница.

Посмотрите на эти ссылки:

http://nginx.com/resources/admin-guide/nginx-ssl-termination/

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Также убедитесь, что ваши CSS и JS-запросы могут отличаться с точки зрения кэша, поэтому опять-таки прокси-сервер может сохранять запросы в том виде, как они есть.

1

Другие решения

Кэширование, похоже, не является проблемой, потому что не похоже, что вы устанавливаете кеш вообще. Чтобы установить кеш, вам нужно что-то вроде:
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:

Ошибка 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,
но это мог также потерять некоторую информацию о безопасности во время передачи прокси.

sec_error_inadequate_cert_type

Итак, 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;
}
}
1

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector