Я создаю центр сертификации для интрасети.
Я создал корневой и промежуточный ЦС и успешно подписал сертификат сервера с помощью промежуточного ЦС. Сертификат сервера имеет CN=mysite.com.
В будущем срок действия этого сертификата сервера истечет, и мне нужно будет выпустить новый. Однако, если я создам еще один CSR с тем же CN=mysite.com тогда, когда я подписываю его, я получаю
failed to update database
TXT_DB error number 2
Эта ошибка исчезнет, если я создам новый CSR с другим CN, но CN должны быть такими же, иначе браузер не скажет, что он действителен, верно?
Как это исправить?
РЕДАКТИРОВАТЬ: я следую это руководство - все в порядке до конца связанной страницы, но когда я пытаюсь повторить шаги на этой странице, чтобы создать второй сертификат, openssl требует, чтобы я дал новому сертификату другой CN.
SUBJ="/C=$C/ST=$ST/L=$L/O=$O/OU=$OU/CN=$CN"
# Generate CSR
echo "$PW" | openssl req \
-config "$CAROOT/intermediate/openssl.cnf" \
-new -sha256 -subj "$SUBJ" -passin stdin \
-key "$PRIV_ENC" -out "$CSR_INT" >/dev/null 2>&1 ||
{
>&2 echo "Could not openssl req";
exit 1;
}
# Sign CSR
openssl ca \
-config "$CAROOT/intermediate/openssl.cnf" \
-batch -extensions server_cert \
-days "$HTTP_DAYS" -notext -md sha256 \
-in "$CSR_INT" -out "$CRT_INT" ||
{
>&2 echo "Could not openssl ca";
exit 1;
}
Это openssl ca который терпит неудачу.
Если вы хотите создать несколько сертификатов с одной и той же темой, вы можете изменить свою конфигурацию следующим образом:
Можно поменять в разделе CA (возможно [CA_default]) в твоем openssl.cnf Настройки
unique_subject = no
Но этот параметр также сохраняется в файле index.txt.attr, вы тоже должны это изменить. Иначе не получится.
Вам нужны дураки? Традиционно браузеры и клиенты требовали, чтобы CommonName поле имя субъекта соответствует имени хоста; современные предпочитают, чтобы запись в SubjectAlternativeName (SAN) расширение Сделай так. Вы можете установить Другой поля отличаться, например
O=Floo Manufacturing, OU=floo server 2016, CN=www.floo.example.com
O=Floo Manufacturing, OU=floo server 2017, CN=www.floo.example.com
и DN субъектов уникальны, хотя CommonName само по себе не является. Или с современными клиентами вы мог ставить www.floo.example.com в SAN и использовать уникальные объекты без CommonName. Но заставить openssl выполнять per-cert SAN немного неудобно; см. например https://security.stackexchange.com/questions/113484/followup-to-one-liner-to-create-cert-request-with-san
Чтобы разрешить обман: официальный способ
В вашем файле конфигурации (который $CAROOT/intermediate/openssl.cnf) перейти в "раздел" (разделенный строками вида [somename] с необязательным пробелом) для вашего ЦС. Поскольку вы не использовали -name в командной строке имя раздела является значением default_ca в [ca] раздел или раздел по умолчанию (вверху перед первым [somename] линия); глядя рядом с вашей ссылкой это вероятно [CA_default]. Добавить строку
unique_subject=no
с интервалом и последующими # comment по желанию. Или, если у вас уже есть строка для этого элемента, измените и / или раскомментируйте ее, но, глядя рядом со своей ссылкой, вы, вероятно, этого не сделаете.
См. Страницу руководства ca(1ssl) в вашей системе или паутина в разделе ОПЦИИ ФАЙЛА КОНФИГУРАЦИИ.
Чтобы разрешить обман: неофициальный способ
Пустой (усечь) настроенный database файл, который обычно index.txt и глядя на вашу ссылку, они, по-видимому, этим пользуются. Или отредактируйте этот файл и удалить строку (и) для предмета (ов), который вы хотите использовать повторно - но в этой ситуации похоже, что у вас есть только один или несколько, и вы хотите повторно использовать его или все из них, поэтому очистить файл проще.