Починка цепочки сертификатов — порядок и полнота связки SSL

Потому что сервер не отдаёт промежуточный сертификат. Настольные браузеры это скрывают: они кэшируют промежуточные, встреченные на других сайтах, и умеют скачать недостающий по адресу из сертификата. Android, curl, Java, Python и большинство API-клиентов не делают ни того, ни другого — они видят цепочку, не доходящую до доверенного корня, и разрывают соединение. Вставьте цепочку сюда: если написано, что промежуточного нет, — это и есть вся причина.

Сначала серверный, затем выпустивший его промежуточный, затем издатель этого промежуточного и так далее. Корень не включается. Часть серверов терпит другой порядок, но OpenSSL, Java и большинство балансировщиков — нет, поэтому безопасный ответ всегда «сначала конечный».

Нет. Клиент доверяет корню потому, что тот лежит в его собственном хранилище, а не потому, что его прислал сервер, — так что корень по сети игнорируется и лишь добавляет килобайт-другой к каждому рукопожатию. Вреда нет, но и смысла тоже; файл, который делает этот инструмент, его не содержит.

У удостоверяющего центра, на той же странице, где вы забирали свой сертификат. Пользователи Let's Encrypt обычно с этим не сталкиваются: certbot пишет fullchain.pem, где промежуточный уже есть, — и если в конфигурации указан cert.pem вместо fullchain.pem, достаточно поменять путь.

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