Как проверить TLS-сертификат сервера через OpenSSL?

При подключении к HTTPS-сервису можно получить ошибку проверки сертификата, хотя сам сервер доступен и TCP-соединение устанавливается. Причина может быть в сроке действия сертификата, неправильной цепочке доверия или несовпадении имени сервера.

Для диагностики достаточно стандартной утилиты openssl. Начнём с TLS-подключения:

openssl s_client \
  -connect example.com:443 \
  -servername example.com

Параметр -servername передаёт имя сервера через SNI. Это важно, если на одном IP-адресе размещено несколько HTTPS-сайтов с разными сертификатами.

Посмотреть только основные сведения о сертификате:

openssl s_client \
  -connect example.com:443 \
  -servername example.com </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -dates

В выводе будут указаны владелец сертификата, удостоверяющий центр и период действия.

Проверим имена, на которые выпущен сертификат:

openssl s_client \
  -connect example.com:443 \
  -servername example.com </dev/null 2>/dev/null |
openssl x509 -noout -ext subjectAltName

Для проверки доменного имени используется расширение Subject Alternative Name. Наличие подходящего Common Name само по себе не заменяет корректную проверку SAN современными TLS-клиентами.

Теперь проверим не только сертификат, но и цепочку доверия:

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -verify_hostname example.com \
  -verify_return_error </dev/null

-verify_hostname проверяет соответствие сертификата имени сервера, а -verify_return_error заставляет завершить проверку с ошибкой при обнаружении проблемы в цепочке.

При успешной проверке можно увидеть:

Verification: OK
Verify return code: 0 (ok)

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

Посмотреть все сертификаты, которые сервер отправляет во время TLS handshake:

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts </dev/null

-showcerts показывает сертификаты, переданные сервером, а не обязательно полную доверенную цепочку до корневого CA.

Проверим, не истекает ли сертификат в ближайшие 30 дней:

openssl s_client \
  -connect example.com:443 \
  -servername example.com </dev/null 2>/dev/null |
openssl x509 -checkend 2592000 -noout

2592000 — количество секунд в 30 сутках. Команда завершится с ненулевым кодом, если сертификат истечёт раньше указанного интервала или уже недействителен по сроку. Такую проверку удобно использовать в мониторинге.

Если нужно проверить новый сервер до изменения DNS, можно подключиться напрямую к его IP, сохранив SNI:

openssl s_client \
  -connect 192.0.2.10:443 \
  -servername example.com \
  -verify_hostname example.com \
  -verify_return_error </dev/null

Это позволяет проверить сертификат конкретного узла, не изменяя /etc/hosts и DNS-записи. Отдельно можно проверить согласование TLS 1.3:

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -tls1_3 </dev/null

Если соединение не устанавливается, это не обязательно проблема сертификата: сервер может не поддерживать TLS 1.3 или соединение может блокироваться на другом уровне.

🔥 openssl s_client позволяет проверить TLS handshake, SNI, цепочку сертификатов, соответствие hostname и срок действия сертификата. При диагностике HTTPS важно проверять не только даты сертификата, но и корректность всей цепочки доверия — действующий сертификат сам по себе ещё не гарантирует успешную TLS-аутентификацию.

🚪 Linux Ready | #практика

📂 Шпаргалка по работе SSH в Linux!

Например, при подключении через ssh клиент и сервер обмениваются ключами, устанавливают защищённое соединение и проверяют подлинность друг друга.

На картинке — 20 этапов работы SSH: от установки TCP-соединения и проверки known_hosts до аутентификации по ключам и передачи зашифрованных данных.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Знали, что в Linux можно отключить программе доступ к сети без настройки firewall и изменения её кода?

Для этого есть unshare — утилита, которая создаёт отдельные пространства имён ядра. С флагом --net процесс получает собственный сетевой стек, изолированный от сети хоста.

Например, можно проверить, как приложение ведёт себя без сети:

sudo unshare --net -- ./myapp

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

Можно открыть отдельную оболочку и исследовать окружение:

sudo unshare --net -- bash
ip addr
ip route

По умолчанию даже интерфейс lo в новом пространстве имён не поднят.

Если нужен локальный сетевой обмен внутри него, включите loopback:

sudo unshare --net -- ip link set lo up

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

🔥 unshare --net позволяет за секунды воспроизвести отсутствие сети при тестировании приложений, не отключая интернет на всей машине. Особенно полезно для проверки автономного режима, обработки сетевых ошибок и неожиданных внешних зависимостей.

🚪 Linux Ready | #совет

🧐 Base of Knowledge — большая русскоязычная коллекция заметок, шпаргалок и руководств!

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

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

🤔 Крутая статья попалась на Хабре: «Как ускорить дисковую подсистему с помощью bcachefs»!

В этой статье:
• Узнаете, как объединить быстрый SSD и медленный диск с помощью кэширования в bcachefs;
• Разберёте настройку Write Back и проверку производительности через fio;
• Посмотрите на реальные тесты RocksDB, где кэширование ускорило запись в 3,75 раза, а случайное чтение — в 7,74 раза.

🔊 Продолжай читать на Habr!

🚪 Linux Ready | #статья

Как запустить процесс в отдельном сетевом пространстве Linux?

Иногда требуется проверить работу приложения в изолированном сетевом окружении, не изменяя маршруты, IP-адреса и правила firewall основной системы. Например, запустить сервис без доступа к внешней сети или проверить, как приложение ведёт себя при отсутствии сетевого подключения.

В линукс для этого предусмотрены network namespaces. Каждый такой namespace имеет собственные сетевые интерфейсы, таблицы маршрутизации, сокеты и ряд других сетевых настроек.

Создадим отдельное сетевое пространство:

sudo ip netns add isolated

Проверим список:

ip netns list

В выводе появится:

isolated

Теперь посмотрим сетевые интерфейсы внутри нового namespace:

sudo ip netns exec isolated ip addr

По умолчанию в нём будет только интерфейс lo, который изначально находится в состоянии DOWN.

Включим loopback:

sudo ip netns exec isolated ip link set lo up

После этого проверим его адрес:

sudo ip netns exec isolated ip addr show lo

На интерфейсе обычно уже назначен стандартный адрес 127.0.0.1/8. Включение lo позволяет использовать его для локального сетевого взаимодействия.

Попробуем выполнить запрос во внешнюю сеть:

sudo ip netns exec isolated \
  ping -c 3 1.1.1.1

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

Теперь запустим внутри namespace простой HTTP-сервер. Чтобы не раздавать файлы текущего каталога, создадим отдельный пустой каталог:

mkdir -p /tmp/netns-http

Запустим сервер:

sudo ip netns exec isolated \
  python3 -m http.server 8080 \
  --bind 127.0.0.1 \
  --directory /tmp/netns-http

В другом терминале проверим, что сервер отвечает:

sudo ip netns exec isolated \
  curl -i http://127.0.0.1:8080

Сервер вернёт HTTP-ответ, поскольку клиент и сервер используют одно сетевое пространство. Для пустого каталога это будет страница со списком файлов.

Но если выполнить аналогичный запрос из основной системы:

curl http://127.0.0.1:8080

Подключиться к серверу внутри isolated не получится, если в основном namespace нет собственного listener на этом адресе и порту. Причина в том, что loopback-интерфейсы разных network namespaces независимы друг от друга.

Это позволяет запускать приложения на одинаковых адресах и портах без конфликтов между сетевыми пространствами. Проверим прослушивающие TCP-порты внутри namespace:

sudo ip netns exec isolated ss -tlnp

В выводе будет присутствовать HTTP-сервер, прослушивающий 127.0.0.1:8080.

При этом обычная команда в основной системе:

sudo ss -tlnp

Не покажет этот listener, поскольку ss просматривает сокеты текущего сетевого пространства.

Посмотрим процессы, использующие созданный namespace как основное сетевое пространство:

sudo ip netns pids isolated

Команда выведет их PID, включая процесс HTTP-сервера.

Также можно проверить сетевое пространство конкретного процесса. Подставим PID сервера из предыдущего вывода:

sudo readlink /proc/<PID>/ns/net

В результате получим идентификатор вида:

net:[4026532456]

Число в квадратных скобках идентифицирует объект namespace. У процессов в одном network namespace ссылки /proc/<PID>/ns/net указывают на один и тот же объект.

Для удаления окружения сначала остановим HTTP-сервер через Ctrl+C, затем удалим namespace:

sudo ip netns del isolated

🔥 Удаление имени namespace не завершает автоматически процессы, которые его используют. Само сетевое пространство сохраняется, пока на него существуют ссылки.

🚪 Linux Ready | #практика

В Linux можно диагностировать загрузку динамических библиотек ещё до запуска самой программы!

Если приложение падает с ошибкой cannot open shared object file, проблема часто не в отсутствии библиотеки, а в том, где именно загрузчик её ищет.

У динамического загрузчика Linux есть собственные диагностические возможности:

LD_DEBUG=libs ./myapp

Команда покажет поиск библиотек по каталогам, включая пути из RPATH, RUNPATH, переменных окружения и системных настроек.

А если нужно проверить зависимости без запуска main(), можно вызвать загрузчик напрямую:

/lib64/ld-linux-x86-64.so.2 --list ./myapp

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

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

# Посмотреть диагностические данные загрузчика
/lib64/ld-linux-x86-64.so.2 --list-diagnostics ./myapp

Последняя возможность доступна в glibc начиная с версии 2.33. Путь к загрузчику зависит от архитектуры и дистрибутива, а диагностика LD_DEBUG может быть ограничена для защищённых исполняемых файлов.

🔥 В следующий раз, когда приложение не найдёт .so, не спешите создавать симлинки и менять LD_LIBRARY_PATH. Сначала посмотрите, где загрузчик ищет библиотеку.

🚪 Linux Ready | #совет

📂 Шпаргалка по протоколу NTP!

Например, NTP позволяет синхронизировать системное время компьютеров и серверов, а временные метки T1–T4 помогают рассчитать сетевую задержку и смещение часов.

На картинке — принцип работы NTP, основные формулы, режимы синхронизации и иерархия NTP-серверов.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

В Linux можно найти процессы, использующие конкретный порт или файл, без просмотра полного списка открытых дескрипторов!

Для этого есть fuser из пакета psmisc. Он удобен, когда сервис не запускается из-за занятого порта:

sudo fuser -v -n tcp 8080

Команда покажет процессы, связанные с TCP-портом 8080. А если нужно узнать, кто использует файл или каталог:

sudo fuser -v /var/log/myapp.log

Есть и более интересный сценарий: выяснить, какие процессы мешают размонтировать файловую систему:

sudo fuser -vm /mnt/data

Здесь -m ищет процессы, использующие файлы на той же файловой системе, что и указанный путь. Это полезно при ошибке target is busy.

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

🚪 Linux Ready | #совет