| 1 |
Anton Ananich wrote: |
| 2 |
|
| 3 |
> В силу специфики их работы они имеют потребность |
| 4 |
> шифровать свою переписку с помощью SSL сертификатов. |
| 5 |
|
| 6 |
Нет такого понятия "ssl-сертификат". |
| 7 |
Не надо выдумывать отсебятину, это запутывает и тебя, и собеседника. |
| 8 |
Лучше почитать RFC3280, RFC2510 и принять существующую терминологию, |
| 9 |
а заодно и получить ответы на 90% своих вопросов :) |
| 10 |
|
| 11 |
> В один день Паниковский теряет свой ноутбук вместе с сертификатом. Он |
| 12 |
> сообщает об этом администратору, администратор с помощью |
| 13 |
> # openssl -revoke panikovsky.pem |
| 14 |
> делает сертификат невалидным, выдает новый ноутбук и новый сертификат. |
| 15 |
> |
| 16 |
> Вопросы: |
| 17 |
> 1) Как _правильно_ нужно настроить CA, чтобы Бендер мог об этом узнать |
| 18 |
> о том, что сертификат скомпрометирован как можно скорее? |
| 19 |
> 2) Как протестировать, что CRL действительно блокирует сертификаты в |
| 20 |
> a) браузере (например firefox) |
| 21 |
> б) почтовом клиенте ( например Thunderbird или Microsoft Outlook) |
| 22 |
> |
| 23 |
|
| 24 |
Есть множество этапов, которые выполняют при проверке сертификата на |
| 25 |
валидность |
| 26 |
Что касается проверки на отозванность, то это вообще отдельная тема, |
| 27 |
т.к. каждый строит свою |
| 28 |
схему в зависимости от жесткости требований. |
| 29 |
Ну например приведу более менее полную схему. |
| 30 |
1. NotBefore <= NOW <= NotAfter |
| 31 |
2. Поиск CRL для данного УЦ в хранилище. |
| 32 |
2.1 Попытка обновить CRL через CDP (CRL Distrubution Point, опциональна, |
| 33 |
указывается в качестве расширения в сертификате УЦ) |
| 34 |
2.1.1 Если удалось, проверяем на присутствие в списке |
| 35 |
2.1.2 Если не удалось, можем игнорировать, при условии наличия в |
| 36 |
локальном хранилище |
| 37 |
неистекшего CRL, а можем обломать, в зависимости от параноидальности. |
| 38 |
3. Проверка статуса через службу OCSP, опять же возможны варианты, если |
| 39 |
не удалось до нее достучаться (доверять локальному CRL или нет). |
| 40 |
|
| 41 |
И это еще не все. Тема вопроса обширнейшая. |
| 42 |
В криптографической подсистеме винды есть даже понятие Revocation |
| 43 |
Provider, т.е. это отдельная сущность, которая |
| 44 |
исходя из своей логики, говорит тебе валиден сертификат или нет и |
| 45 |
которую можно написать под свои требования. |
| 46 |
|
| 47 |
Основная беда в том, что в линуксе ничего такого централизованного нет - |
| 48 |
хранилища сертификатов, единое криптоапи и т.д. |
| 49 |
Да даже нецентрализованного тоже в общем то нет, openssl который с |
| 50 |
ооочень большим натягом можно посчитать за стандарт |
| 51 |
каждое приложение использует как ему вздумается. |
| 52 |
|
| 53 |
Единственное - в мозилле (firefox, thinderbird, etc) криптуха более |
| 54 |
менее реализована, оно даже OCSP держит. |
| 55 |
|
| 56 |
> Ранее в рассылке было упомянуто решение: CRL Distribution Point, |
| 57 |
> однако поиск в сети не дал желаемых результатов. |
| 58 |
|
| 59 |
CDP это всего лишь вершина айсберга. |
| 60 |
|
| 61 |
> Надеюсь мы сможем найти истину вместе :) |
| 62 |
> |
| 63 |
|
| 64 |
Истина в том, что криптуха в линуксе в плачевном состоянии. |
| 65 |
А если говорить о каком-то стандарте на уровне системы, то ее просто нет. |
| 66 |
|
| 67 |
Тупое решение в лоб. |
| 68 |
1. Создаешь CA с расширением id-ce-cRLDistributionPoints (CDP по |
| 69 |
простому), там можно всякие URI указывать, |
| 70 |
самое простое - http. Будет типа http://blabla.bla/ca.crl |
| 71 |
(на чем CA поднимать не спрашивай, тут тоже все печально. самое простое |
| 72 |
- можешь из openvpn выдрать) |
| 73 |
2. На CA обеспечиваешь, чтобы текущий crl был доступен по тому же урлу, |
| 74 |
что и в расширении корневого сертификта. |
| 75 |
3. Магическим образом заставляешь клиентское ПО использовать проверку |
| 76 |
сертификатов по CRL вытащенгному с CDP |
| 77 |
(могу ошибаться, но вроде в openssl есть механизмы, которые сами это |
| 78 |
делают, если с curl'ом собирать) |
Archives