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, Інтернет-сертифікат інфраструктури відкритого ключа Internet X.509 та список відкликаних сертифікатів (CRL) та базові вимоги форуму CA / Browser Forum .
В основному вам потрібно використовувати файл конфігурації 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. Тут не так багато. Ви можете зробити все, що може зробити громадський громадський центр. Єдине, що вам потрібно буде встановити свій сертифікат Root CA в різних магазинах. Це не інакше, ніж, скажімо, використання CURL cacerts.pm
. cacerts.pm
це лише колекція Root CA, і тепер ви приєдналися до клубу.
Якщо ви перебуваєте у власному центрі обслуговування, тоді обов'язково запишіть на диск приватний ключ 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
.