RedFirefly

1. У тебя должна быть включена виртуализация в процессоре
2. В компонентах нужно включить "Подсистема Windows для Linux" и "Платформа Виртуальных Машин". Можно через консоль:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

(желательно перезагрузиться)
3. Установить обновление для ядра: https://wslstorestorage.blob.core.windows.net/wslb...
(желательно перезагрузиться)
4. wsl --set-default-version 2
5. Дальше любым желаемым способом устанавливаешь нужный тебе образ.
Взято из вот этого мануала: https://learn.microsoft.com/ru-ru/windows/wsl/inst...

В корневые нужно пихать только сертификат ЦА. Это контейнер для них.

Самоподписанный сертификат - это другое. Это когда у вас нет ЦА и вы просто выпускаете сертификат сервера и он сам себя подписывает. Такой простейший вариант сертификата.

Сертификат ЦА - самоподписанный, т.к. его никто не подписывавет, но используете вы сертификат сервера и возможно клиента, а эти оба сертификата подписываются ЦА и они не самоподписанные. В работе используется сертификат ЦА только для проверки подписи предоставленного сертификата сервера и/или клиента, дальше для всего используются серверный и клиентский сертификаты.
Не знаю особенностей Jitsi Meet, но по ссылке нет самоподписанных сертификатов. Там упор делается на использование LetsEncrypt, но по большому счету разницы нет - используете ли вы ЦА от LetsEncrypt или свой собственный. В случае своего ЦА , вы должны обеспечить возможность проверки сертификатов, правильно установив сертификат ЦА, тогда как сертификат LetsEncrypt (и других известных публичных ЦА) обычно уже установлен в системе. Процесс контроля за сроком сертификатов, их перевыпуском, ведением списка отозванных сертификатов и его доступностью то же ложится на вас.

Любой сертификат содержит в себе публичный ключ владельца сертификата. Вторая часть ключа - секретный ключ - идет в отдельном файле. Серктеный ключ ЦА должен находится только на самом ЦА, он требуется только для выпуска новых клиентских сертификатов. В остальных случаях используется только сертификат ЦА, который можно свободно распространять. Аналогично и секретные ключи сервера/клиента - они должны находиться только у владельца ключа.

Если развертывается свой CA, то в винде к контейнер "Доверенные корневые..." помещается сертификат этого CA. После этого все сертификаты, выпущенные в этом CA (и в его подчиненных CA, буде есть такие) - станут валидными.
Для линуха скопировать сертификат в /etc/ssl/certs (или куда настроено в openssl) может быть недостаточно, нужно линк создавать.
Насчет именри в сертификате - для веб-сервисов проверяется поле CN, в нем должно быть совпадающее имя.

Какой сертификат здесь имеется в виду?

Сертификат сервиса. Корневой должен находиться в /etc/ssl/certs

В Вашем случае ca.crt это RootCA который надо поместить в хранилище доверенных (корневых) ЦС. hostname1.crt это сертификат сервера. В хранилище доверенных его помещять не надо. Если он будет использоваться на ОС Windows его надо поместить в локальное хранилище сертификатов (машинное) вместе с закрытым ключом.

Есть какой-нибудь список?

Есть (вкладка "Сведения о пакете")

они будут заменять это KB2928120 или нет?

последняя замена - KB5012626, 04 2022 г.
самая ранняя доступная замена - KB4580345, 10 2020 г.
для х86 аналогично все...

Можно ли задать адрес локальной сети в филиале 192.168.1.0?

Можно. Но не нужно. Единственная известная мне причина, когда сеть настоятельно пытаются растянуть на L2 - это наличие софта с артефактами, например поиска компьютера сугубо по Netbios-имени (которое не работает ни через что, а работает только в пределах L2-сети). Попытка упростить себе администрирование приведет к его фантастическому усложнению.

Обычная схема построения VPN - это центр, к которому подключаются удаленные узлы. Маршрутизацию осуществляет центр. У центра своя подсеть, у узлов своя - у каждого узла своя. dhcp раздается узлом (теоретически dhcp можно пробрасывать с помощью dhcp realy, но при этом заметно страдает надежность - упал туннель - в филиале пропала сеть). Локальный DNS раздается центром, хотя при приличной нагрузке на узле обычно на узел ставят подчиненный сервер, на котором подымают дубли сервисов - dns, ad и прочее - чтобы не бегали юзера за аутентификацией на каждый чих в центр.

Можно ли задать адрес локальной сети в филиале 192.168.1.0?

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

Так что лучше сети не объединять (в смысле ответа на второй вопрос) и использовать маршрутизацию вместо бриджа.
А значит, если вы в сети филиала будете использовать ту же подсеть, то получите кучу проблем с маршрутизацией, которые придется как-то решать.
Что бы в принципе избежать проблем - используйте другую подсеть.