Вопрос по TCP, HTTPS, certificates, ports, url's, etc..

[zVlad]

Я сейчас позавтракаю и начну грызть науку. А пока может кто-то знает ответ на мою проблему.
Есть три апп сервера на RedHat Linux под WebSphere DM: dev, qa, and prod каждый на своем линуксе сидит. Dev существует один под своим DM на своем линуксе, а qa и prod под своим, оба два, причем DM и рrod на одном линуксе, а qa на другом.
После стандартной инсталляции (сделаной мной в 2015 году) https ругается на сертификат мол он те трустед. Но соединение устанавливается и все работает на всех серверах. Попытка в лоб инсталировать сертификаты с сервера ничего не дала и я тогда махнул рукой на это. Ясно было, однако, что автоматом сгенерированные сертификаты несут неверную информацию в поле CN, взятую видимо где-то из линукса. На dev вообще CN=localhost, а на prod и qa имя сервера, но без .com. Т.е. надо было переделовать сертификаты и мне с этим заниматься на линукс совсм не хотелось, я как раз этим занимался тогда на мф.
Потом я зарычал и отказался от этой работы - я тогда остался один на мэйнфрэймах и мне не дали роста зп. Вместо меня поставили Китайца из другого департамента где он занимается другими WebSphere. И еще Программист там крутится.
Тем временем наш клиент в свою очередь начал рычать на то что он получает сообщения с намеками на секьюрити бридж с этих серверов, поле URL красное и есть "Certificat error" на бровзере.
Больше полгода назад наняли контрактора, Ван Дам его звать, решать эту проблему. Ван Дам довел dev до ума и оставил инструкции подробные как это делать. Китаец и Программист навалились на qa и prod используя инструкцию Ван Дама, и у них ничего не получилось пока.
Недавно Китаец уехал в Китай в отпуск на 4 недели. Клиент наш поставил ультиматум или-или, ASAP, штрафы, и тд. В прошлый четверг добрались до меня. Я, старый дурак, согласился. Опросил Программиста, взял инструкции Ван Дама. Вчера все просмотрел на системах, сравнивал dev с qa через призму этих инструкций - вса вроде ок, но не работает.
Сертификаты для приложения имеют CN=myaccess.qa.com, лежат в keystore связанном с портом 8443 через транспрот чэйн.

Короче читайте пока это. Я позавтракаю и продолжу.

[zVlad]

К приложению на сервере мы ходим по порту 9443. Но на dev все работает без указания порта, и наоборот если на dev указать этот порт начинаются проблемы с сертификатом. Это можно понять из того что в CN сертификата нет порта.
На qa если указать порт то работает с проблемами сертификата, а если порт не указывать то коннекция не устанавливается вообще.
Как я писал выше есть конфигурации (transport chain) с использованием порта 8443 и keystore в котором сертификат с url myaccess.ga.com (в случае dev это myaccess.dev.com).
Что такого магического в порту 8443? Как отследить все шаги по которым идет процесс чтобы дойти до сертификата и порта 9443?

[zVlad]

Есть идея, бегу проверять.

[Flash-04]

Проблема в только в том что сертификат not trusted?

Броузер проверяет несколько вещей:
1. Common name совпадает с доменным именем,
2. Сертификат не просрочен
3. Сертификат подписан CA который с списке trusted у броузера
4. Недавно ввели что сертификаты с sha1 более не trusted, минимум sha-256.
5. CA не revoked

[zVlad]

Проблема в только в том что сертификат not trusted?

Броузер проверяет несколько вещей:
1. Common name совпадает с доменным именем,
2. Сертификат не просрочен
3. Сертификат подписан CA который с списке trusted у броузера
4. Недавно ввели что сертификаты с sha1 более не trusted, минимум sha-256.
5. CA не revoked

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

[Palych]

Для начала хорошо бы посмотреть на сертификат из браузера:
Уточнить какой собственно сертификат используется и что с ним не так.
Потом (или до того) тщательно почитать как работает TLS handshake, server authentication.
Важно не торопиться с "пониманием".

[zVlad]

Для начала хорошо бы посмотреть на сертификат из браузера:
Уточнить какой собственно сертификат используется и что с ним не так.
Потом (или до того) тщательно почитать как работает TLS handshake, server authentication.
Важно не торопиться с "пониманием".

Проблема не в сертификате, кмк, аппликация отзывается на порт 9443 (ругаясь на сертификат), но если даже явно указать порт 8443, который, я вижу в SystemOut.log, этой аппликухе известен и она на него забайндилась, то в ответ тишина до таймаута с сообщением "...cannot display the webpage".

[zVlad]

Обнаружилась одна преграда - в файрволе линукса порты 8443, 443 не были открыты. После их открытия появились хотя бы поклепы на сертификат. Буду разбираться в понедельник.

P.S. Точнее поклепы на unsupported protocol.

[zVlad]

Работает.
Причина была в том что в SSL configuration для конечных пользователей стояло Client authentication = required, и слиент запрашивал TLS v1, который сервер, сконфигурированный для TLS v1.2 отвергал и клиент сдувался.
Поставил Client authentication = None и все заработало.

[kyk]

Домашний роутер D-link 868L . Нужно логиниться из-за пределов дома.

Раньше remote access работал нормально через http. Вчера включил опцию Secure Connection в настройках, чтобы через https

Теперь выдаёт ошибку в FFox:
The server rejected the handshake because the client downgraded to a lower TLS version than the server supports. Error code: SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT

и не хочет показывать страницу логина.
MS Explorer и Chrome тоже не могут открыть страницу роутера

Вопрос-1: можно ли пофикисить?
Вопрос-2: если вернуться к старым настройкам без Secure Connection, т.е. обычный http, чем рискую?

[deev_a_v]

Try this
https://knowledge.digicert.com/generali ... O3299.html

[kyk]

Try this
https://knowledge.digicert.com/generali ... O3299.html

У меня уже такие settings

[Boriskin]

Вопрос-1: можно ли пофикисить?

Проапдейтить браузер?

[kyk]

Проапдейтить браузер?

проапгроейдил и браузер и роутер firmware, не помогает

Вопрос-2: если вернуться к старым настройкам без Secure Connection, т.е. обычный http, чем рискую?

[kyk]

Когда убираю галочку "Use HTTPS" - работает нормально.
Когда ставлю галочку - не работает
Смотри картинку: http://oi66.tinypic.com/71kbbn.jpg

[uncle_Pasha]

Теперь выдаёт ошибку в FFox:
The server rejected the handshake because the client downgraded to a lower TLS version than the server supports. Error code: SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT

wireshark воспользуйтесь - все должно быть видно.

[Palych]

Когда убираю галочку "Use HTTPS" - работает нормально.
Когда ставлю галочку - не работает
Смотри картинку: http://oi66.tinypic.com/71kbbn.jpg

Может Вы наступаете на HTTP порт используя https:// prefix? Или наоборот...

[kyk]

Я так и не смог найти причину. Пришлось отказаться от "Use HTTPS"

[iDesperado]

а не может быть что когда "Нужно логиниться из-за пределов дома." работодатель перехватывает трафик и пускает через корпоративный прокси, а тот подменивает сертификаты ?

[Mobi]

Я так и не смог найти причину. Пришлось отказаться от "Усе ХТТПС"

1. перенесите свой remote admin port с порт 8080 на 443 и check "Use HTTPS"
2. на https://www.ssllabs.com/ssltest/index.html вбейте URL по которому пытаетесь удаленно администрировать
3. в репорте самые интересные места
Certificate
Protocols
Cipher Suites
Handshake Simulation
надо посмотреть что поддерживает Ваш router по HTTPS

4. заидите на https://cc.dcsec.uni-hannover.de/
report покажет что поддерживает Ваш browser по HTTPS

по результатам можно будет что-то сказать , а так информации маловато