Чтобы получить то, что вы показываете, создайте ключевой файл как v1.5, но подпишите сертификат с помощью PSS. Для самоподписанного сертификата:
# in separate steps either of
openssl genrsa 2048 >keyfile
openssl genpkey -algorithm rsa -pkeyopt rsa_keygen_bits:2048 >keyfile
# in either case add encryption if desired; your Q is inconsistent about that
# then
openssl req -new -x509 -key keyfile -sigopt rsa_padding_mode:pss -sha1 -sigopt rsa_pss_saltlen:20 -out certfile
# add options for subject, days, extensions, or other config as desired
# for 1.0.0 & 1.0.1 -sha1 was default for hash and can be omitted;
# in all versions MGF1 hash defaults to data hash
# but saltlen defaults to 0xEA -- I'm not sure why -- and must be set
# in one step
openssl req -new -x509 -newkey rsa:2048 -keyout keyfile -sigopt rsa_padding_mode:pss -sha1 -sigopt rsa_pss_saltlen:20 -out certfile
Тем не менее, я в основном согласен с комментарием Мэтта; это не обязательно то, что вам нужно для подписи TLS1.3 rsa_pss_rsae, если это ваша реальная цель. Во-первых, подпись на самоподписанном root или другом сертификате привязки вообще не способствует безопасности и обычно даже не проверяется; RFC8446 4.2.3 явно разрешает эту подпись не удовлетворять sigalgs. (Хотя я думаю, что это ошибка; учитывая оставшуюся часть spe c, было бы более разумно извинить ее от sigalgs или sigalgs_cert , в зависимости от того, что применимо.)
Второе, если это была подписью, которая имеет значение - для сертификата, выданного (отдельным) CA, что OpenSSL может также сделать, если вы хотите, но по-другому - тогда использование SHA-1 было бы очень плохо. RFC8446 позволяет сигнатурам сертификатов использовать SHA-1 только в качестве крайней меры - для любого алгоритма publickey (RSAv1.5, RSA-PSS, ECDSA, EdDSA) - и некоторые реализации не доверяют сертификатам, использующим их когда-либо после 'разбитых' и теперь 'рухнувших' (подробности смотрите в Google, или посмотрите crypto.SX и security.SX).