openssl req -x509 -days 365 -newkey rsa: 2048 -keyout /etc/ssl/apache.key -out /etc/ssl/apache.crt
Вы не можете использовать эту команду для генерации правильно сформированного сертификата X.509. Это будет неправильно сформировано, потому что имя хоста помещено в Общее имя (CN) . Размещение имени хоста или IP-адреса в CN осуждается как IETF (большинство инструментов, например, wgetи curl), так и форумами CA / B (CA и браузеры).
Согласно форумам IETF и CA / B, имена серверов и IP-адреса всегда указываются в дополнительном имени субъекта (SAN) . Правила см. В документе RFC 5280, профиле сертификата и списка отзыва сертификатов (CRL) инфраструктуры открытого ключа Internet X.509 и базовых требованиях к форуму CA / Browser .
Вам в основном нужно использовать файл конфигурации OpenSSL и адаптировать его под свои нужды. Ниже приведен пример того, что я использую. Он вызывается example-com.confи передается команде OpenSSL через -config example-com.conf.
Также заметьте : все машины утверждают, что localhost, localhost.localdomainи т.д. Будьте осторожны , о выдаче сертификатов на localhost. Я не говорю, не делай этого; просто поймите, что есть некоторые риски.
Альтернативы localhost: (1) запустить DNS и выдать сертификаты для DNS-имени машины. Или (2) использовать статический IP-адрес и включать статический IP-адрес.
Браузеры по-прежнему будут предупреждать вас о самозаверяющем сертификате, который не связывается с доверенным корнем. Такие инструменты, как curlи wgetне будут жаловаться, но вы все равно должны доверять себе, подписав с опцией, как cURL --cafile. Чтобы преодолеть проблему доверия браузера, вы должны стать вашим собственным центром сертификации.
«Стать вашим собственным ЦС» известно как запуск частного PKI. Там не так много для этого. Вы можете делать все, что может делать Public CA Разница лишь в том, что вам нужно будет установить свой сертификат корневого центра сертификации в разных магазинах. Это ничем не отличается от, скажем, использования cURL cacerts.pm. cacerts.pmэто просто коллекция Root CA, и теперь вы вступили в клуб.
Если вы стали вашим собственным центром сертификации, то обязательно запишите свой закрытый ключ корневого центра сертификации на диск и держите его в автономном режиме. Затем вставьте его в привод CD / DVD, когда вам нужно подписать запрос на подпись. Теперь вы выдаете сертификаты точно так же, как Public CA.
После подписания одного или двух запросов на подпись все это будет очень сложно. Я годами управлял частной ИПК в доме. Все мои устройства и устройства доверяют моему CA.
Для получения дополнительной информации о том, как стать вашим собственным центром сертификации, см. Как подписать запрос на подпись сертификата в вашем центре сертификации и Как создать самозаверяющий сертификат с помощью openssl? ,
Из комментариев в файле конфигурации ниже ...
Самоподписанный (обратите внимание на добавление -x509)
openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.cert.pem
Запрос на подпись (обратите внимание на отсутствие -x509)
openssl req -config example-com.conf -new -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.req.pem
Распечатать самоподписанный
openssl x509 -in example-com.cert.pem -text -noout
Распечатать запрос на подпись
openssl req -in example-com.req.pem -text -noout
Файл конфигурации
# Self Signed (note the addition of -x509):
# openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.cert.pem
# Signing Request (note the lack of -x509):
# openssl req -config example-com.conf -new -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.req.pem
# Print it:
# openssl x509 -in example-com.cert.pem -text -noout
# openssl req -in example-com.req.pem -text -noout
[ req ]
default_bits = 2048
default_keyfile = server-key.pem
distinguished_name = subject
req_extensions = req_ext
x509_extensions = x509_ext
string_mask = utf8only
# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
# It's sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = NY
localityName = Locality Name (eg, city)
localityName_default = New York
organizationName = Organization Name (eg, company)
organizationName_default = Example, LLC
# Use a friendly name here because it's presented to the user. The server's DNS
# names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
# by both IETF and CA/Browser Forums. If you place a DNS name here, then you
# must include the DNS name in the SAN too (otherwise, Chrome and others that
# strictly follow the CA/Browser Baseline Requirements will fail).
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Example Company
emailAddress = Email Address
emailAddress_default = test@example.com
# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
# If RSA Key Transport bothers you, then remove keyEncipherment. TLS 1.3 is removing RSA
# Key Transport in favor of exchanges with Forward Secrecy, like DHE and ECDHE.
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alternate_names
nsComment = "OpenSSL Generated Certificate"
# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# extendedKeyUsage = serverAuth, clientAuth
# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]
subjectKeyIdentifier = hash
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alternate_names
nsComment = "OpenSSL Generated Certificate"
# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# extendedKeyUsage = serverAuth, clientAuth
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
# Add these if you need them. But usually you don't want them or
# need them in production. You may need them for development.
# DNS.5 = localhost
# DNS.6 = localhost.localdomain
# DNS.7 = 127.0.0.1
# IPv6 localhost
# DNS.8 = ::1
# DNS.9 = fe80::1
Возможно, вам придется сделать следующее для Chrome. В противном случае Chrome может пожаловаться на неправильное общее имя ( ERR_CERT_COMMON_NAME_INVALID) . Я не уверен, какова связь между IP-адресом в SAN и CN в этом случае.
# IPv4 localhost
# IP.1 = 127.0.0.1
# IPv6 localhost
# IP.2 = ::1
Centos 7 / Vagrant / Chrome Browser.