Может ли TheBat при подписывании сертификатом проигнорировать недоступность CRL центра сертификации? Дело в том, что организация выдавшая сертификат не публикует CRL на своем узле. Outlook закрывает на это глаза, а Бат нет… как то можно исправить?
Может ли TheBat при подписывании сертификатом проигнорировать недоступность CRL центра сертификации? Дело в том, что организация выдавшая сертификат не публикует CRL на своем узле. Outlook закрывает на это глаза, а Бат нет… как то можно исправить?
Не очень хорошо понимаю, все эти дела с сертификатами, только в общих чертах, но:
раз бат проверяет CRL, то видимо он запрашивает файл по http или https. если это так, и есть этот CRL, то можно запустить apache под виндой (как сервис конечно), и в hosts поправить IP, думаю, что это должно сработать
В принципе, это решение, но вдруг есть ключик в реестре?
В баглисте есть такой пункт: раньше бат как раз игнорировал CRLМожет это осталось как опция
>В баглисте есть такой пункт:
и номерок в BT можно сказать?
1. Выпрямить руки сертификатору "Или трусы наденьте, ии крестик снимите"Сообщение от bmu
2. Сменить СЦ и делать это
3. Использовать внутреннюю имплементацию, а не КриптоАПИ… в ней CRL, как я знаю, вообще не проверяется
2 aff:
>>В баглисте есть такой пункт:
>и номерок в BT можно сказать?
(#0005551) In CryptoAPI S/MIME implementation, if a certificate didn't have a CRL distribution points extension, The Bat! wrote that certificate revocation status is unknown and ceased to use this certificate.
Исправлено в 3.71.
2 Wanderer:
>1. Выпрямить руки сертификатору "Или трусы наденьте, ии крестик снимите"
К сожалению, не получится, им на нас наср***.
>2. Сменить СЦ и делать это
Тож не выйдет.
>3. Использовать внутреннюю имплементацию, а не КриптоАПИ… в ней CRL, как я знаю, вообще не проверяется
У нас гостовские ключи КриптоПро, внутренняя реализация с ними не справится.
Похоже придется веб-сервер поднять.