В сведениях сертификата данные о самоподписном сертификате на сервере, видимо тот, что используется ISPmanager-oм.
Nginx v1.8
Конфиг полный стандарт, даже не знаю есть ли смысл такой выкладывать, любые другие манипуляции к эффекту не приводят.
Сертификаты установлены правильно, и подключал со степлингом промежуточные сертификаты.
Смысл в том, что в других браузерах всё норм. Но IE в XP не поддерживает SNI. Это когда на одном сервере находятся несколько доменов с SSL сертификатами и с помощью nginx можно выбрать и настроить каждый домен со своим сертификатом. Первый запрос к серверу, когда приходит по https, сервер отдает неглядя первый попавшийся SSL, но ему нужно отдать правильный. Короче SNI спасает в этом плане и отдает из 10 доменов и 10 сертификатов нужный.
Но у меня вопрос в другом, SNI мне наоборот не нужна. На сервере 1 домен. Возможно глупая железка видит как второй домен сервер Апача, или локалхоста или даже http сервер ISPmanager (он как раз таки подписан самописным сертификатом), или ip адрес на порту 81 (nginx+apache). В настройках сервера указан основной домен к ip адресу уже по умолчанию, т.е. если вводим IP адрес в строке, то запускается сайт на домене, а не выдается ошибка 403, 404. В общем я не пойму что он видит и что ему нужно.
Также пытался писать пути к сертификатам прям в секции http{}, nginx это допускает, если ставим один wild сертификат которым подписываем все домены. Не помогает. Получается, что самоподписной сертификат гдето еще раньше засвечивается.
Пыхтел с настройками, ничего не получается. Но я вижу, что на других сайтах включен nginx и сайты отлично работают по https в ie8 XP с шифрацией RC4 (TLS), и это единственная шифрация в ie которую можно включить без уязвимых SSLv3. Хотя опять же, не имеет это никакого значения какая шифрация, суть в том что nginx выдает неправильный первый попавшийся сертификат сервера, хотя в конфиге nginx указан лишь один доверенный сертификат.
Я понимаю, что судя по статистике пользователей на IE8 остался 1,1% и к тому же половина боты с поддержкой JS, и понимаю что поддержку XP пора прекращать... новсё же, может кто подскажет как вылечить эту болезнь.
зы
В общем попытаюсь сделать еще тест, удалить самоподписной сертификат в ISP, вставив туда нормальный.---------- Добавлено 01.06.2015 в 01:01 ----------Всё. Победил.
Объясню у кого такая же проблема.
Это конфликт в nginx изза панели ISPmanager
В конфиге сервера nginx видим строчку include /usr/local/ispmgr/etc/nginx.domain;
Я думаю все понимают, что вставляется дополнительная секция из ISP по этому пути.
Строчка находится в самой первой секции http{}, соответственно самоподписной сертификат от ISP берет на себя приоритет и поэтому такая трабла в IE XP.
Есть 2 решения, либо удалить из nginx.domain пути на сертификаты и прописать в nginx.conf в секции http{} "правильные" подписанные сертификаты, либо заменить файлы сертификатов ISP
ssl_certificate /usr/local/ispmgr/etc/manager.crt;
ssl_certificate_key /usr/local/ispmgr/etc/manager.key;
manager.crt manager.key выданные в ЦС, что я и сделал. Ребут сервера и всё норм.
Да, попробовал строчку в http{ записать, отключил.
В общем чудеса в какойто степени разрешились.
Пошли любопытные логи, совсем не такие как были.
Не думаю что до конца победил, но уже на верном направлении.
Вопрос остался в приветствии, думаю ип адрес должен быть всё таки не 127.0.0.1...
Сейчас в свойствах письма уже такое: Received: from site.ru (site.ru [127.0.0.1])
by mail.site.ru (Postfix) with ESMTPA
В чем были проблемы?
Добавил домен в /etc/hosts 127.0.0.1 site.ru localhost localhost.localdomain localhost4 localhost4.localdomain4
А то там был только localhost
Это еще вызывало ошибку, на которую ругался postfix warning: numeric hostname: 11.11.11.11
Также в файлике /etc/sysconfig/network был глюк. Когда в панеле ISPmanager меняю имя хоста, то он не удаляет прежнее значение, в итоге тупо дописывает еще одну строку HOSTNAME=site.ru
Вобщем уже гдето близок к победе. По крайней мере стало понятно где копать. Теперь нужно убрать 127.0.0.1 в строке Received, видимо это тоже плохой знак. Там судя по всему должен стоять ИП сервера. Наверно по нему почтовики резольвят PTR запись, и этой информации я нигде не нашел.
Кстати такой же глюк на официальном сайте mvd.ru, но ребят это не парит, если письма не доставятся адресатам, натянут майлру вместе с алишером. ---------- Добавлено 27.05.2015 в 01:56 ---------- Всё. Победил 127.0.0.1
Меняем в /etc/hosts в строке 127.0.0.1 site.ru localhost localhost.localdomain localhost4 localhost4.localdomain4 ип адрес 127.0.0.1 на наш 11.11.11.11
Эта строчка по умолчанию прописалась после установки Centos, если честно, не знал что ее нужно менять вручную. ---------- Добавлено 27.05.2015 в 02:12 ---------- Чудеса... наконецто в Gmail попал не в спам.
Еще поидее часовые пояса надо синхронизировать. Синхра на время у меня установлена через крон, но часовой пояс поидее нужно выставить правильно. или нет?---------- Добавлено 27.05.2015 в 02:22 ----------Самое необычное, что теперь письмо принимается Gmail не в спам даже с отключенным релеем Гугл Apps, напрямую с моего сервера, без DKIM.
;; ANSWER SECTION:
x.x.x.x.in-addr.arpa. 3599 IN PTR мойдомен.ру.
;; Query time: 38 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue May 26 16:35:00 2015
;; MSG SIZE rcvd: 65
У меня сайт находится на одном сервере с postfix. почта находится не на mail.мойдомен.ру, а на мойдомен.ру
соответсвенно PTR сделана тоже на мойдомен.ру как у ya.ru. И у меня вопросы возникают. Можно ли вообще postfix делать на основном домене по 25 порту. Не на субдомене например mx.xxx.ru или mail.xxx.ru
у яндекса ya.ru PTR так
3.204.180.213.in-addr.arpa IN PTR www.yandex.ru
Но у них как видем PTR указывает на основной домен, с WWW причем. а основной указывает на
2 PTR записи
11.251.250.87.in-addr.arpa IN PTR yandex.ru
8.250.250.87.in-addr.arpa IN PTR rusearch.yandex.com
что меня вообще в корне запутало.---------- Добавлено 26.05.2015 в 17:51 ----------Я тут гдето читал, помоему в справке гугла, что делать почтовые сервера на основном домене нельзя, например если коннектится через telnet mydomain.ru 25, то это неправильно, и якобы письма могут не доставляться и чтото еще в том роде.
Не знаю, это верная информация и я действительно неправильно настроил сервак или ктото может опровергнуть?
PTR есть, и настроена провайдером правильно. До нее и после нее было одинаково. Или еще гдето на сервере о ней надо упомянуть?
Единственное, что успокаивает, просадка у всех. До этого думал, что у меня какието неполадки или гугл решил меня понизить в цене за клик.
Но сам сейчас понемногу рекламируюсь в эдвордс, и непонятки однако. Судя по цифрам с меня снимают в 3 раза больше, чем я указал за клик. Посмотрим потом общую статистику, может выровняется, но непонятки остались. Клики отслеживаю не только через эдвордс но и в метрике.
Вообще не слишком ясна просадка, которая началась уже в декабре. Обычно идет какойто кипишь, люди ищут товары, подарки, делают покупки. Всегда считал что в этот период максимальная конкуренция. Но сейчас прихожу к иным выводам. Или гугл делает деньги на этом периоде, чтобы покрыть какие либо недостачи за год, или порадовать акционеров. А нам втюхивают низкую стоимость клика и понижают CTR. С лета у меня ничего не поменялось, но CTR упал в 2 раза. Но еще заметил одну странную вещь.. 31 декабря. Казалось бы, все делают оливье и ждут гостей, ктото уже пьет. Трафик естественно падает в разы (если это сайт не тематики праздников), но тут самое прикольное... цена клика повышается и доход растет. И это 31 числа!!!!!!!!!!!!!! как так????????? А потом снова с 1 числа мгновенаая просадка. Что произошло днем 31 числа? сотрудники (ассеоры) гугл разошлись по домам и перестали скликивать "недействительные" клики? Недействительные - это те которые по ИХ мнению нужно отнять у вас, чтобы вы получили меньше доход. Вообще тему скликивания в своей статистике вижу постоянно. Открываю adsense, ыижу одну сумму, потом через минут отнимают.. и так постоянно. Т.е. реальный CTR в разы больше, но гугл себе в убыток не пойдет, говоря что в России кризис, и всё списывают на это.
Ну и второй вариант проблемы, как его вижу я. В декабре товарный кипиш, и видимо люди итак совершают много покупок и рекламироваться видимо уже не имеет особого смысла, так как покупки идут своим чередом и без рекламы. Отсюда понижение стоимости клика. И тем не менее не ясна ситуация описанная мной выше, которая рубит на корню все остальные мои догадки. Я хотел бы верить в то, что все лентяи ушли бухать (в России нужно запретить такие длительные трудовые каникулы), и лишь поэтому нужда в рекламе уменьшилась.. но много непоняток.
Нет не увеличивает. В любом случае, пока сайт молодой, Гугл вам не позволит зарабатывать выше определенной планки. Клики отсеиваются, как случайные. Там масса скрытых условий, кто наивно думает, что они не влияют, тот ошибается.
