Роман

Должен ли корневой сертификат (CompanyName Root CA) иметь ссылки на crl и ocsp?
Ответ: Корневой самоподписанный сертификат не должен содержать ссылок на crl и ocsp

А вот что касается любого (ну почти любого) подчиненного сертификата - в нем д.б. ссылка на crl. Ссылка на ocsp - опционально, по Вашему желанию или требованию информационной системы (ИС).
Соответственно, как в сертификатах подчиненных УЦ (Проекта 1, Проекта 2, VPN и т.д.) обязательно должна быть ссылка на crl. Уже не говоря о клиентских сертификатах, выпущенных УЦами Проекта 1, Проекта 2, VPN и т.д.

Ссылка на crl в сертификатах УЦов Проекта 1, Проекта 2, VPN и т.д. будет одна и та же и будет содержать список отзыва, выпускаемый Корневым УЦ. С помощтю этого СОС можно управлять сер-тами подчиненных УЦ.

В сер-тах, выпускаемых УЦами Проекта 1, Проекта 2, VPN и т.д. будет содержаться ссылка на crl, соответствующий каждый определенному УЦ и управлять отзывом сер-тов клиентов можно с каждого подчиненного УЦ, на котором сер-т этого клиента был выпущен.

Не совсем понятно, что означает фраза "получить доступ к CompanyName Project 2 CA по сер-ту, выпущенному на УЦ CompanyName Security CA".
Судя по всему ответ "нет" - получить доступ к CompanyName Project 2 CA по сер-ту, выпущенному из под CompanyName Security CA, не получится.

Что же касается ИС, в которых используются сертификаты, то реализация функции доверия этой ИС к сер-ту целиком и полностью ложится на плечи разработчика ИС и ее архитектуры.
Самый простой способ ограничить использование сер-тов выпущенных только CompanyName Project 2 CA - это установить корневой сер-т CompanyName Project 2 CA в систему и проверять эту цепочку. При этом сер-т CompanyName Security CA в ИС должен отсутствовать

cryptcp -creatrqst p20.der -provtype 75 -cont Petrov20 -dn "T=Руководитель,OID.1.2.840.113549.1.9.2=INN=0123456789/KPP=123456789/OGRN=0123456789123,CN=Петров Петр Петрович,OU=Тестовое подразделение,O=""ООО """"Тестовая организация"""""",L=Краснодар,S=23 Краснодарский край,C=RU,E=test@test.ru,ИНН=001234567890,ОГРН=0123456789123,СНИЛС=12345678901" -certusage "1.2.643.1.1,1.2.643.1.2,1.2.643.1.3.1,1.2.643.1.4.5,1.2.643.1.5,1.2.643.1.6" -both -ku -provname "Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider"

Я не знаю точно про LDAP, но Вы описали SugarCRM — все, требуемое Вами он умеет.
Плюс у него есть еще один жирный плюс — он очень распространен, а поэтому, соответственно, по нему как минимум есть документация (в том числе и на русском), а как максимум — ее много… + сообщества разные и т.д. и т.п.