Google скасовує довіру до всіх Entrust сертифікатів SSL

У Google прійняте рішення скасувати довіру до всіх Entrust публічних сертифікатів SSL у веб-переглядачі Chrome після 31 жовтня 2024 року.

Протягом останніх кількох місяців у Entrust виникла низка невідповідних вимог, що призвело до надзвичайно запізнілих відкликань і численних іноді гарячих онлайн-діалогів щодо цих помилок.

У результаті цих і попередніх інцидентів Google Chrome оголосив, що не довіряє публічним кореням Entrust після 31 жовтня 2024 року.

У блозі безпеки Google зазначено: «Протягом останніх шести років ми спостерігали збій у відповідності, недотримання зобов’язань щодо вдосконалення та відсутність відчутного, вимірюваного прогресу у відповідь на публічно оприлюднені звіти про інциденти... довіра Chrome до Entrust більше не виправдовується». Компанії з загальнодоступними сертифікатами SSL Entrust повинні будуть замінити їх, інакше їхні веб-сайти будуть позначені як ненадійні в Chrome. Раніше про недовіру до центру сертифікації Entrust заявила Mozilla

Digicert Code Signing - проблема підпису в застарілих ОС

Проблема

Нещодавня зміна в ієрархії довіри для підпису коду DigiCert призвела до того, що деякі застарілі операційні системи не довіряли правильно підписаному коду та відображали попередження.

Помилка перевірки підпису автентикоду з новою перехресною міткою часу

У червні 2022 року DigiCert представив новий перехресний корінь «DigiCert Trusted Root G4» для вирішення проблем сумісності із застарілими клієнтами з міткою часу. Запровадження перехресного кореня полягало в тому, що сертифікат часової позначки зв’язувався з більш поширеним коренем, який уже був присутній у кореневих сховищах застарілих систем.

У рамках цієї зміни новий крос-корінь включав лише атрибут EKU Time Stamping (1.3.6.1.5.5.7.3.8). Оскільки цей перехресний корінь також використовуватиметься як частина ланцюжка цифрового підпису, Windows не зможе перевірити ланцюжок сертифіката підпису коду через обмежений EKU.

Під час перевірки даних цифрового підпису на застарілих платформах можуть з’явитися помилки, подібні до наведених нижче:

"Сертифікат недійсний для запитаного використання"

"Здається, цей сертифікат недійсний для вибраної мети"

-------------

Рішення

Щоб вирішити цю проблему, DigiCert опублікував новий тимчасовий міжкореневий центр сертифікації. Для використання цього нового ЦС потрібно змінити процес підписання.

Це тимчасовий обхідний шлях для вирішення цієї проблеми, створено ще один крос-корінь спеціально для використання з цифровим підписом. Він містить правильний код підпису (1.3.6.1.5.5.7.3.3) EKU для проходження перевірки підпису Windows.

Ви можете завантажити його тут: digicert-g4-to-haevrca-codesigningcrosscert.crt

CodeSigning Cross Root

Serial: 0fd1bbca796bd7f8dd4c82e10a9a9631

Valid From: Jan 13 00:00:00 2022 GMT

Valid To: Nov 9 23:59:59 2031 GMT

Новий ICA «DigiCert Trusted Root G4» був перехресно підписаний «DigiCert High Assurance EV Root CA» лише з кодовим підписом EKU.

Timestamping Cross Root

Serial: 01240afb1e380b8a16f14b719df4d3c0

Valid From: Jun 9 00:00:00 2022 GMT

Valid To: Nov 9 23:59:59 2031 GMT

Новий ICA «DigiCert Trusted Root G4» був створений і перехресно підписаний «DigiCert Assured ID Root CA» лише з міткою часу EKU.

Підписання коду з новим перехресним підписом проміжного ICA повинно вирішити проблему. Якщо для підпису коду використовується Signtool, передайте параметр /ac у команді підпису:

signtool sign /ac DigiCert-G4-to-HAEVRCA-CodeSigningCrossCert.crt /tr http://timestamp.digicert.com /td sha256 /fd sha256 /a "c:\path\to\file_to_sign.exe"

Переконайтеся, що файл було правильно підписано за допомогою цієї команди: signtool verify /pa signed_file.exe

Джерело: https://knowledge.digicert.com/solution/authenticode-signature-verification-fails-with-new-timestamping-cross-root.html?om_ext_cid=dc_email_7014z000001p3BtAAI_10783&mth=July%2C%202022

Certum блокує РФ

Digicert блокує РФ

SECTIGO блокує РФ

До уваги користовачів сертификатів підпису документів PDF AATL GlobalSign

С 14 октября 2020 года GlobalSign будет использовать новый центр сертификации для сертификатов подписи документов AATL.

Эти изменения вносятся после того, как отрасль центров сертификации была предупреждена о последствиях для соответствия, связанных с отказом от включения выдающих ЦС с поддержкой TLS в соответствующие отчеты аудита, и включение определенного расширения (использование расширенного ключа подписи OCSP) в сертификаты ЦС для определенных условий, непреднамеренном соответствием и последствий для безопасности.

Эта проблема затрагивает также центры сертификации AATL «GlobalSign CA 2 для AATL», «GlobalSign CA 3 для AATL», «GlobalSign CA 4 для AATL» и «GlobalSign CA 6 для AATL».

Обратите внимание, что не было взлома ключа или нарушения безопасности, изменение выполняется исключительно в контексте устранения проблемы соответствия и устранения любого потенциального  риска безопасности.

GlobalSign будет переходить на новый AATL ICA в рамках планов компании по исправлению ситуации в соответствии с базовыми требованиями форума CA / B и GlobalSign CPS.

Если в настоящее время у вас есть какие-либо сертификаты AATL, выпущенные перечисленными выше центрами сертификации AATL, будьте уверены, что на данный момент ваши сертификаты останутся действительными, и любые действия по отзыву в рамках подготовки к событию отзыва 31 декабря 2020 года будут своевременно переданы всем затронутым клиентам.

Примечание. Подписи AATL, применяемые к PDF-файлам, которые включают встроенные проверки отзыва (например, OCSP или CRL, что часто встречается при использовании Adobe Acrobat для подписи), останутся действительными даже после отзыва.

Уведомление для клиентов HSM или приложений для пользовательской подписи:

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

Начиная с 14 октября 2020 г., вам нужно будет установить новый Промежуточный центр сертификации под названием "GlobalSign GCC R6 AATL CA 2020" расположен здесь

Обратите внимание, что новый ICA выдается центром сертификации GlobalSign для AATL - SHA384 - G4 в настоящее время используется для GlobalSign CA 4 для AATL, и поэтому он должен оставаться частью вашей иерархии сертификатов.

Если вы вручную задали URL-адрес OCSP как часть пользовательского приложения или конфигурация системы (вместо использования URL-адреса OCSP, указанного в расширении AIA сертификатов EE), вам также потребуется обновить конфигурацию системы для нового URL-адреса OCSP http: // ocsp.globalsign.com/gsgccr6aatlca2020.

SSL FATCA для українських банків і фінансових установ

1 липня 2014 року набрав чинності Закон Сполучених Штатів Америки «Про податкові вимоги до іноземних рахунків» (далі - FАТСА), що містить вимоги до іноземних фінансових організацій - Інформаційна довідка щодо імплементації положень Закону США «Про податкові вимоги до іноземних рахунків» (FATCA)

Міністерство фінансів України повідомило всіх фінансових агентів України про перенесення у зв’язку з COVID-19 строків подання звітів про підзвітні рахунки в рамках Угоди FATCA за 2019 податковий рік для компетентних органів країн, що звітують за моделлю IGA 1, до яких відноситься і Україна, на період до 31 грудня 2020 року. Ознайомитись з ним можна за посиланням.

Також,  Міністерство фінансів США, листом від 07.08.2020, повідомило, що  термін подання звітів для всіх звітуючих країн, у тому числі для України, подовжено до 31 грудня 2020 року.

Для ДПС України, яка є компетентним органом для цілей автоматичного обміну інформацією в рамках Угоди FATCA,  строки подання до Служби внутрішніх доходів США звітів за 2019 податковий рік подовжено до 31 грудня 2020 року.

Зважаючи на те, що у Кодексі встановлений термін звітності для фінансових агентів, який забезпечує компетентному органу місячний термін для обробки та перевірки наданої інформації, кінцевий строк подання фінансовими агентами звіту про підзвітні рахунки подовжуються до 1 грудня 2020 року. До цієї дати фінансові агенти повинні подати через портал IDES (International data exchange service – Міжнародна служба обміну даними) до ДПС України (центрального органу виконавчої влади, що реалізує державну податкову політику) звіти про підзвітні рахунки за 2019 рік та інформацію, яка стосується звітних періодів з 2014 по 2018 роки, відповідно до положень Угоди FATCA.

Відповідно до зазначеного Порядку заповнення і подання фінансовими агентами звіту про підзвітні рахунки відповідно до Угоди FATCA фінансові агенти подають звіти до ДПС через Міжнародну службу обміну даними (МСОД – платформа IDES). Порядок та методика використання платформи IDES докладно описані в Інструкції користувача (Публікація Служби внутрішніх доходів США 5190 (далі – Публікація СВД 5190).

Порядок та методика використання платформи IDES докладно описані в Інструкції користувача (Публікація Служби внутрішніх доходів США 5190 (далі – Публікація СВД 5190). (переклад українською)

Для підключення до фінансовим агентам необхідно:

• Придбати SSL-сертифікат (типи сертифікатів та центри сертифікації наведено у розділі 3 Публікації СВД 5190 або за посиланням. Подробнее про получение SSL сертификата для Fatca читайте в нашей статье
• мати GIIN (ідентифікаційний номер, що надається Службою внутрішніх доходів США для цілей звітування відповідно до Угоди FATCA).
• Інформація щодо реєстрації для цілей звітування відповідно до Угоди FATCA та одержання коду GIIN розміщена на вебсайті Служби внутрішніх доходів США (https://www.irs.gov/businesses/corporations/fatca-foreign-financial-institution-registration-system).
• здійснити реєстрацію (процедуру реєстрації викладено у розділі 4 Публікації СВД 5190).

Звіти фінансових органів вважаються наданими і отриманими Службою внутрішніх доходів США у день, коли ДПС України підтвердить, і, таким чином, розкриє інформацію у IDES Службі внутрішніх доходів США, а інформація, яка передається Службою внутрішніх доходів США, вважається наданою і отриманою ДПС України у день, коли вона є доступною для завантаження з IDES (розділ 11.6 Публікації СВД 5190).

Всі проблемні питання, пов’язані із FATCA, фінансові агенти можуть направляти на адресу електронної пошти info_FATCA@tax.gov.ua, відповіді на які будуть розміщені на банері «FATCA» https://tax.gov.ua/baneryi/fatca/pitannya-vidpovidi/ або надані безпосередньо особі, яка направила запит електронною поштою.

Джерело

upd 20.11.2020: Перенесення строків звітування про підзвітні рахунки (FATCA)

Листом від 12 листопада 2020 року Служба внутрішніх доходів США повідомила Міністерство фінансів України про перенесення для України строку подання звітів про підзвітні рахунки за звітні періоди з 2014 року по 2019 рік на 30 вересня 2021 року.

Враховуючи зазначене та положення пункту 69.8.3 статті 69 Податкового кодексу України фінансові агенти мають подати до ДПС України через систему IDES звіти про підзвітні рахунки за 2020 рік та інформацію, яка стосується звітних періодів з 2014 по 2019 роки, до 1 вересня 2021 року.

------------

оновлено 19.11.21

Джерело  https://tax.gov.ua/media-tsentr/novini/527408.html

Інформація на сайті міністерства фінансів

Служба внутрішніх доходів США (далі – СВД США) надала інформацію щодо оновлення її цифрового сертифікату. Термін дії цифрового сертифікату FATCA СВД США закінчиться наприкінці грудня 2021 року. Щоб запобігти перериванням у поданні звітів, СВД США буде відкрито новий сертифікат/ключ, доступний для фінансових агентів для завантаження починаючи з 3 грудня 2021 року з 07:00 EST (14:00 за київським часом).

Щоб заявники мали можливість завантажити новий сертифікат, СВД США планує сповістити їх через інформаційний бюлетень FATCA.

Після 3 грудня 2021 року отримані файли звітів з FATCA мають бути закодовані новим відкритим сертифікатом, інакше ці файли створюватимуть помилки на рівні файлу «Помилка перевірки підпису».

Digicert ігнорує поле OU в сертифікатах

31 августа DigiCert прекратили поддержку поля «Организационная единица» (OU), чтобы упростить заказ сертификатов.

Поле OU позволяет хранить дополнительные метаданные в сертификате, однако его предполагаемое назначение крайне ограничено и требует длительной и глубокой проверки со стороны сертификационного центра.

Чтобы избежать путаницы вокруг этого необязательного поля и сократить время проверки, Digicert принял решение удалить его из будущих процессов заказа.

Вскоре поле OU больше не будет отображаться в формах заказов, будет игнорироваться в запросах API и будет удалено во всех новых, обновленных и повторно выпущенных общедоступных сертификатах TLS.

Это изменение не повлияет на ранее выданные сертификаты с действительным полем OU. Это не влияет на частные сертификаты TLS или другие типы сертификатов, отличных от TLS.

До уваги власників 2-річних SSL сертифікатів.

З 27 серпня для діючих дворічних SSL сертифікатів після перевипуску буде скорочуватись термін дії до 397 днів (без відшкодування вартості втраченого терміну). Будьте уважні та не перевидавайте діючі дворічки SSL без необхідності.

Нагадуємо, що з 1 вересня SSL сертифікати видаватимутся виключно терміном дії 1 рік. Сертифікаційні центри припиняються видачу 2-річних сертифікатів невалідованим організаціям з 12 серпня, валідованим 27 серпня.

з 1 вересня 2020 року SSL сертифікати лише на 1 рік

SSL сертифікати тільки на 1 рік

Що це для користувачів сертифікованих веб-сайтів? Що стосується вашого веб-сайту Safari, ви більше не можете публічно надсилати сертифікати TLS, а термін, який потрібно було пройти 398 днів після 30 серпня 2020 року. Будь-які сертифікати, видані до 1 вересня 2020 року, залишаються справді незалежними від терміну дії (до 825 днів). Сертифікати, які використовують не для публічної довіри, все ще можуть бути розпізнані до максимальної терміни, яка вимагає 825 днів.

Чому так сталося.

Як правило, у форумі CA / Browser (CA / B) у Братиславі, Словаччина, Apple оголосила, що з 1 вересня почала використовувати у своєму браузері Safari нові новини, що публікуються публічно, щоб отримати сертифікати TLS, які мають не більше 398 днів. Це супроводжує довгу історію, яка обговорюється у Форумі CA / B, яка працювала над скороченням терміну службового сертифіката та покращувала безпеку, одночасно використовуючи необхідні власні користувачі, переходячи на короткі терміни.

У серпні 2019 року Google представив бюлетень для голосування на форумі CA / B SC22, щоб зменшити терміни сертифікатів TLS до одного року. Організатори розглядали цю пропозицію із своїми власними замовниками та публікували інших користувачів коментарів, які в основному підтримували протидії, а також додавали додаткові результати, необхідні ІТ-команди для скорочення коротких термінів. Будучи не ввімкненим у Форумі, що зазначило, що максимальний термін сертифікатів підтверджувався протягом двох років.

Час від часу можна було отримати сертифікати SSL з максимально можливим терміном три роки. Кілька років тому вони скоро до двох років. Швидкий перехід до цього Apple, який підкреслює те, що не вдалося зробити головному SC22: скоро перевірити сертифікат до одного року.

Чому Apple в односторонньому випадку працювала за короткою терміном, що скорочує термін дії сертифікатів? Їх речник вважає, що це "захищений користувач". З попередньою дискусією Форум CA / B ми знаємо, що довший термін служби сертифікованих довіряє склад у заміні сертифікатів у великих інцидентах, які мають бути впевнені. Apple очевидно хоче використати системи, які не можуть швидко реагувати на основні загрози, представлені сертифікатами. Короткотривалі сертифікати покращують безпеку, при цьому вони зменшують експозицію вікна, і сертифікат TLS надсилається. Також ми підтримуємо нормальне функціонування в організації, використовуючи те, що оновлено ідентифікують, як і колись, і адресу та активні домени. Як і будь-яке, котрий підкреслив, скорочення терміну життя запросив бути суттєво перед твердими, необхідними для користувачів сертифікатів для досить важливих.

Зараз Apple представила свою офіційну інформацію про основні знання про цю тему https://support.apple.com/en-us/HT211025.