Не удается сгенерировать сертификат на стороне клиента после создания собственного центра сертификации
Нет, anacron нельзя использовать для планирования заданий для выполнения в такое точное время. Его лучше всего использовать, чтобы убедиться, что, например, сценарий обслуживания запускается с приблизительной частотой, например, ежедневно, еженедельно или ежемесячно. Его временное разрешение не ниже одного дня.
Лично я запускаю anacron из @hourly и @reboot задания cron (на моем компьютере OpenBSD, который не работает круглосуточно) , и он выполняет ежедневные, еженедельные и ежемесячные задачи, если эти задачи необходимо выполнять:
@hourly /usr/local/sbin/anacron -s
@reboot /usr/local/sbin/anacron -s
anacrontab :
SHELL=/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin
HOME=/var/log
1 1 cron.daily /bin/sh /etc/daily
7 3 cron.weekly /bin/sh /etc/weekly
28 5 cron.monthly /bin/sh /etc/monthly
Некоторые версии anacron , кажется, понимают ] @daily , @weekly и @monthly (я использую версию 2.4.3, а его руководство anacrontab не ] упоминают эти заполнители, но этот упоминает).Однако мне не удалось найти никаких реализаций anacron , которые поддерживают использование @hourly .
Однако, если вы запускаете anacron ежечасно, как я, и если одно из его заданий требует выполнения, то это задание будет выполняться в час , то есть примерно в 08 : 00, а не 08:33. Но он не будет запускаться ежечасно .
Согласно учебнику,Я должен быть в состоянии изменить общее имя во время этого процесса
Этот учебник говорит вам сгенерировать новый ключ с openssl genrsa И новый CSR с openssl req -new И создать сертификат из CSR с помощью openssl ca.
(Хотя, как и слишком многие люди, он ошибочно говорит, что сертификат создается путем «подписи КСО». ЦС не подписывает CSR.
ЦС подписывает сертификат, который создает частично основан на КСО, но отличается от КСО. /rant)
При создании нового CSR вы указываете имя субъекта, включая, но не ограничиваясь общим именем, которые, как говорится, должны отличаться от сертификатов ЦС над ним, и должны отличаться от других сертификатов EE, чтобы избежать путаницы.
openssl ca может фактически переопределить имя субъекта для выданного сертификата (полное имя, а не общее имя по отдельности),Но это приведет к получению сертификатов с разными именами для одного и того же ключа, что в лучшем случае излишне запутанно.
и, как правило, менее безопасны (хотя вы не заботитесь об этой части, другие делают, поэтому это нелегко).
Ошибка Загрузка расширения в разделе usr-crt
... нет значения ... имя=email_in_dn
Может ли это исходить из вышестоящего файла по умолчанию ...
Не напрямую. openssl ca -config xxx использует xxx и только xxx в качестве конфигурационного файла. Если файл является производным от upstream, нужное имя раздела —usr_cert, как вы, по-видимому, обнаружили, но вам не нужно указывать usr_cert, поскольку оно используется по умолчанию. Сообщение об ошибке о email_in_dn просто осталось в стеке ошибок, и единственной реальной ошибкой была usr-crt; как только вы исправите, что -noemailDN не нужен, хотя вы можете захотеть это в любом случае.
Имеет ли это какое-то отношение к subjectNameAlt?
Предполагая, что вы имеете в виду unique_subject, нет. subjectAltName (не subjectNameAlt) aka SAN является распространенным
, которое задает альтернативные имена для субъекта,
но unique_subject относится только к базовому Поле субъекта, а не к san.
Сертификат на стороне клиента для установки в браузере, который будет получать доступ к Интернету через прокси
Чтобы было ясно, сертификат клиента, подобный этому, полезен только для аутентификации себя на прокси-сервере. Вы не можете использовать сертификат в клиенте / браузере для аутентификации в чем-либо в Интернете через ЛЮБОЙ HTTPS MitM, и вы не можете использовать сертификат клиента, который вы выдаете сами, для аутентификации в чужих системах в Интернете.
Ошибка TXT_DB номер 2 означает DB_ERROR_INDEX_CLASH.
Вы дважды пытались отправить сертификат в базу данных OpenSSL CA с тем же индексом.
Причиной этого обычно является отправка сертификата в базу данных, содержащего тот же серийный номер или такое же общее имя. Для последнего проверьте параметр unique_subject в файле intermediate / openssl.conf , о котором вы можете прочитать в man ca .
Общее имя для сертификата клиента может быть любым - например, вашим именем.
Общее имя будет указано в файле intermediate / openssl.conf . Его можно настроить для запроса значений или чтения значений из файла конфигурации. Это контролируется опцией prompt , о которой вы можете прочитать в man req .