Alexey Dmitriev

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

Первый подход:
1. Положить их в любую директорию на хосте.
2. Примонтировать эту директорию внутрь контейнера в docker-compose.yaml.
3. Использовать сертификаты в настройках вебсервера внутри контейнера, обслуживающего nextcloud (по умолчанию там apache).
Второй подход:
1. Перенести nextcloud на порт 8080\8443.
2. Закрыть их файрволом снаружи.
3. Установить на хост nginx.
4. Настроить nginx reverse proxy с сертификатами на проксирование до nextcloud.

Вариант того, что если сертификат отозван, то он действительно отозван - не рассматривается я так понимаю? :-)
Уверены, что это один и тот же сертификат на проблемной машине и остальных? Thumbprint сравнивали?
Вангую, что на проблемную машину не прилетают обновления\не установилось обновление корневых сертификатов, а на остальные остановилось.

Вопрос конечно странный, попахивает приличной паранойей.
Но если у вас закрыт 80 порт, значит он не используется и вам стоит убрать то, что его использует и открыть, чтобы Lest Encrypt мог сам поднимать на нем временный веб сервер для валидации своих сертификатов.
Это можно сделать - если вам действительно важно использовать http-01 challenge для подтверждения.
НО у LE есть и другие способы валидации, не требующие 80 порта.

Клиент должен доверять корневому центру сертификации, подписавшему сертификат на сервере. Либо иметь опцию игнорировать проверку и принимать любые сертификаты.
Private key никогда и никому не отдается.

Есть готовый образец конфигов
https://github.com/XTLS/Xray-examples/tree/main/VL...

Нужно определить, что у вас слушает на порту 8888 (например ss -tnlp) и добавить сертификат в настройки этого самого, что слушает.

1. Корневой и выпускающий сертификаты должны быть установлены в хранилища ОС на всех машинах, включая веб серверы.
2. Если конвертируете сертификат в PEM для apache\nginx и т.п., используйте полную цепочку, то есть добавляйте в файл сертификата и корневой с выпускающим сертификаты.
3. Проверьте, что CRL доступны и не просрочены.
Если эти три условия соблюдены, остальные ошибки уже на уровне ошибок при выпуске конкретного сертификата.

Браузеры могут пользоваться системным хранилищем сертификатом и своим строенным, а могут только своим встроенным. Можно отключить в настройках браузера использование системного хранилища и пользоваться только своим, добавив\удалив в нем то, что нужно.

Нет не будет. Wild card только для *.Domain.Com

Смотреть логи, включать вывод ошибок php

Установите в ОС, где размещен ваш почтовый сервер, корневой и выпускающие сертификаты Минцифры

Создайте OU "Non_Trusted_Computers", переопределите Computers на этот OU через redircmp, создайте политику GPO, которая будет запрещать все, что вы хотите запретить и примените ее к OU "Non_Trusted_Computers".

Нужно использовать пакетную базу дистрибутива для установки ПО, пока это возможно.
Удалите все, что наустанавливали и
apt update
apt remove python-is-python2 python2
apt install python3
apt install certbot python3-certbot-nginx

IIS использует сертификаты, находящиеся в хранилище сертификатов Windows. Если вы добавили сертификат в соответствующую папку в хранилище, он будет доступен в выпадающем меню настроек Bindings дла сайта или сервера.

Nginx или haproxy

P.S. Нужно уметь их устанавливать и настраивать.

P.P.S. "Software" - это не пункт для выбора, а заголовок поля выбора.

вставить содержимое трех файлов в один fullchain.pem в текстовом редакторе.
В файле будет три блока
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

Вам нужно обеспечить доступ certbot к директории .well-known/acme-challenge
Он сам создаст нужный файлик и удалит за собой. Данные генерируются уникально при каждом запуске certbot.
Если у вас с этим проблемы - используйте другой метод проверки например dns-01

P.S. в настройках веб сервера можно прописать Directory (apache) или location (nginx) .well-known, которая будет смотреть в доступное для certbot место.