Tls certificate changed ошибка

Когда дело доходит до SSL/TLS-сертификатов, вы можете столкнуться с множеством проблем, некоторые из которых связаны с браузером или проблемой в серверной части веб-сайта.

Одной из таких ошибок является «Недопустимый сертификат TLS» в Linux.

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

В моем случае я заметил проблему при добавлении репозитория Flathub через терминал, шаг, который позволяет вам получить доступ к огромной коллекции Flatpak, когда настройка Flatpak.

Однако вы также можете столкнуться с этой ошибкой при установке приложения Flatpak или использовании ref-файла Flatpak из стороннего репозитория через терминал.

Некоторые пользователи заметили эту проблему при использовании рекомендованной их организацией службы VPN для работы в Linux.

Итак, как это исправить? Почему это проблема?

Ну, технически это одна из двух вещей:

• Ваша система не принимает сертификат (и сообщает, что он недействителен).
• Сертификат не соответствует домену, к которому подключается пользователь.

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

Но если это первое, у вас есть несколько способов справиться с этим.

1. Исправьте «Недопустимый сертификат TLS» при использовании Flatpak или добавлении онлайн-аккаунтов GNOME.

Если вы пытаетесь добавить пульт Flathub или новое приложение Flatpak и замечаете ошибку в терминале, вы можете просто ввести:

sudo apt install --reinstall ca-certificates

Это должно переустановить доверенные сертификаты ЦС на случай, если какая-то проблема со списком возникла.

В моем случае при попытке добавить репозиторий Flathub я столкнулся с ошибкой, которая была устранена путем ввода вышеуказанной команды в терминале.

Итак, я думаю, что любые проблемы, связанные с Flatpak с сертификатами TLS, можно исправить с помощью этого метода.

2. Исправьте «Недопустимый сертификат TLS» при использовании Work VPN.

Если вы используете VPN вашей организации для доступа к материалам, связанным с работой, вам может потребоваться добавить сертификат в список доверенных центров сертификации в вашем дистрибутиве Linux.

Обратите внимание, что вам нужно, чтобы служба VPN или администратор вашей организации предоставили общий доступ к версии корневого сертификата .CRT, чтобы начать работу.

Далее вам нужно будет пройти свой путь к /usr/local/share/ca-сертификаты каталог.

Вы можете создать в нем каталог и использовать любое имя для идентификации сертификата вашей организации. Затем добавьте файл .CRT в этот каталог.

Например, это usr/local/share/ca-certificates/organization/xyz.crt.

Обратите внимание, что вам нужны привилегии root для добавления сертификатов или создания каталога под CA-сертификаты каталог.

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

sudo update-ca-certificates

И ваша система должна считать сертификат действительным всякий раз, когда вы пытаетесь подключиться к VPN вашей компании.

Подводя итог

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

Если ошибку не удается устранить двумя из этих способов, возможно, домен/служба, к которым вы подключаетесь, имеет ошибку конфигурации. В этом случае вам придется связаться с ними, чтобы решить проблему.

Вы когда-нибудь сталкивались с этой ошибкой? Как ты это починил? Известны ли вам другие решения этой проблемы (возможно, что-то, за чем легко следовать)? Дайте мне знать ваши мысли в комментариях ниже.

Оригинал статьи

Ошибки браузера и предупреждения

Слишком часто при доступе к веб-сайтам встречаются такие сообщения об ошибках браузера:

Эти сообщения обычно начинаются с жирного заголовка, в котором говорится, что Ваше соединение не является частным or Предупреждение: потенциальная угроза безопасности впереди. Эти сообщения могут расстраивать пользователей и владельцев веб-сайтов, особенно когда владелец приложил усилия для защиты своего веб-сайта с помощью SSL /TLS сертификат. Часто эти ошибки вызваны неправильной конфигурацией сервера, которую легко исправить, если вы знаете основную причину. В этом руководстве мы рассмотрим некоторые распространенные ошибки в конфигурации и связанные с ними сообщения об ошибках в различных веб-браузерах. Для создания этих снимков экрана использовались следующие браузеры:

• Google Chrome 76.0.3809.100 (macOS 10.14.6)
• Firefox 68.0.1 (macOS 10.14.6)
• Safari 12.1.2 (macOS 10.14.6)
• Edge 44.17763.1.0 (Windows 10 Корпоративная)
• Internet Explorer 11.379.11763.0 (Windows 10 Корпоративная)

Ситуации, которые мы рассмотрим, подробно описаны в содержании ниже.

Сертификат с истекшим сроком действия

В этих случаях на сервере установлен сертификат, который истек срок действия и нуждается в замене:

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

Доменное имя не соответствует сертификату

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

Решение: Убедитесь, что распространенное имя и / или альтернативное имя субъекта указанное в сертификате соответствует доменному имени веб-сайта.

Неполная цепь доверия

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

Решение: Убедитесь, что на вашем сервере установлена ​​полная цепочка сертификатов. Пожалуйста, смотрите наш статья о диагностике и устранении этой проблемы чтобы получить больше информации.

Аннулированный сертификат

Иногда из-за компрометации сервера или проблем с соответствием сертификаты должны быть отозваны до истечения запланированного срока их действия (например, см. серийный номер энтропии выпуск начала 2019 года). Невозможность заменить отозванный сертификат приведет к следующим сообщениям об ошибках:

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

Мы надеемся, что это руководство было полезно для того, чтобы помочь вам расшифровать (иногда загадочные) сообщения об ошибках, выдаваемые веб-браузерами, когда они сталкиваются с проблемным SSL /TLS монтаж. Если у вас есть какие-либо вопросы, пожалуйста, свяжитесь с нами по электронной почте на Support@SSL.com, вызов 1-877-SSL-SECURE, или просто нажмите ссылку чата в правом нижнем углу этой страницы. Вы также можете найти ответы на многие распространенные вопросы поддержки в нашем база знаний. Спасибо, что выбрали SSL.com!

Windows 10, version 1903, all editions Windows 10, version 1809, all editions Windows Server 2019, all editions Windows 10, version 1803, all editions Windows 10, version 1709, all editions Windows 10, version 1703, all editions Windows 10, version 1607, all editions Windows Server 2016, all editions Windows 10 Windows 8.1 Windows Server 2012 R2 Windows Server 2012 Windows 7 Service Pack 1 Windows Server 2008 R2 Windows Server 2008 Service Pack 2 Windows Embedded 8 Standard Windows Embedded Standard 7 Service Pack 1 Windows Embedded POSReady 7 Еще…Меньше

Первоначально разработанный для браузеров, SSL/TLS-протокол позже стал стандартом де-факто вообще для всех защищенных интернет-коммуникаций. Сейчас он используется для удаленного администрирования виртуальной инфра­структуры, развернутой в облаке, для передачи платежных реквизитов покупателя от серверов электронной коммерции к платежным процессорам, таким как PayPal и Amazon, для пересылки локальных данных в облачное хранилище, сохранения переписки в мессенджерах и аутентификации серверов в мобильных приложениях iOS и Android.

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

SSL/TLS-протокол: хотели как лучше…

В теории, защищённое SSL/TLS-протоколом соединение должно обеспечивать конфиденциальность, достоверность и целостность коммуникаций клиентского и серверного софта, – даже в условиях присутствия активного продвинутого злоумышленника из сети: когда сеть полностью захвачена врагом, DNS отравлен, а точки доступа и маршрутизаторы, коммутаторы и WiFi контролируются злоумышленником; злоумышленником, который помимо всего прочего контролирует SSL/TLS-бэкэнд. Кроме того, когда клиентский софт пытается подключиться к законному серверу, – злоумышленник может подменить сетевой адрес сервера (например, через отравление DNS), и вместо законного сервера, перенаправить клиента на свой злонамеренный сервер.

Безопасность коммуникаций в таких суровых условиях, как известно, целиком зависит от адекватности проверки криптографического сертификата, предоставленного сервером при установке соединения. В том числе от адекватности реализации набора шифров (ciphersuite), которыми клиент и сервер пользуются при обмене данными. Для того чтобы SSL/TLS-соединение было полностью безопасным, клиентский софт, в числе прочего, должен тщательно удостовериться, что:

• сертификат выдан действующим органом сертификации;
• срок его действия не истёк (или сертификат не был отозван);
• в списке перечисленных в сертификате имён присутствует тот домен, к которому производится подключение.

…а получилось как всегда: примеры провальной проверки SSL/TLS-сертификата

Однако во многих приложениях и библиотеках, для которых безопасность коммуникаций очень критична, процедура проверки SSL/TLS-сертификата, – и даже EV-SSL, сертификата с расширенной проверкой [4], – полностью провальная. Во всех популярных операционных системах: Linux, Windows, Android и iOS. Среди уязвимого софта, библиотек и middleware-сервисов можно выделить следующие [1]:

• Amazon’овская Java-библиотека EC2 и все облачные фронтэнд-клиенты построенные на её основе.
• Amazon’овский и PayPal’овский торговый SDK, ответственный за доставку платёжных реквизитов от сайтов (на которых развёрнута инфраструктура онлайн-коммерции) к платёжным шлюзам.
• Интегрированные «корзины», такие как osCommerce, ZenCart, Ubercart и PrestaShop, которые не проверяют сертификаты вообще.
• AdMob-код используемый мобильным софтом для показа контекстной рекламы.
• Интерфейсные фронтэнд-компоненты ElephantDrive и FilesAnywhere, ответственные за взаимодействие с облачным хранилищем.
• Android’ная библиотека Pusher и весь софт, который использует Pusher API для управления обменом мгновенными сообщениями (например, GitHub’овский Gaug.es).
• Apache HttpClient (версия 3.x); Apache Libcloud; и все клиентские подключения к серверам Apache ActiveMQ и т.п.
• SOAP middleware-сервисы Java, в том числе Apache Axis, Axis 2, Codehaus XFire; а также весь софт, который на базе этих middleware-сервисов построен.
• API-инструменты Elastic Load Balancing.
• Weberknecht-реализация WebSockets’ов.
• А также весь мобильный софт, построенный на базе перечисленных выше библиотек и middleware-сервисов (чтобы понять, что такое middleware-сервисы, смотри рис. 1); в том числе iOS-клиент хостинг-провайдера Rackspace.

Рисунок 1. Что такое middleware-сервисы

Кроме того, в [2] перечислено ещё больше сотни уязвимых мобильных приложений (см. рис. 2). В том числе: Android’s Google Cloud Messaging, Angie’s List Business Center Passwords, AT&T Global Network Client, CapitalOne Spark Pay, Cisco OnPlus (remote access), Cisco Technical Support, Cisco Webex, Cisco WebEx Passwords, Dominos Pizza, E-Trade, Freelancer, Google Earth, Huntington Mobile (Bank), Intuit Tax Online Accountant, iTunes Connect, Microsoft Skype, Oracle Now, Pinterest, SafeNet (VPN client), SouthWest Airlines, Uber, US Bank – Access Online, WesternUnion, WordPress, Yahoo! Finance, Yahoo! Mail.

Рисунок 2. Небольшая выборка из списка уязвимых мобильных приложений

Логические уязвимости SSL/TLS-протокола

SSL/TLS-соединения всего этого и многого другого софта уязвимы для широкого спектра MiTM-атак. При этом, MiTM-атаку можно провести, зачастую, даже без подделки сертификатов и без похищения приватных ключей, которыми серверы подписывают свои сертификаты. MiTM-атаку можно провести – просто эксплуатируя логические уязвимости, которые присутствуют в процедуре проверки SSL/TLS-сертификата на стороне клиентского софта. В результате MiTM-злоумышленник может, например, собирать токены авторизации, номера кредитных карт, имена, адреса и т.п. – у любого продавца, который использует уязвимые веб-приложения обработки платежей.

Поставщики мобильного софта, которые берут за основу сэмпл-код AdMob для связи своих приложений с AdMob-аккаунтом, тоже уязвимы, – они позволяют атакующему захватывать учётные данные, и получать доступ ко всем его Google-сервисам. К примеру, из-за некорректной проверки сертификатов в таких мессенджерах как Trillian и AIM, MiTM-злоумышленник может похитить учётные данные для входа ко всем сервисам Google (включая Gmail), Yahoo!; и также к сервисам Windows Live (в т.ч. SkyDrive). Среди других уязвимостей, которыми страдает современный небраузерный веб-софт: использование неправильных регулярных выражений при сравнении имени хоста; игнорирование результатов проверки корректности сертификата; случайное или преднамеренное отключение проверки. [1]

Другие распространённые уязвимости реализации SSL/TLS-протокола

Ну и конечно же нельзя забывать о том, что даже если в реализации SSL/TLS-протокола нет логических ошибок (если конечно кто-то в это ещё верит), то защиту можно обойти посредством похищения приватного ключа [12], посредством применения 0day-эксплойтов к таким вещам как клавиатуры, браузеры, операционные системы, утилиты и прошивки [3]; посредством компрометации BGP-маршрутизации [10]; или атаковать SSL/TLS по аппаратным (см. рис. 3) [8] и/или программным [9] обходным каналам.

Рисунок 3. Атака на SSL по аппаратным обходным каналам

Кроме того, злоумышленники могут выполнять практически невидимые MiTM-атаки, злоупотребляя механизмом кэширования SSL/TLS-сеансов, реализованным в классе SSLSessionCache. Этот механизм проверяет достоверность сертификатов только при первоначальном соединении; и при этом не способен должным образом аннулировать сеанс связи после удаления сертификатов с устройства. Кроме того, после перезагрузки Android-устройства (через опции «Перезапуск» или «Отключить питание») можно продолжать видеть зашифрованный трафик некоторых приложений, которые после перезагрузки не запускались, но до перезагрузки работали. Так например с Google Maps происходит. В [2] описано, как благодаря этим недочётам кэширования, злоумышленник может совершенно прозрачно для пользователя устанавливать и удалять «невидимые сертификаты», и затем устанавливать сетевое соединение с любым приложением.

Рисунок 4. Ретроспектива уязвимого шифрования

Среди других распространённых уязвимостей реализации SSL/TLS-протокола можно отметить уязвимое шифрование (см. рис. 4) [5], повторное использования GCM (Galois/Counter Mode; счётчик с аутентификацией Галуа) [6], хитрость с CNG (CryptoAPI-NG) в Schannel (см. рис. 5) [7], некорректную проверку цепочки доверия [2], некорректную проверка имени хоста [11].

Рисунок 5. Хитрость с CNG: вытягиваем секреты из Schannel

Некорректная проверка цепочки доверия представляет собой ситуацию, когда веб-приложение принимает абсолютно любой сертификат, в котором указано корректное имя хоста, не проверяя при этом каким центром сертификации он был подписан. Это позволяет перехватывать и дешифровывать пароли и/или номера кредитных карт. А в некоторых случаях даже делать инъекцию вредоносного кода. В Android-софт данная уязвимость проникает, например когда создаётся кастомизированный X509TrustManger-интерфейс, который игнорирует исключения CertificateException. Или когда разработчик софта вставляет в код WebViews-компонента вызов метода SslErrorHandler.proceed(). [2]

Некорректная проверка имени хоста представляет собой ситуацию, когда веб-приложение принимает сертификат, не удостоверившись в том, что хост, с которого этот сертификат пришёл, присутствует в списке доверенных хостов. В Android-софт данная уязвимость проникает, например когда создаётся HostnameVerifier-интерфейс, который при любых условиях возвращает TRUE. Или когда разработчик софта в вставляет в код WebViews-компонента вызов метода SslErrorHandler.proceed(). [2]

Коренная причина существования уязвимостей в SSL/TLS-протоколе

Коренная причина существования подавляющего большинства перечисленных уязвимостей – ужасный API-дизайн SSL/TLS-библиотек (в том числе JSSE, OpenSSL, и GnuTLS). А также не менее ужасный дизайн библиотек передачи данных (таких как cURL, Apache HttpClient и urllib), каждая из которых представляет собой высокоуровневую обёртку для SSL/TLS-библиотек. Не говоря уже о middleware-сервисах (таких как Apache Axis, Axis 2, или Codehaus XFire), которые ещё более высокоуровневой обёрткой являются, и которые увеличивают «снежный ком» ужасного дизайна ещё больше. Вместо того чтобы вести с прикладным разработчиком (зачастую далёким от системного программирования) диалог на понятном ему языке (в терминах конфиденциальности и аутентификации), абстрагировано от низкоуровневых подробностей реализации SSL/TLS-протокола, эти API вываливают на бедолагу кучу низкоуровневых SSL/TLS-параметров, непонятных ему. Требуют от высокоуровневого софта, чтобы он правильно выставлял низкоуровневые опции; реализовывал функции проверки имени хоста и заботился об интерпретации возвращаемых низкоуровневыми операциями значений.

В результате, прикладные разработчики используют SSL/TLS API неправильно: ошибочно интерпретируют многообразие их параметров, опций, побочных эффектов и возвращаемых значений. Например [1]:

• Amazon’овская PHP-библиотека Flexible Payments Service пытается включить проверку имени хоста – посредством установки параметра CURLOPT_SSL_VERIFYHOST в значение TRUE (в cURL-библиотеке). Однако корректное значение по умолчанию для этого параметра – 2; если же присвоить ему значение TRUE, то этому параметру незаметно для разработчика присваивается значение 1, и т.о. проверка сертификата отключается.
• PHP-библиотека PayPal Payments Standard – приобрела ту же самую ошибку; причём в тот момент, когда предыдущая, уязвимая, реализация обновлялась (т.е. одну ошибку убрали, другую добавили).
• Другой пример – это Lynx, тексто-ориентированный браузер. Он проверяет самоподписанные сертификаты, – но только в том случае, если GnuTLS’ная функция проверки сертификата возвращает отрицательное значение. Однако эта самая функция для некоторых ошибок возвращает 0; в том числе в тех случаях, когда сертификаты подписаны недоверенным органом. Из-за этого цепочка проверки доверия в Lynx – нарушена.

Кроме того, прикладные разработчики зачастую неправильно понимают, какие именно гарантии безопасности предоставляет та или иная SSL/TLS-библиотека. Поэтому в дикой природе можно встретить клинические случаи, когда в приложениях, принципиально нуждающихся в защищённых коммуникациях (например, взаимодействующих с платёжным процессором), используется SSL/TLS-библиотека, которая не проверяет SSL/TLS-сертификаты вообще. Более прозаичные, но ещё более убийственные случаи – это когда разработчик какого-нибудь из промежуточных слоёв софта молча отключает процедуру проверки SSL/TLS-сертификатов (он это может сделать, например, для тестирования системы, а после тестирования – забыть вновь включить её). При этом высокоуровневый программный код, использующий этот промежуточный слой, уверен, что проверка сертификатов производится. Т.о. ошибки SSL/TLS часто бывают скрыты в глубине одного или сразу нескольких промежуточных слоёв-библиотек – из-за чего обнаружить данную проблему становится практически невозможно.

Например, в JSSE (Java Secure Socket Extension) расширенный интерфейс SSLSocketFactory API – молча пропускает проверку имени хоста, если поле «algorithm» в SSL-клиенте установлено в NULL или в пустую строку, – а не в HTTPS. Хотя данное обстоятельство упоминается в справочном руководстве JSSE, многие Java-реализации SSL-протоколов используют SSLSocketFactory без выполнения проверки имени хоста…

Ложка мёда в бочку дёгтя

Т.о., по факту получается, что в большинстве современного небраузерного веб-софта проверка SSL/TLS-сертификатов либо отключена совсем, либо реализована неправильно. На рисунке 7 представлена классификация актуальных уязвимостей SSL/TLS-протокола. Некоторые из этих уязвимостей, но не все, были описаны и/или упомянуты выше. Ознакомиться с упомянутыми, но неописанными уязвимостями – можно почитав материалы, перечисленные в библиографии.

Рисунок 6. Классификация актуальных для SSL/TLS уязвимостей

Ну и чтобы добавить ложку мёда в бочку дёгтя, стоит отметить, что в [1] подробно/понятно/популярно/грамотно описано, как SSL реализовываться должен, со ссылкой на RFC. Лучшего описания, которое бы технически точным и одновременно понятным было, мы не встречали. Также в [1] разбираются самые распространённые SSL-библиотеки, с классификацией по уровню абстрагирования (низкоуровневые/высокоуровневые). Всё с диаграммами и лаконичными алгоритмами в псевдокоде. Подробно уязвимости конкретных продуктов описаны, с приведением программного кода некорректного, и указанием ошибок. Так что если вдруг у кого-то в очередной раз возникнет желание создать такую реализацию SSL/TLS-фреймворка, которая станет исключением из поговорки «хотели как лучше, а получилось как всегда», то [1] – идеальное для этого начало.

If your website is showing Invalid TLS/SSL certificate error, your mind may be going through a lot of questions.

You may be thinking about what does invalid certificate means, whether my site has been hacked, what did I do wrong, and how to fix this issue at the earliest.

Most of the time this error appears right after you install your new SSL certificate, so it’s easy to be terrified by it. But don’t worry, it’s not something that can’t be fixed. It can be fixed through a proper procedure, and in this article, we’ll explain how do you fix “the certificate for this server is invalid” error.

Let’s get started!

What does invalid TLS/SSL Certfcate error mean?

Before we go through fixing the Invalid TLS/SSL Certificate error, let’s take a quick look at what it means and when it is shown.

The invalid certificate error is shown when your browser fails to validate your certificate.

A failure in validation essentially means that your business’s identity remains unverified, which is equal to not having any SSL certificate installed at all.

Now let’s check the reasons behind it, and how you can fix it.

Reasons of Invalid TLS/SSL Certificate Error

There can be a variety of reasons behind the display of invalid TLS/SSL error for your site in the browser. Here they’re:

Misconfiguration of certificate

One of the most common reasons behind a TLS/SSL error is misconfiguration of your certificate during installation. If you have made any mistake during the certificate’s installation, there is no way for the browser to verify your business identity properly.

Domain mismatch

If there is a mismatch in your site’s domain and the domain for which certificate has been issued, there will be an error in verification, and the browser will show a TLS/SSL error.

Break in the chain of trust

If the certificate’s chain of trust is broken, it’ll inevitably lead to TLS/SSL error. The break-in chain of trust happens when the identity of the certificate issuer can’t be verified either due to the expiry of its certificate or due to any other reason.

Incorrect date/time on your computer

TLS/SSL certificates are issued for a year (or more). If the date and time is not correct on your computer/device, it won’t fall into the validity period for which the certificate has been issued. As a result, the verification will fail and an error message will be shown.

Broken certificate structure

If the structure of your TLS/SSL certificate is broken, that too may be a reason behind the invalid certificate error. There are many ways in which the structure of your certificate may be broken, the most common among them being an invalid digital signature.

Only SHA-1

If your certificate uses only the Secure Hash Algorithm 1 hash function, then it may be flagged as invalid by the browser as this hashing algorithm is quite outdated.

Certificate revoked

Finally, it’s also possible that your certificate might have been revoked because you acquired it by providing false information or because of any accidental misrepresentation from your end. If that’s the case, you’ll also be notified about the revocation by your CA.

Now let’s see how you can fix this invalid SSL certificate error.

How to Solve the Invalid SSL /TLS Certificate Error

Fixing invalid TLS/SSL error requires identifying what’s wrong with your certificate and then taking steps to fix it. Here’s a step by step procedure to do so:

1. Check the date on your computer

First of all you should check if the date and time on your computer is correct. If it’s not, you should fix it. Most of the time this can fix the issue. If the issue still persists, you should try loading your site on other devices to check if it’s opening fine or giving the same error. If it’s returning the same error, then you can proceed with other steps given below.

2. Check for configuration errors

The next step is to check if you did something wrong during the installation of the certificate. This can be done with help of this online tool called “Why No Padlock”. The tool checks your site’s SSL installation for common certificate installation mistakes and tells what’s wrong with the installation that’s preventing your site from showing that much needed gray padlock of SSL security. It also provides you tips on how the error can be fixed.

3. Check for domain mismatch

You should check the domain for which the certificate has been issued. If it has been issued for a domain that doesn’t match with yours, you should get a new certificate issued for your domain to fix that nasty invalid security certificate error. You can check this guide to solve it.

4. Get your certificate from a reliable CA

You should get your SSL certificate from a reliable certifying authority like Comodo, Symantec, Thawte, GeoTrust, DigiCert etc. Certificates from less reputed CAs or self-signed certificates carry a higher risk of breaking the chain of trust.

5. Check the certificate structure

You can check the structure of your certificate by opening it with the help of Windows Explorer. Just click the ‘Not secure’ label showing before your site URL in the address bar, and from the pop-up that comes next click on the “Certificate” option. This will open the certificate in a dialogue box-like window, which will have 3 tabs. You can click the “Certification Path” tab to check the structure of your certificate. If a cross mark is showing on any level of a certification path, the problem lies with that part of your certificate structure and the solution is to get a new certificate issued by your CA.

6. Check for revocation

Finally, if none of the above-given steps fixes the error for you, then you should check if the issuer has revoked your certificate.

7. This can be checked by going through your emails, or by logging in to your account on the site from where you purchased your certificate.

Conclusion

An invalid SSL certificate can be one of the costliest things for your business. With its scary warning messages showing in the browser, it can make people run away from your site like nothing else. Therefore, you should fix it at the earliest. And hopefully, you’ll not have any trouble fixing it now when we’ve provided you all the necessary information required to fix it. If you still have any questions, feel free to ask in the comments and we’ll try to answer them soon.

При посещении веб-сайта с установленным сертификатом безопасности (для шифрования данных по протоколам SSL/TLS), который браузер не может проверить, выдаются следующие предупреждения:

Internet Explorer:

«Сертификат безопасности этого веб-узла не был выпущен доверенным центром сертификации». 

Firefox 3:

«(Имя сайта) использует недействительный сертификат безопасности. К сертификату нет доверия, так как сертификат его издателя неизвестен». Или: «(Имя сайта) использует недействительный сертификат безопасности. К сертификату нет доверия, так как он является самоподписанным».

Давайте разберемся, почему браузеры так реагируют на некоторые сертификаты и как от избавиться от этой ошибки.

Почему возникает ошибка SSL?

Браузеры обычно разрабатываются с уже встроенным списком доверенных поставщиков SSL сертификатов. К таким относятся всем известные компании Comodo, Thawte, Geotrust, Symantec, RapidSSL, GlobalSign и некоторые другие.

Тем не менее многие поставщики SSL сертификатов в этих списках отсутствуют, так как далеко не у всех есть договоренности с разработчиками веб-браузеров. При открытии сайта с SSL сертификатом, выданным одним из таких поставщиков, браузер выдает предупреждение, что Центр сертификации (ЦС), выдавший SSL сертификат, не является доверенным. То же происходит, когда на сайте установлен самоподписанный SSL сертификат. Internet Explorer выдает довольно общее предупреждение, тогда как Firefox 3 различает SSL сертификаты, выданные самим сервером (самоподписанные SSL сертификаты), и другие виды недоверенных сертификатов.

Если Вы купили SSL сертификат у нас и после его установки возникает такая ошибка, Вы можете устранить ее, следуя инструкциям ниже. Нет необходимости устанавливать дополнительное ПО на клиентские устройства и приложения, чтобы устранить ошибку с доверенным SSL сертификатом. Первое, что следует сделать, это найти причину ошибки SSL с помощью тестера SSL сертификатов. Перейдя по ссылке, Вы можете ввести Ваш домен и запустить проверку SSL сертификата. Если присутствует ошибка SSL о недоверенном сертификате, сервис об этом сообщит. Он различает два типа ошибок:

Самоподписанные SSL сертификаты

Возможной причиной подобной ошибки SSL может быть установленный на сервере самоподписанный SSL сертификат. Браузеры не принимают самоподписанные сертификаты, потому что они сгенерированы Вашим сервером, а не независимым центром сертификации. Чтобы определить, является ли Ваш SSL сертификат самоподписанным, посмотрите с помощью вышеназванного тестера, указан ли центр сертификации в поле Issuer. В случае самоподписанного SSL, в этой графе указывается название Вашего сервера и далее написано «Self-signed».

Решение: Купить SSL сертификат от доверенного центра сертификации.

Если после установки доверенного SSL сертификата на Вашем сервере нашелся самоподписанный, мы рекомендуем пересмотреть инструкции по установке и убедится, что Вы выполнили все нужные шаги.

Ошибка в установке SSL сертификата

Наиболее распространенной причиной ошибки типа «к сертификату нет доверия» — это неверная установка SSL на сервер (или серверы), на котором размещен сайт. С помощью все того же тестера SSL сертификатов Вы можете проверить, в этом ли причина проблемы. В блоке Certification Paths перечислены промежуточные и корневые сертификаты, установленные на Вашем сервере. Если в этом блоке указано «Path #X: Not trusted», значит у Вас ошибка в установке SSL сертификата и клиенту не удалось установить издателя Вашего SSL сертификата.

Решение: Чтобы устранить эту ошибку SSL, установите файл промежуточного сертификата на сервер, следуя инструкциям по установке для Вашего сервера. Промежуточные и корневые сертификаты Вы можете скачать в личном кабинете, вместе с Вашим основным SSL сертификатом.

После установки сертификата дополнительно убедитесь, что установка была произведена правильно. Если нужно, перезагрузите сервер.

Другие сообщения браузеров об ошибке SSL

Ниже приведены еще несколько предупреждающих сообщений, выдаваемых различными браузерами. Internet Explorer 6: 

«Информация, которой Вы обмениваетесь с этим сайтом, не может быть просмотрена или изменена другими. Тем не менее, имеются замечания по сертификату безопасности сайта. Сертификат безопасности выдан компанией, не входящей в состав доверенных. Просмотрите сертификат, чтобы определить, следует ли доверять центру сертификации. Хотите продолжить?»

Internet Explorer 7: 

«Сертификат безопасности этого веб-узла не был выпущен доверенным центром сертификации. Наличие ошибок в сертификате безопасности может означать, что вас пытаются обмануть или хотят перехватить информацию, передаваемую на сервер».

Когда дело доходит до SSL/TLS-сертификатов, вы можете столкнуться с множеством проблем, некоторые из которых связаны с браузером или проблемой в серверной части веб-сайта.

Одной из таких ошибок является «Недопустимый сертификат TLS» в Linux.

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

Когда вы сталкиваетесь с этой проблемой сертификата TLS?

В моем случае я заметил проблему при добавлении репозитория Flathub через терминал, шаг, который позволяет вам получить доступ к огромной коллекции Flatpak, когда настройка Flatpak.

Однако вы также можете столкнуться с этой ошибкой при установке приложения Flatpak или использовании ref-файла Flatpak из стороннего репозитория через терминал.

Некоторые пользователи заметили эту проблему при использовании рекомендованной их организацией службы VPN для работы в Linux.

Итак, как это исправить? Почему это проблема?

Ну, технически это одна из двух вещей:

• Ваша система не принимает сертификат (и сообщает, что он недействителен).
• Сертификат не соответствует домену, к которому подключается пользователь.

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

Но если это первое, у вас есть несколько способов справиться с этим.

1. Исправьте «Недопустимый сертификат TLS» при использовании Flatpak или добавлении онлайн-аккаунтов GNOME.

Если вы пытаетесь добавить пульт Flathub или новое приложение Flatpak и замечаете ошибку в терминале, вы можете просто ввести:

sudo apt install --reinstall ca-certificates

Это должно переустановить доверенные сертификаты ЦС на случай, если какая-то проблема со списком возникла.

В моем случае при попытке добавить репозиторий Flathub я столкнулся с ошибкой, которая была устранена путем ввода вышеуказанной команды в терминале.

Итак, я думаю, что любые проблемы, связанные с Flatpak с сертификатами TLS, можно исправить с помощью этого метода.

2. Исправление «Недопустимый сертификат TLS» при использовании Work VPN

Если вы используете VPN вашей организации для доступа к материалам, связанным с работой, возможно, вам придется добавить сертификат в список доверенных центров сертификации в вашем дистрибутиве Linux.

Обратите внимание, что вам нужно, чтобы служба VPN или администратор вашей организации предоставили общий доступ к .CRT-версии корневого сертификата, чтобы начать работу.

Далее вам нужно будет пройти свой путь к /usr/local/share/ca-certificates каталог.

Вы можете создать в нем каталог и использовать любое имя для идентификации сертификата вашей организации. Затем добавьте файл .CRT в этот каталог.

Например, это usr/local/share/ca-certificates/organization/xyz.crt.

Обратите внимание, что вам нужны привилегии root для добавления сертификатов или создания каталога под ca-сертификаты каталог.

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

sudo update-ca-сертификаты

И ваша система должна считать сертификат действительным всякий раз, когда вы пытаетесь подключиться к VPN вашей компании.

Подведение итогов

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

Если ошибку не удается устранить двумя из этих способов, возможно, домен/служба, к которым вы подключаетесь, имеет ошибку конфигурации. В этом случае вам придется связаться с ними, чтобы решить проблему.

Вы когда-нибудь сталкивались с этой ошибкой? Как ты это починил? Известны ли вам другие решения этой проблемы (возможно, что-то, за чем легко следовать)? Дайте мне знать ваши мысли в комментариях ниже.