Squid + SSL Bump не признает доверенные CA

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

# openssl verify 1.pem
1.pem: C = RU, ST = Moskovskaya obl., L = Krasnogorskiy rayon, O = Ltd. Russ Outdoor, OU = IT, CN = *.russoutdoor.ru
error 20 at 0 depth lookup:unable to get local issuer certificate

# openssl verify -CApath /etc/ssl/certs 1.pem
1.pem: C = RU, ST = Moskovskaya obl., L = Krasnogorskiy rayon, O = Ltd. Russ Outdoor, OU = IT, CN = *.russoutdoor.ru
error 20 at 0 depth lookup:unable to get local issuer certificate

# openssl verify -CAfile /etc/ssl/certs/geotrust2.pem 1.pem
1.pem: OK

Проверь /etc/ssl на наличие битых символических ссылок. В Gentoo для этого при обновлении пакета ca-certificates мы чистим /etc/ssl от такого хлама. Есть мнение, что не зря...

Неа, битых ссылок нет, я их тоже удаляю периодически оттуда.

Пока что решил заменой sslproxy_capath /etc/ssl/certs на sslproxy_cafile /etc/ssl/certs/ca-certificates.crt (это просто бандл из всех доверенных CA, генерируется при dpkg-reconfigure судя по всему) - всё сразу стало окей.

Молодец! А ты используешь прозрачный proxy?

А как относятся всякие клиент-банки к такому? Ну те, что через web бегают...

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

А банк клиенты ходят из отдельной зафаерволенной подсети минуя прокси, понятное дело что им такие хаки нравится не могут :)

А, если squid не прозрачный, а жёстко записан, то мы не можем увидеть чего было внутри https? Но видим на какую ссылку и на сколько много мегабайтов посетили?

Почему? Можно SSL дешифровать как в режиме прозрачного сквида, так и в режиме обычного прокси насколько я помню. Если SSL не дешифровать, то никаких ссылок видно не будет. Только IP сервера и кол-во переданных данных.

http://wiki.squid-cache.org/Features/SslBump

http://wiki.squid-cache.org/Features/DynamicSslCert

http://wiki.squid-cache.org/Features/BumpSslServerFirst

Ок! Я имел ввиду конечно-же не squid с SSLBump, а классический squid, я просто не задавался вопросом (я обычно смотрю общий трафик, и бегло смотрю ссылки куда ходил пользователь, не обращаю дюжего внимания http или https оно там...). С SSLBump в общем всё ясно, что оно представляется клиентом, расшифровывает SSL сессию, генерирует свой сертификат для сайта, предъявляет его клиенту, и строит на основе этого новую SSL сессию.

Вот мне стало интересно, как клиент-банк пропалит такую схему? В целом то пропалить можно... Как-нибудь по UserAgent или ещё как-то...

Если это чисто веб-клиентбанк, то особо никак, сквид юзерагента передает того, что у клиента.

Спасибо! Интересно!

1) Ты делаешь что-то неправильно

я скачал http://gb.symcb.com/gb.crt, конвертировал в PEM. Взял дебиановский же /etc/ssl/certs/GeoTrust_Global_CA.pem

Скопировал их в ~/cert_test/ca. перешёл туда, выполнил c_rehash вернулся в каталог с тестовым сертификатом

router@amalthea:cert_test$ openssl verify -CApath ca/  test.crt 
test.crt: OK

2) Авторы сайта https://sales.russoutdoor.ru страдают некоторой криворукостью. Они должны были включить в цепочку три сертификата, а включили только два, минуя промежуточный.

3) посмотри strace. Можно указать openssl ЛЮБОЙ CAfile, при этом он полезет за сертификатами в дефолтный CApath.

И ещё. У меня есть подозрение, что когда ты указываешь CAfile с промежуточным сертификатом ( gb.pem, «Subject: C=US, O=GeoTrust Inc., CN=GeoTrust SSL CA - G2») , openssl удовлетворяется уже на проверке промежуточного сертификата, т.к. ты назвал его доверенным.

Окей, я экспортировал оба сертификата (СА и промежуточный) в PEM, подсунул дебияну в /usr/share/ca-certificates, сделал dpkg-reconfigure ca-certificates, они там увиделись, добавились. Ссылка на них в /etc/ssl/certs появилась. Хотя они(GeoTrust) там, по идее, и так были.

А вот нифига. Корневой сертификат был ( /etc/ssl/certs/GeoTrust_Global_CA.pem ), а вот мутный промежуточный - нет.

router@amalthea:cert_test$ ls -l ca/
итого 8
lrwxrwxrwx. 1 router router   22 Авг 14 03:25 2c543cd1.0 -> GeoTrust_Global_CA.pem
lrwxrwxrwx. 1 router router    6 Авг 14 03:25 322109c8.0 -> gb.pem
lrwxrwxrwx. 1 router router   22 Авг 14 03:25 7999be0d.0 -> GeoTrust_Global_CA.pem
lrwxrwxrwx. 1 router router    6 Авг 14 03:25 bb0961ec.0 -> gb.pem
-rw-r--r--. 1 router router 1570 Авг 14 03:13 gb.pem
-rw-r--r--. 1 router router 1216 Авг 14 03:24 GeoTrust_Global_CA.pem

router@amalthea:cert_test$ ls -lh /etc/ssl/certs/| grep 322109c8 -i
router@amalthea:cert_test$ ls -lh /etc/ssl/certs/| grep bb0961ec -i
router@amalthea:cert_test$

Итого. Когда браузер подключался к этому криво настроенному https сайту, он [браузер] за промежуточным сертификатом шёл по указанному url ( либо в firefox он дополнительно установлен ). Когда выполнялась проверка через openssl, он НЕ лез в интернет за всяким мусором, т.к. не положено. Для прохождения проверки, достаточно было установить сертификат http://gb.symcb.com/gb.crt и выполнить c_rehash

Если у тебя при этом что-то не проходит, смотри strace

strace -f -ff -o /tmp/trace -s 8192 -r -T -- openssl verify test.crt

Ну а по-хорошему нужно постучать по голове ленивым админам, которые криво слепили цепочку сертификатов для веб-сервера

1) Ну, вот я и пытаюсь понять ЧТО я делаю не так. Делал всё по дебиановским манам. c_rehash делал, не помогает.

2) Там еще интереснее, они отправляют некий самоподписаный(!) сертификат с CN=«GeoTrust Primary Certification Authority - G2», действительный с 2007 по 2038 год, что не соответвтует реальным (они оба, промежуточный и корневой, до 2022 года). Может дело в этом.

И, кстати, правильный промежуточный сертификат (который от 2012 до 2022 года) включен в современные броузеры просто как доверенный, поэтому, судя по всему, в броузерах нет проблем с подключением из них.

3) Не сомневаюсь, но конкретно со сквидом мне помог именно cafile, capath не работал.

Вот мне стало интересно, как клиент-банк пропалит такую схему?

Прозрачный squid с SSLBump «не нравится» приватбанку.
В чем проблема я не выяснял, хоть это похоже на отдачу разных сертификатов с одного айпишника/днс-адреса.

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

Это понятно)

Там просто браузер очень быстро выдает сообщение, что сертификат не от этого сайта.

1) Ну, вот я и пытаюсь понять ЧТО я делаю не так. Делал всё по дебиановским манам. c_rehash делал, не помогает.

Скорее всего - установил неправильный сертификат. Нужен был

router@amalthea:cert_test$ openssl x509 -in ca/gb.pem -noout -text | egrep '^\s*(Subject|Issuer):'
        Issuer: C=US, O=GeoTrust Inc., CN=GeoTrust Global CA
        Subject: C=US, O=GeoTrust Inc., CN=GeoTrust SSL CA - G2

его url указан в сертификате сервера

            Authority Information Access: 
                OCSP - URI:http://gb.symcd.com
                CA Issuers - URI:http://gb.symcb.com/gb.crt

2) Там еще интереснее, они отправляют некий самоподписаный(!) сертификат с CN=«GeoTrust Primary Certification Authority - G2», действительный с 2007 по 2038 год, что не соответвтует реальным (они оба, промежуточный и корневой, до 2022 года).

Как ты этот сертификат смог получить?

3) Не сомневаюсь, но конкретно со сквидом мне помог именно cafile, capath не работал.

Ещё ты приводил цитаты, что с openssl тоже CApath не работал. А я привёл цитату, что после установки сертификата openssl работает :)

Вот ещё s_client:

router@amalthea:cert_test$ openssl s_client -CApath ca/ -connect sales.russoutdoor.ru:443
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = GeoTrust Inc., CN = GeoTrust SSL CA - G2
verify return:1
depth=0 C = RU, ST = Moskovskaya obl., L = Krasnogorskiy rayon, O = Ltd. Russ Outdoor, OU = IT, CN = *.russoutdoor.ru
verify return:1
---
Certificate chain
 0 s:/C=RU/ST=Moskovskaya obl./L=Krasnogorskiy rayon/O=Ltd. Russ Outdoor/OU=IT/CN=*.russoutdoor.ru
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G2
 1 s:/C=US/O=GeoTrust Inc./OU=(c) 2007 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G2
   i:/C=US/O=GeoTrust Inc./OU=(c) 2007 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G2
---
Server certificate

Скорее всего - установил неправильный сертификат. Нужен был

Я открыл этот сайт в хроме у себя, посмотрел цепочку сертификации, вытащил оттуда оба сертификата и сунул их в openssl, всё. Судя по тому, что указывая напрямую ca-certificates.crt всё работает, то сертификаты таки правильные.

Как ты этот сертификат смог получить?

Прогнал в SSL-тестилке: https://www.ssllabs.com/ssltest/analyze.html?d=sales.russoutdoor.ru&hideR...

Additional Certificates (if supplied)
Certificates provided	2 (1930 bytes)
Chain issues	Incomplete, Extra certs, Contains anchor
#2
Subject	GeoTrust Primary Certification Authority - G2   In trust store
SHA1: 8d1784d537f3037dec70fe578b519a99e610d7b0
Valid until	Mon Jan 18 23:59:59 UTC 2038 (expires in 23 years and 5 months)
Key	EC 384 bits
Issuer	GeoTrust Primary Certification Authority - G2   Self-signed
Signature algorithm	SHA384withECDSA

Ну или через openssl s_client -showcerts -connect 193.150.115.88:443 вытащить.

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

Ещё ты приводил цитаты, что с openssl тоже CApath не работал.

Как не работал, так и не работает, даже после c_rehash.