В Континенте требует обновить CRL
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Alex_04
- —>
- Ушел
- ТОФК
- Сообщений: 2378
- Спасибо получено: 396
finsem пишет: lk.budget.gov.ru — статус сертфиката — сертификат просрочен.
lk2012.budget.gov.ru — статус сертификата — требуется обновить CRL.
CRL- требуется обновление.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- finsem
- Автор темы —>
- Не в сети
- Сообщений: 31
- Спасибо получено: 1
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Alex_04
- —>
- Ушел
- ТОФК
- Сообщений: 2378
- Спасибо получено: 396
finsem пишет: Возьму совет на заметку для следующего раза.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Gvinpin
- —>
- Ушел
- Сообщений: 2033
- Спасибо получено: 268
finsem пишет: В настройках континента полазили (но ничего не меняя), заработало.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- finsem
- Автор темы —>
- Не в сети
- Сообщений: 31
- Спасибо получено: 1
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Gvinpin
- —>
- Ушел
- Сообщений: 2033
- Спасибо получено: 268
finsem пишет: Прошлый (очередной) раз помогло на вкладке CDP нажать "Скачать crl". Сегодня не помогло. Опять требует обновить CRL. Файл ucfk_gost12.crl скачала и установила в хранилище "Доверенные корневые. " Что еще поделать?
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- finsem
- Автор темы —>
- Не в сети
- Сообщений: 31
- Спасибо получено: 1
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Gvinpin
- —>
- Ушел
- Сообщений: 2033
- Спасибо получено: 268
finsem пишет: Ведь через неделю опять это все будет. Опять скачивать и вручную?
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Alex_04
- —>
- Ушел
- ТОФК
- Сообщений: 2378
- Спасибо получено: 396
Gvinpin пишет:
finsem пишет: Файл ucfk_gost12.crl скачала и установила в хранилище "Доверенные корневые. " Что еще поделать?
Недавно поставил на проблемном АРМе оба этих САС в "Локальный компьютер" и в "Доверенные корневые" и в "Промежуточные" — помогло (просроченные удалял при этом).
Не знаю прав или нет, но на всякий случай туда же установил и ucfk_2020.crl — не будет лишним для сертов после 17.02.2020 года выпуска.
Куда и как публиковать файлы CRL и CRT?
Как известно, каждый выданный в CA сертификат (кроме самоподписанных сертификатов. Корневой сертификат так же является самоподписанным сертификатом) содержит 2 расширения:
- В расширении «CRL Distribution Points (CDP)» хранятся ссылки на CRL издавшего конкретный сертификат CA;
- В расширении «Authority Information Access (AIA)» хранятся ссылки на сертификат CA, издавшего конкретный сертификат. А для сертификатов, выданных CA под управлением Windows Server 2008 и выше — могут содержаться ссылки на OCSP Responder (см. OCSP (часть 1) и OCSP (часть 2))
Эти ссылки берутся не из воздуха, а из настроек CA. Вот как они выглядят для дефолтной инсталляции Certificate Services:
В принципе, эти настройки годятся для нормальной работы certificate chaining engine в небольших сетях с одним лесом и доменом без сайтов (или с сайтами, соединённых быстрыми каналами). Если сеть состоит из нескольких доменов (или лесов с настроенным Cross-forest enrollment) и сайтами, соединённых не очень быстрыми каналами, то эти настройки уже могут приводить к сбоям построения и проверок цепочек сертификатов. Я не буду рассказывать, что означают галочки, т.к. с ними вы можете ознакомиться в статьях CRL Publishing Properties и AIA Publishing Properties, а приступлю сразу к разбору путей.
Первый путь указывает путь файловой системы, куда физически публикуются файлы CRL и CRT. Следующая ссылка ( LDAP://
Вот как будут выглядеть расширения CDP и AIA в выдаваемых сертификатах при таких настройках:
- CDP
[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=ldap:///CN=Contoso%20CA,CN=DC1,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=contoso,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
URL=http://dc1.contoso.com/CertEnroll/Contoso%20CA.crl
- AIA
[1]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=ldap:///CN=Contoso%20CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=contoso,DC=com?cACertificate?base?objectClass=certificationAuthority
[2]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://dc1.contoso.com/CertEnroll/DC1.contoso.com_Contoso%20CA.crt
Как вы видите, ссылки в расширениях расположены в том же порядке, что и в настройках CA.
Это важно знать, поскольку certificate chaining engine (сокращённо назовём его CCE) будет проверять ссылки в том порядке, в котором они приведены в расширениях сертификата. Т.е. сперва будет пробовать скачать файл из Active Directory в течении 10 секунд. Если за 10 секунд файл не скачается, CCE будет пытаться скачать указанный файл по следующей ссылке (HTTP). При этом времени на это будет отводиться в 2 раза меньше (т.е. 5 секунд), чем в предыдущей попытке. И так будет происходить с каждой последующей ссылкой, пока не будет добыт файл, закончатся ссылки или отвалится по таймауту. На обработку каждого расширения для CCE выделяется ровно 20 секунд.
Уже на данном этапе видно, что любой недоменный клиент (будь то смартфон, изолированная рабочая станция в интернете, etc.) при попытке скачать файл может терять до 10 секунд на обработку первой ссылки, которая всегда завершится неудачей. Следовательно, первой ссылкой в CDP/AIA должна быть ссылка, которая использует универсальный для всех протокол (это должен быть HTTP), не смотря на то, что в домене, где расположен CA доступ через LDAP будет чуточку быстрее.
Второй момент заключается в репликации объектов AD. После того как CRL/CRT были опубликованы в Active Directory, клиенты об этом узнают не сразу, т.к. здесь вступает фактор репликации AD. Поскольку все объекты PKI публикуются в AD в разделе forest naming context, то эти данные реплицируются не только в прелелах текущего домена, но и всего леса. Поэтому задержки в появлении новых файлов у клиентов могут быть очень значительными и достигать нескольких часов. Задержки могут составлять время до двух полных циклов полной репликации в лесу. А если у вас используется cross-forest enrollment, то там ситуация будет ещё хуже, поскольку это ещё будет зависить от периодичности репликации объектов PKI между лесами (AD не поддерживает репликацию между лесами и репликация объектов PKI выполняется вручную) и уже может достигать нескольких суток. По этой причине рекомендуется либо вовсе отказаться от публикации CRL/CRT в AD и включения этих ссылок в сертификаты, либо располагать следом за более доступными протоколами.
С HTTP тоже не всё так идеально, как это может показаться с первого взгляда. Совсем не обязательно, чтобы сервер CA выполнял и роль веб-сервера (хотя, только для внутреннего использования это допустимо с определёнными оговорками). Будет лучше даже если файлы CRL/CRT будут копироваться как на внутренний, так и на внешний веб-серверы. В идеале эти файлы должны копироваться как минимум на 1-2 внутренних и 1-2 внешних веб-сервера для обеспечения высокой доступности. В таких случаях уже используется 4-я ссылка в настройках CA, которая должна указываь на шару DFS, чтобы файлы автоматически распространялись по веб-серверам. И вот здесь мы снова сталкиваемся с латентностью репликации DFS между серверами. Если все схемы публикации CRL/CRT подвержены латентности репликации, то как с этим бороться, чтобы файлы были всегда в актуальном состоянии?
Примечание: хоть CCE поддерживает скачивание CRL и CRT с HTTPS ссылок, делать это категорически нельзя, иначе CCE свалится в бесконечный цикл проверки сертификатов.
Периодичность публикации и обновления файлов CRL и CRT
По умолчанию в Windows Server основные CRL (Base CRL) публикуются раз в неделю и инкрементные CRL (Delta CRL) публикуются раз в сутки. Файлы сертификатов CA обычно обновляются через промежутки равные времени жизни сертификата самого CA (или чаще, если сертификат CA обновляется внепланово). Если сертификаты CA нужно обновлять достаточно редко (раз в несколько лет) и к этому следует готовиться отдельно, то обновление CRL происходит автоматически без вмешательства администратора и здесь требуются особые корректировки о которых мы сейчас и поговорим.
Если посмотреть на CRL, то мы увидим следующее:
Сейчас нас будут интересовать только 3 поля:
- Effective Date — указывает дату и время с которого данный CRL считается действительным и оно по умолчанию на 10 минут меньше, чем фактическое время, чтобы покрыть издержки рассинхронизации времени между сервером и клиентом;
- Next Update — указывает дату и время, когда заканчивается срок действия конкретного CRL и он считается недействительным;
- Next CRL Publish — указывает дату и время публикации следующего списка CRL.
Примечение: время в этих полях указывается в формате UTC без учёта временных зон.
Обычно время Next Update и Next CRL Publish одинаково. Но у меня, как вы видите на картинках, Next Update равен 8 дням (дефолтный срок действия CRL), а вот Next CRL Publish равен 7 дням после начала действия CRL. Т.е. CRL обновляется каждые 7 дней, но срок действия равен 8 дням (период публикации CRL + время overlap). Это сделано как раз для покрытия расходов времени (издержки репликации) распространения списков отозванных сертификатов от сервера CA до точек, откуда клиенты будут скачивать CRL. Как это делается?
Для этого в реестре на сервере CA по пути HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\CA Name существует 4 ключа:
- CRLOverlapUnits — указывает время до истечения срока действия текущего основного CRL, за которое будет публиковаться новый основной CRL.
- CRLOverlapPeriod — указывает единицу измерения этого времени для основного CRL
- CRLDeltaOverlapUnits — указывает время до истечения срока действия текущего инкрементального (если используется) CRL, за которое будет публиковаться новый инкрементальный CRL
- CRLDeltaPeriodPeriod — указывает единицу измерения этого времени для инкрементального CRL.
Если вы используете LDAP ссылки в расширениях CDP/AIA сертификатов и/или у вас есть латентность репликации файлов между веб-серверами, то вы должны отрегулировать это время, которое должно быть не менее, чем максимальное время репликации каталога AD во всём лесу или DFS как для основных, так и для инкрементальных CRL (если они у вас используются). Данную операцию можно автоматизировать утилитой certutil:
certutil –setreg ca\CRLOverlapUnits 1
certutil –setreg ca\CRLOverlapPeriod «days»
certutil –setreg ca\CRLDeltaOverlapUnits 8
certutil –setreg ca\CRLDeltaOverlapPeriod «hours»
net stop certsvc & net start certsvc
Примечание: CRLOverlap не может быть больше периодичности публикации BaseCRL, а CRLDeltaOverlap не может быть больше 12 часов.
в результате новые основные CRL будут публиковаться за сутки до истечения времени действия предыдущего основного CRL и новые инкрементальные CRL будут публиковаться за 8 часов до истечения предыдущего. Этим самым вы сможете гарантировать, что клиенты всегда получат актуальные CRL’ы. Более детальные сведения о порядке подсчёта временных интервалов публикации CRL и срока их действия можно ознакомиться здесь: How EffectiveDate (thisupdate), NextUpdate and NextCRLPublish are calculated
Общая периодичность публикации самих файлов CRL зависит от количества отзываемых сертификатов за некоторый промежуток времени (обычно измеряется в неделях). Если сертификаты отзываются десятками в неделю, то есть смысл сократить периодичность публикации основных CRL до 2 раз в неделю и Delta CRL до 2-х раз в сутки. Если сертификаты отзываются редко (реже, чем раз в неделю), то периодичность публикации Base CRL можно увеличить до 2-4 недель, а от Delta CRL можно даже отказаться или публиковать раз в неделю. Но это касается только Issuing или Online CA. Для Offline CA рекомендации будут чуть другие. Поскольку Offline CA выдают сертификаты только другим CA и большую часть времени выключены, для них следует отключить публикацию Delta CRL (установив параметр CRLDeltaPeriodUnits в ноль), а основные CRL публиковать раз в 3-12 месяцев. Хоть это и Offline CA, но на него так же распространяются требования по корректировке времени публикации и срока действия CRL.
CDP и AIA в корневых сертификатах
Как уже отмечалось, расширения CDP и AIA содержат ссылки на CRL/CRT издавшего конкретный сертификат CA, то с корневыми сертификатами будет немного иначе. Если быть точнее, то в корневых сертификатах этих расширений быть не должно совсем. Почему? Windows Server 2003 по умолчанию добавлял эти расширения в самоподписанный сертификат, когда CA конфигурировался как корневой CA. В нём AIA содержал ссылки по которым можно было скачать этот же сертификат. Очень прикольно :-).
А CDP — не менее прикольно. Корневые сертификаты всегдя являются конечной точкой самой цепочки и доверия этой цепочки сертификатов. К корневым сертификатам доверие всегда устанавливается явное путём помещения сертификата в контейнер Trusted Root CAs (а ко всем остальным сертификатам устанавливается неявное доверие через цепочку сертификатов). Следовательно отменить доверие корневому сертификату CA можно только одним способом — удалить сам сертификат из контейнера Trusted Root CAs и никак иначе. Вторая проблема заключается в том, что все CRL подписываются закрытым ключом самого CA. А теперь предположим, что CA отозвал свой сертификат и поместил его в CRL. Клиент скачивает CRL и видит, что сертификат CA отозван. Можно предположить, что это всё и никакой проблемы здесь нет. Однако, получается, что CRL подписан отозванным сертификатом и мы не можем доверять этому CRL как и считать сертификат CA отозванным. Именно поэтому начиная с Windows Server 2008 при установке корневого CA, эти расширения по умолчанию уже не включены в корневой сертификат. А для Windows Server 2003 приходилось лепить костыли в файле CAPolicy.inf:
[AuthorityInformationAccess]
Empty = true
[CRLDistributionPoint]
Empty = true
Как показывает практика, очень много администраторов игнорируют такие вещи и делают всё простым Next-Next, за что они должны гореть в аду. Но не только простые Windows-админстраторы, а луноходы (фаны линукса) тоже должны там гореть. Как живой пример бардака в сертификатах приведу компанию StartCom, которая в сентябре 2009 получила право выдавать EV (Extended Validation) сертификаты и вот их корневой сертификат: http://www.startssl.com/sfsca.crt
Мало того, что у них в корневом сертификате есть расширение CDP, но и с ссылками на CRL у них в цепочке тоже бардак мутный. Есть подозрение, что это сделано для поддержки какой-то ветки линукса (для совместимости или просто как костыль), но вот такой он опенсорс. Так что не каждый публичный и коммерческий CA следует всем бест-практисам. А вам советую им следовать, тогда меньше вероятность, что вы потом будете гореть в аду.
Изменения в существующих инфраструктурах
Изменение путей в уже существующих инфраструктурах вопрос достаточно серьёзный, хоть и прост в реализации. Если вы решились на такой шаг, то следует руководствоваться следующими правилами:
- пути публикации физических файлов можно располагать в произвольном порядке;
- новые ссылки к файлам, по которым клиенты будут их скачивать должны располагаться первыми, т.е. с более высоким приоритетом (кроме случаев, когда вы добавляете ссылки только для обеспечения более высокой доступности файлов. Тогда новые ссылки можно просто добавить в хвост уже существующим);
- если вы собираетесь уйти от существующих ссылок на CRL/CRT, то в для них следует отключить опцию публикации ссылок в сертификатах. Однако, до окончания действия сертификата CA вы будете обязаны их поддерживать в рабочем состоянии, т.к. они содержатся в уже выданных сертификатах. А новые ссылки появятся только в сертификатах, которые были выпущены после изменения CDP/AIA.
- если у вас корневой сертификат уже содержит расширения CDP/AIA, то вы не можете их оттуда убрать до момента обновления корневого сертификата. При обновлении корневого сертификата на Windows Server 2003, вам потребуется создать CAPolicy.inf файл, прописать нужные настройки (например, как уже указано выше с пустыми CDP и AIA). Более подробно про файл CAPolicy.inf можно прочитать по ссылке: http://technet.microsoft.com/en-us/library/cc728279(WS.10).aspx
Новые технологии
С выходом Windows Server 2008 Enterprise Edition вы можете внедрить в своей сети Online Responder для снижения нагрузки на серверы публикации CRL (хоть пути к OCSP публикуются в расширении AIA, к файлам CRT это никакого отношения не имеет). Но даже внедрение OCSP не решает этих проблем, поскольку реализация OCSP в Windows Server основана на регулярном чтении CRL и, следовательно, зависит от латентности репликации AD и/или DFS, а так же этим сервисом могут пользоваться только клиенты начиная с Windows Vista. Хочу отметить один приятный момент. Если изменения ссылок на CRL/CRT скажутся только на новых сертификатах (уже выпущенные сертификаты ничего не будут знать о новых путях в CDP/AIA), то интегрировать OCSP внутри домена/леса с уже существующей инфраструктурой PKI достаточно легко. Все уже выданные сертификаты могут быть проверены на отзыв с использованием OCSP: Managing OCSP Settings with Group Policy.
Заключение
В данном посте я обозначил ключевые моменты в структуированном (как мне кажется) виде, которые следует знать при планировании публикации файлов CRL/CRT и ссылок на них. Как вы видите, внедрение новых технологий пока что не освобождает от знания и соблюдения рекомендаций публикации CRL/CRT в вашей инфраструктуре PKI. Я считаю этот материал достаточным для начального и среднего уровня знаний по теме revocation и chain building и для более детального изучения всего этого процесса уже следует обратиться сюда: Certificate Revocation Checking in Windows Vista and Windows Server 2008.
Сертификат сервера CRL не загружен или устарел
Внимание. Если у Вас при подписании не видит сертификат, то:1 — попробуйте зайти через Internet Explorer и подписать.
2 — существует проблема с сертификатами по 2012 госту, где в самом сертификате наименование организации больше 127 символов — тогда придется делать конвертацию контейнеров .
Эта статья о том что при входе в ЛК не видно сертификатов.
После перехода на Континент TLS-клиент версии 2.0 столкнулся с несколькими проблемами.
Первая проблема — после установки и попытки запуска программы (для настройки) выходила ошибка доступ к конфигурационному файлу запрещен — с ней успешно разобрались.
Вторая проблема — при попытках подписать документ, перестали отображаться сертификаты на сьемных носителях.
Если пробывать подписывать через иконку «сертификаты Windows», идет беконечный цикл подписания. Если встать на сьемный носитель и нажать «обновить» — сертификаты не появляются.
Решение крылось в удалении плагина eXtended Container — который будет отображаться в панеле управления в программах и компонентах — он установился при переходе на Континент TLS-клиент 2.0.
Там же будет и ключик для него.
- 18-12-2017, 16:14
- 5 439
crl не прошел проверку — такую ошибку стало выдавать у моих специалистов при входе в Электронный Бюджет.
Лечится довольно просто, перезапуском службы Континент ТЛСа.
Перезапускаем службу, перезаходим в ЭБ, выбираем нужный сертификат для входа и работаем дальше.
Похожие новости
lk.budget.gov.ruАДМИНИСТРАЦИЯ ГОРОДА-КУРОРТА КИСЛОВОДСКАКрасные камни Кисловодск — часть 1Гора кольцо Кисловодск (легенда)Call to undefined function build_rssТамбуканская грязь
Смена сертификата сервера Continent TLS Client
с сайта Федерального Казначейства актуальный сертификат сервера.
3. Выставляем галочки как на скриншоте и переходим во вкладку настройки соединений. Если ранее у вас уже был установлен и корректно настроен то там уже будет строчка. Для чистоты эксперимента выделяем ее и нажимаем кнопку Удалить. Создадим соединение с нуля нажав на кнопку Добавить соединение.
. Шаг №1 — вводим адрес сервера lk.budget.gov.ru, жмем Далее.
5. Шаг №2 — указываем путь до сертификата который скачали с самого начала этого руководства и выбираем его, жмем Далее.
6. Шаг №4 — указываем адрес получения списка отзывов. Вот он: https://rostelecom.ru/cdp/guc.crl Жмем Далее.
7. Тоже самое делаем и в следующем окне, только указываем уже этот список отзыва: http://crl.roskazna.ru/crl/ucfk.crl
8. Жмем Ок. Новый сертификат сервера установлен.
РАБОТАЕМ С РЕГИОНАМИ!
Сегодня особенный привет работникам бюджетной сферы. Поговорим о наболевшем. О работе в системе ГИС «Электронный бюджет». Который просто кишит ошибками.
Вот эта ошибка: «crl сертификата сервера не загружен или устарел» , по запросу на которую вы сюда и пришли, она тянется с августа 2020г. Тогда в электронном бюджете произошли большие изменения, и вместе с ними, например, «приклеились» и всякие ошибки, которые до сих пор не могут быть устранены в автоматическом режиме в «полюбившемся» вам континент tls 2.0. Уж извините за сарказм.
ЭБ: crl сертификата сервера не загружен или устарел
Если вы видите такую ошибку в своём TLS — клиенте, значит нужно установить «список отзыва» вручную
Проблема в том, что ещё 2 года назад программисты УФК говорили, что обычные пользователи не должны выискивать вручную в интернете «рецепты», и всё должно делаться автоматически в Континент TLS 2.0 «по кнопке»:
. Континент TLS 2.0
Теперь переходим к процедуре установки «списка отзыва»
По ней надо пройти, и вы увидите заголовок:
Сертификаты и Списки аннулированных сертификатов Удостоверяющего центра Федерального казначейства
Сертификаты и Списки аннулированных сертификатов Удостоверяющего центра Федерального казначейства
Список этот будет меняться с течением времени. Но ссылка работает пока. Это файлы с расширением .CRL на текущий момент их 6. Но не суть важно. Главное понять как их устанавливать. Итак, скачиваем все .CRL — файлы с этой страницы в какую-либо папку:
Установка списка отзыва вручную
И правой мышкой, по очереди на каждом файле, нажимаем и выбираем в меню «Установить список отзыва CRL». Следуйте несложным инструкциям после этого (грубо говоря жмём на все вопросы «ОК», «далее» и т.п.)
P.S. Данный рецепт получил от тех.поддержки УФК.
Типовые проблемы при установке и настройке рабочего места для Электронного Бюджета
Причина: Не установлен набор системных библиотек windows visual С++ redistributable, необходимый для завершения установки. В большинстве случаев причина кроется в установке заглушек вместо полноценных компонентов, их полным отсутствием или повреждением.
В ASN1 встречен неожиданный конец данных
Причина: Проблема кроется в старых сертификатах. Континент ТЛС клиент не может прочитать некоторые сертификаты, с неподдерживаемыми знаками (например ;
«» и т.п.) и встретив их в хранилище сертификатов Windows отказывается запускаться.
Решение: Вычислить проблемные сертификаты и избавиться от них. Следует помнить, что пользователю доступны не все хранилища сертификатов, поэтому удалять нужно используя оснастку Windows и проверять хранилище локального компьютера. Или прибегнуть к помощи специалиста.
Доступ к конфигурационному файлу запрещен — классическая и самая распространенная ошибка после установки Континент ТЛС клиента
Решение: Предоставить текущему пользователю права на чтение и изменение данных каталогов и веток реестра. В некоторых случаях, придется стать их владельцем, чтобы выставить права и увидеть скрытые ветки реестра которые так же желает использовать Континент ТЛС клиент. Список исчерпывающий, поэтому если Вы предоставили все права на все ветки, но проблема не решилась, значит что-то упущено (некоторые ветки реестра не видны, пока не выдать права текущему пользователю). Если ничего не получается, то Вы всегда можете обратиться к нашим специалистам за помощью.
При попытке подключения к адресам электронного бюджета в нижнем правом углу появляется бесконечное кол-во сообщений от Континента, подключение сразу прерывается
Причина: В 9 случаях из 10 это Dr.Web и его програмные продукты. Межсетевой экран антивирусов этого вендора требует тщательной настройки для беспроблемной работы электронного бюджета.
Решение №1: Отказ от а, с его полным удалением и перезагрузкой. Решение №2: Настройка Континент ТЛС клиента через Непрозрачное проксирование.
Первый вариант простой, но оставляет ваш компьютер незащищенным если у Вас нет альтернатив под рукой. Второй вариант требует дополнительной настройки АРМ, выделение свободного сокета под прокси-сервер континент тлс клиента
При входе в электронный бюджет недоступны формы для работы. Главное меню отображается, но при открытии любого подраздела меню — пустая страница
Причина: Проверить ссылку для входа. Скорее всего вы входите через http:// . Для корректного отображения всех таблиц и форм вход должен осуществляться через http:// без . Ремарка: Сейчас большинство таблиц отображается и при входе через https, но пользователи могут с вами не согласиться — организации открывающиие 71 счет для перечисления денег по столкнутся с трудностями при работе по этому протоколу.
Решение: Требуется корректная настройкачерез http или дополнительные тонкие настройки браузера. могут реализовать работу Chromium-подобных браузеров для работы через https.
При входе в Электронный Бюджет идет постоянно запрос сертификата снова и снова, или выдает ошибку «Internet Explorer не может отобразить эту страницу»
Причина: Самый вероятный и самый печальный исход — сертификат пользователя сформирован некорректным образом. Настройки были изменены перед формированием запроса на текущий сертификат. Чтобы удостоверить в этом, необходимо протестировать текущий сертификат и проверить алгоритмы, используемые при его формировании.
Вывод тестирования о проблемном сертификате:
ГОСТ Р 34.10-2012 DH 256 битГОСТ Р 34.10-2012 256 бит, параметры ТК-26 АГОСТ Р 34.11-2012 256 битГОСТ 28147-89, параметры шифрования ТК26 Z
Вывод тестирования о любом другом сертификате, вход которого успешен:
ГОСТ Р 34.10-2012 DH 256 битГОСТ Р 34.10-2001, параметры обмена по умолчаниюГОСТ Р 34.11-2012 256 битГОСТ 28147-89, параметры шифрования ТК26 Z Решение: Формировать новый запрос на сертификат, предварительно вернув настройки
«Целостность этого сертификата не гарантирована. Возможно он поврежден или изменен»
Причина: Известная несовместимость при установке на компьютере и криптопровайдера от Кода Безопасности. Решение: Удаление корневого сертификата из всех хранилищ (пользователя, локального компьютера, реестра), удаление проблемных веток реестра:
и последующая переустановка корневых сертификатов.
При подписании в Электронном Бюджете в окне Jinn client не видит сертификаты сформированные по гост 2012.
Причина №1: Наименование организации превышает 127 символов. см. решение №1 Причина №2: Ручная установка расширения eXtendedContainer по инструкции с сайта . К сожалению, в руководстве указан только xc.exe который идет в составе дистрибутива , установка которого нужна только на 32-битных системах. Для установки на 64-битные системы необходимо использовать xc64.exe. см. решение №2 Причина №3: Если eXtendedContainer не был установлен вручную, он будет автоматически установлен при установке Континент ТЛС клиент. Его использование нерекоммендуется, т.к. он вызывает проблемы с отображением сертификатов. см. решение №2
Решение №1: Необходимо с помощью специального инструмента размещенного на сайте конвертировать текущие подписи в формат, понятный Решение №2: Воспользоваться подготовленным нами архивом для удаления старого и установки корректного eXtendedContainer
Ошибка при подписании — «Ошибка целостности файла масок контейнера криптопро»
Причина: Вероятнее всего вы пытаетесь подписывать, выбирая сертификат не с флешки, а из хранилища сертификатов Windows. Это неправильно. Подписывать в Электронном Бюджете следует только с физического носителя: флешки или рутокен.
Решение: При подписании выбирать сертификат с флешки, или, если в окне выбора сертификатов не отображается нужного, ознакомиться с
Как автоматически обновить CRL?
У меня есть следующая проблема: у меня есть самозаверяющий CA (центр сертификации), в основном для личного использования (шифрование и подпись почты, . ). Я создал несколько сертификатов и CRL (которые пока пусты) и опубликовал их все.
Теперь у меня проблема, что я получаю сообщение от kleopatra (менеджер сертификатов X509 под Linux), что CRL устарели и, следовательно, не используются. Кроме того, я предполагаю, что все сертификаты с устаревшим CRL временно отклоняются / аннулируются, пока обновленный CRL не может быть получен по HTTP (в моем случае).
Теперь я хочу знать, как это возможно в профессиональном контексте. Чтобы создать новый CRL с использованием скрипта, я должен был бы поместить незашифрованный (!) закрытый ключ моего корневого CA на рабочий сервер для генерации CRL с использованием скрипта cron. Я не могу поверить, что это необходимо для запуска профессионального центра сертификации, или это так?
Как только возникнет какая-либо проблема на этом сервере, весь корневой сертификат будет скомпрометирован. Это приведет к полной перезагрузке всех сертификатов, и все приложения, установившие этот корневой сертификат, придется изменить вручную. Для (доверенного) корневого сертификата не может быть самого CRL, поэтому мы не можем отозвать его в классическом смысле.