Easy-RSA index.txt, серийный номер и дубликаты

У нас более 700 сертификатов ... более половины сгенерированных сертификатов имеют идентичный серийный номер ... исходный index.txt содержит только половину всех сертификатов (последняя половина), не включая предыдущие.

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

Если вы хотите получить более подробный обзор выдачи сертификата в частной PKI, см. Как вы подписываете запрос на подпись сертификата с вашим центром сертификации? Здесь объясняется, как вы будете делать все вручную, если Easy- RSA не делала этого за вас.

Другой важный документ - RFC 4158, Internet X.509 Public Key Infrastructure: Certification Path Building . Это __ __ документ, в котором объясняется, что такое совпадения и как можно использовать кортежи, такие как {отличительное имя эмитента, серийный номер} или {отличительное имя субъекта, идентификатор открытого ключа} для сравнения двух сертификатов на эквивалентность. OpenSSL использует этот документ для сопоставления. Также см. Раздел 3.5.15, «Сопоставление отличительного имени (DN) конечной точки» и раздел 3.5.12, «Сопоставление идентификаторов ключей (KID)» .

Серийные номера должны быть уникальными. Это проблема, которую нужно преодолеть. Отличительные имена субъектов (DN) - это совсем другая история. Если ваш openssl.cnf имеет unique_subject = yes , то они не могут быть дублированы. Если unique_subject = no , то DN могут быть дублированы.

Я думаю, вам нужно сделать несколько вещей. Во-первых, используйте современную или обновленную версию утилит OpenSSL. Здесь «современный» означает одну из более поздних версий 1.0.2 или 1.1.0. В предыдущих версиях утилиты возникали небольшие проблемы с сопоставлением имен и серийных номеров.

Во-вторых, проверьте свой файл конфигурации (обычно openssl.cnf , но вы можете использовать другой, возможно, скопированный файл с -config filename ) и запишите соответствующие настройки, например serial.txt и unique_subject = no . Я считаю, что это релевантные из [CA_Default] из openssl.cnf :

base_dir       = .
certificate    = $base_dir/cacert.pem  # The CA certifcate
private_key    = $base_dir/cakey.pem   # The CA private key
new_certs_dir  = $base_dir             # Location for new certs after signing
database       = $base_dir/index.txt   # Database index file
serial         = $base_dir/serial.txt  # The current serial number
unique_subject = no                    # Allow reuse of subjects

В-третьих, сделайте резервную копию всего, особенно таких важных вещей, как index.txt и serial.txt .

В-четвертых, создайте список сертификатов, которые вы хотите отозвать. В списке могут быть записи вроде имен файлов - john-doe-vpn.pem . Если хотите, переместите их в отдельную папку. Желательно, чтобы каждый из них имел уникальный серийный номер и ДОЛЖЕН иметь одно и то же имя эмитента; функции openssl ca и ocsp не могут одновременно обрабатывать более одного эмитента, хотя для протокола OCSP это возможно.

В-пятых, создайте новый index.txt , содержащий строку для каждого серийного номера.Один из подходов состоит в том, чтобы извлечь тему, серийный номер и срок действия из каждого файла сертификата, как в опубликованном вами сценарии, хотя вы можете свернуть большую часть работы оболочки в один openssl и один awk для каждого сертификата:

for f in *files*; do 
  openssl x509 -noout -enddate -serial -subject -in $f \
  | awk 'BEGIN{FS="=";OFS="\t"} /^serial/{num=$2} /^subject/{sub=$2} 
      /^notAfter/{split($2,a,/ /);mon=index(months,a[1])/3+1;day=a[2]...exp=sprintf(...)}
      END{print "V",exp,"",num,sub}' >>index.txt
done

Если это сложно (надежно) заранее удалите повторяющиеся серийные номера, вы можете вставить все, а затем удалить дубликаты с помощью awk -F '\ t' '! already [$ 4] ++' или sort -t $ '\ t' -k4,4 -u или аналогичный.

Другой подход, доступный в версии 1.0.2, но задокументированный только в 1.1.0, заключается в использовании openssl ca [-config conffile] -valid certfile для автоматического извлечения. Но -valid излишне загружает закрытый ключ CA каждый раз, поэтому, если ваш закрытый ключ зашифрован паролем, что является хорошей практикой, это будет означать ввод пароля снова и снова; чтобы сэкономить время, временно замените реальный ключ CA и сертификат на царапинный незашифрованный ключ и соответствующий, но в остальном поддельный (возможно, самоподписанный) сертификат. -valid не будет записывать повторяющуюся серийную запись, поэтому вам не нужно беспокоиться об их исключении или удалении.

Поместите в файл с серийным номером значение, которое является по крайней мере наибольшим значением любого ранее выданного сертификата; если вы хотите перейти к следующему 10000 или 1000000 или как-то еще, чтобы быть в безопасности и, возможно, также более понятным, это нормально. На этом этапе вам может потребоваться установить unique_subject = no .

В-шестых, пометьте каждый сертификат (серийный) в файле индекса как отозванный.Вы можете циклически просматривать файлы сертификатов, используя openssl ca -revoke для каждого, но проще использовать awk, например:

awk -F'\t' -vOFS='\t' '{$1="R"; $3="161101000000Z"}' <index.txt >temp && mv temp index.txt
# if you want, you can add a comma and a reason, see man ca or 
# online at https://www.openssl.org/docs/manmaster/man1/ca.html
# under -crl_reason. But there isn't a code for 'CA stupid', and 
# in practice the reason doesn't really matter to reliers except 
# you should't use hold or remove (latter noted in the man) 

В-седьмых, сгенерируйте CRL из этого индекса с помощью ] openssl ca -gencrl [-crldays n] [-out file] и / или настроить ответчик OCSP, используя его, если (любой из) старые сертификаты указали расширение OCSP.

В-восьмых, как только вы распространите CRL и / или запустите (новый) респондент OCSP, все сертификаты с затронутыми серийными номерами отозваны, и при их использовании (и правильной проверке) связь будет прервана. Если какие-либо из дублированных серийных номеров есть в сертификатах, которые все еще используются в ваших системах, они должны быть сначала заменены. Если у вас все еще есть файлы запросов (CSR) из систем, использующих затронутые сертификаты, вы можете просто повторно выпустить openssl ca [-config conffile] [-in reqfile | -infiles reqfile ...] и отправить новые сертификаты в соответствующие системы, и операторы этих систем установят их. В противном случае вам нужно сначала, чтобы оператор каждой системы отправил вам CSR, который может быть тем, который они использовали ранее (и сохранили), или новым, который они сгенерировали.

Наконец, восстановите все «хорошие» записи (серийные номера, которые вы не отозвали) из старого файла index , объединив с любыми новыми записями для заменяющих сертификатов, выданных в пункте 8 чуть выше. Если вы используете респондент OCSP (см. Выше), вы также должны сохранить отозванные записи; это не важно, но, наверное, проще. Не не восстанавливайте старое значение на серийный , если оно ниже, чем наивысший старый сертификат или наивысший новый заменяющий сертификат, вместо этого позвольте ему продолжать увеличиваться с новое значение.

Относительно цикла for и печати дат:

hour=substr($3,1,2) ;
minutes=substr($3,4,2);
seconds=substr($3,7,2);
printf "%02d%02d%02d%02d%02d%02dZ", year, month, day, hour, minutes, seconds}'`

Даже не беспокойтесь о датах. Если срок их действия истек, их нельзя использовать, если ваша PKI работает правильно. Если от этого вам станет легче, удалите закрытый ключ, связанный с сертификатом и открытым ключом.

Все, что вас интересует, - это список сертификатов, которые нужно отозвать, их серийный номер и отличительное имя. Здесь ваш список будет состоять из таких сертификатов, как: (1) увольняющийся сотрудник, у которого есть сертификат с истекшим сроком действия и закрытый ключ (т.е. сотрудник уходит на пенсию или увольняется); (2) сотрудник, потерявший устройство (т. Е. Закрытый ключ отсутствует); и т.д.

Другой вариант, который у вас есть ... Сжечь существующую PKI до основания и начать заново. В этом случае шаг (1) - отозвать корневой CA и все промежуточные / подчиненные CA. Затем выбросьте закрытый ключ. Шаг (2) - создание нового корневого центра сертификации, выпуск новых промежуточных / подчиненных центров сертификации и, наконец, выпуск новых сертификатов конечных объектов. На шаге (2) вы даже можете танцевать вечеринку с автографами.

Вы не поверите, но OpenStack использует эту стратегию (или рассматривал возможность ее использования). Это своего рода «эфемерная PKI», которая должна оставаться достаточно долго, чтобы удовлетворить ваши потребности; а затем быть отброшенным, когда что-то пойдет не так.

Чтобы посмеяться, вы можете почитать книгу Питера Гутманна Инженерная безопасность . Он безжалостен, когда дело касается PKI и публичных центров сертификации.