CityCat4

Что-то мне подсказывает, что Вы получаете результатом выполнения Вашей команды - CSR, а вовсе не сертификат :) Откройте файл сертификата текстовым редактором - что видите? вот так
-----BEGIN CERTIFICATE REQUEST-----
или вот так
-----BEGIN CERTIFICATE-----?

С openssl. Боюсь, что его просто выпилили оттуда. libcurl по-моему не содержит криптопримитивы - если их нет в openssl - то их нет.

man pkg-config

В указанном файле не сертификат, а что-то другое - CRL, CSR, ключ или вообще произвольная фигня

Нет. - OV - это специально проверенный сертификат (документы у юрика запрашивают, все такое, обратный контрольный звонок...). Ни физически, ни логически - вообще никак не отличается от DV - информация о том, что он OV -хранится в CA.

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

Была книжка, там в начале как раз про создание и настройку CA, не все правда, написано, только основные моменты.

Размыто все и непонятно потому что МММ - Мы Можем Многое. Ну в смысле реально там можно многое :)

Что за сертификаты будут выпускаться? Какая будет информация в Subject? Какой срок действия? Будет ли использоваться CDP? AIA? Будет ли выпускаться PKCS#12 или же так передаваться? Допустимо ли наличие в базе двух сертификатов с одинаковым Subject? Какая информация будет необходимой для Subject (без нее будет в выпуске отказано).

Бездна вопросов :) Если что - мыло в профиле, но отвечаю не сразу

Ну вообще-то система пятилетней давности и вовсе ничего нет удивительного, что обновление openssl потащило за собой столько обновлений других вещей.
И обновляться конечно же надо. Но сначала нужен бэкап всего и вся, потому что:
- такое обновление наверняка сломается на половине
- даже если не сломается, вовсе не факт, что все заработает как должно

Как из чего сервер генерирует новые сертификаты для пользователей который посещают определенную веб сайт

Никак и ни из чего. Сертификат, который предоставляет сайт - его заранее получил и настроил админ сайта. Сервер не может ничего никому генерить - у него обычный клиентский сертификат. Если же Вы ему сами создали сертификат, позволяющий что-то генерить - такому сертификату никто не будет верить.

Да-да, все PKI - оно про доверие :) Мы безусловно доверяем всем корневым центрам, но самопальному сертификату не поверит никто.

Создать - никак.

Можно купить или получить бесплатно.

Купить: Thawte, Comodo, GlobalSign
Бесплатно: Let's Encrypt

Статью по iptables порекомендовать? :) Запросто - Вот

UPD: Не задавайте два вопроса в одном.

Для бампинга нужна достаточно специфичная конфигурация squid, которая позволяет писать лог так же, как это было без https.

dhparam генерит стартовое число Диффи-Хеллмана для SSL, к сертификатам это имеет опосредованное отношение. Оно нужно для предотвращения атаки понижения стойкости стартового числа, поскольку стандартные стартовые числа хорошо известны, можно вынудить систему перейти на нестойкое число и провести атаку

Ну, способы есть, но гарантии - нуль.

- Найти репу, где лежит собранный под el6 openssl. Для этого надо, чтобы нашелся кто-то, кому он понадобился и этот "кто-то" захотел собрать пакет как минимум.
- Взять исходники и собрать вручную. Это путь мазохиста, потому что в el6 не только openssl старый - там все примерно возраста ведра 2.6 (а чего хотели-то?). То есть придется собрать и все зависимости, какие он захочет.

Читать про режим бампинга в squid, который собственно говоря этим и занимается - врезается в соединение между клиентом и сервером, чтобы узнать, куда на самом деле пошел клиент.

Если ЕСИА принимает какие попало сертификаты - сгенерить. Про то, как сгенерить самоподписанный серттификат, написаны тонны макулатуры. Если принимает только государственные - получить его у государства, вестимо.

UPD Просто так тему сертификатов не одолеть, гуглите больше

Когда я реализовывал прокси с бампингом и использованием собственного CA (да, у нас тоже СA двухуровневый) - то пришлось в систему поставить оба сертификата - и корневого CA и промежуточного - и именно в корневые, пока промежуточный стоял в "Промежуточные CA" - нифига доверия не было.

В клиентских запросах нет атрибутов политик применения. Они появляются в сертификате после его выпуска. Если СА Ваш - используйте нужный шаблон или создайте новый, в котором будет указано нужное число политик.
CSR содержит практически только данные для Subject, которые вписываются в сертификат.
Вот его примерное содержание:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=RU, ST=*** region, L=***, O=*** Ltd, OU=***, CN=***/emailAddress=certmgr@***.ru
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                ...
                Exponent: 65537 (0x10001)
        Attributes:
        Requested Extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: 
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Subject Alternative Name: 
                email:certmgr@***.ru, URI:http://***.ru
    Signature Algorithm: sha256WithRSAEncryption

Там где звездочки понятно будут другие данные, может вообще не быть

Гуглу может и получится загнать - если это конечно реально ценная уязвимость. А прочие - придут и сами забесплатно заберут