Как вы подписываете запрос на подпись сертификата в вашем центре сертификации?
Во время поиска я нашел несколько способов подписать запрос на подпись сертификата SSL:
С использованием
x509модуль:openssl x509 -req -days 360 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crtС использованием
caмодуль:openssl ca -cert ca.crt -keyfile ca.key -in server.csr -out server.crt
Примечание: я не уверен в использовании правильных параметров для этого. Пожалуйста, посоветуйте правильное использование, если я хочу его использовать.
Каким образом следует подписывать запросы на сертификаты в вашем центре сертификации? Один метод лучше, чем другой (например, один не рекомендуется)?
4 ответа
1. Using the x509 module
openssl x509 ...
...
2 Using the ca module
openssl ca ...
...
Чего вам не хватает, так это прелюдии к этой команде.
Это двухступенчатый процесс. Сначала вы настраиваете свой CA, а затем подписываете сертификат конечного объекта (он же сервер или пользователь). Обе эти команды объединяют два шага в один. И оба предполагают, что у вас уже есть файл конфигурации OpenSSL, уже настроенный как для ЦС, так и для сертификатов сервера (конечного объекта).
Сначала создайте базовый файл конфигурации:
$ touch openssl-ca.cnf
Затем добавьте следующее:
HOME = .
RANDFILE = $ENV::HOME/.rnd
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
[ CA_default ]
default_days = 1000 # how long to certify for
default_crl_days = 30 # how long before next CRL
default_md = sha256 # use public key default MD
preserve = no # keep passed DN ordering
x509_extensions = ca_extensions # The extensions to add to the cert
email_in_dn = no # Don't concat the email in the DN
copy_extensions = copy # Required to copy SANs from CSR to cert
####################################################################
[ req ]
default_bits = 4096
default_keyfile = cakey.pem
distinguished_name = ca_distinguished_name
x509_extensions = ca_extensions
string_mask = utf8only
####################################################################
[ ca_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Maryland
localityName = Locality Name (eg, city)
localityName_default = Baltimore
organizationName = Organization Name (eg, company)
organizationName_default = Test CA, Limited
organizationalUnitName = Organizational Unit (eg, division)
organizationalUnitName_default = Server Research Department
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Test CA
emailAddress = Email Address
emailAddress_default = test@example.com
####################################################################
[ ca_extensions ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always, issuer
basicConstraints = critical, CA:true
keyUsage = keyCertSign, cRLSign
Поля над полем взяты из более сложного openssl.cnf (вы можете найти его в /usr/lib/openssl.cnf), но я думаю, что они необходимы для создания сертификата CA и закрытого ключа.
Настройте поля выше на свой вкус. Значения по умолчанию экономят ваше время от ввода той же информации при экспериментировании с файлом конфигурации и параметрами команды.
Я пропустил материал, относящийся к CRL, но ваши операции CA должны иметь их. Увидеть openssl.cnf и связанные crl_ext раздел.
Затем выполните следующее. -nodes пропускает пароль или фразу-пароль, чтобы вы могли проверить сертификат. Это действительно плохая идея, чтобы опустить пароль или фразу-пароль.
$ openssl req -x509 -config openssl-ca.cnf -newkey rsa:4096 -sha256 -nodes -out cacert.pem -outform PEM
После выполнения команды cacert.pem будет вашим сертификатом для операций CA, и cakey.pem будет закрытый ключ. Напомним, закрытый ключ не имеет пароля или парольной фразы.
Вы можете сбросить сертификат с помощью следующего.
$ openssl x509 -in cacert.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 11485830970703032316 (0x9f65de69ceef2ffc)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=MD, L=Baltimore, CN=Test CA/emailAddress=test@example.com
Validity
Not Before: Jan 24 14:24:11 2014 GMT
Not After : Feb 23 14:24:11 2014 GMT
Subject: C=US, ST=MD, L=Baltimore, CN=Test CA/emailAddress=test@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:b1:7f:29:be:78:02:b8:56:54:2d:2c:ec:ff:6d:
...
39:f9:1e:52:cb:8e:bf:8b:9e:a6:93:e1:22:09:8b:
59:05:9f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
4A:9A:F3:10:9E:D7:CF:54:79:DE:46:75:7A:B0:D0:C1:0F:CF:C1:8A
X509v3 Authority Key Identifier:
keyid:4A:9A:F3:10:9E:D7:CF:54:79:DE:46:75:7A:B0:D0:C1:0F:CF:C1:8A
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage:
Certificate Sign, CRL Sign
Signature Algorithm: sha256WithRSAEncryption
4a:6f:1f:ac:fd:fb:1e:a4:6d:08:eb:f5:af:f6:1e:48:a5:c7:
...
cd:c6:ac:30:f9:15:83:41:c1:d1:20:fa:85:e7:4f:35:8f:b5:
38:ff:fd:55:68:2c:3e:37
И проверьте его назначение следующим образом (не беспокойтесь о Any Purpose: Yes; см. "критический,CA: ЛОЖЬ", но "Any Purpose CA: Yes").
$ openssl x509 -purpose -in cacert.pem -inform PEM
Certificate purposes:
SSL client : No
SSL client CA : Yes
SSL server : No
SSL server CA : Yes
Netscape SSL server : No
Netscape SSL server CA : Yes
S/MIME signing : No
S/MIME signing CA : Yes
S/MIME encryption : No
S/MIME encryption CA : Yes
CRL signing : Yes
CRL signing CA : Yes
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : Yes
Time Stamp signing : No
Time Stamp signing CA : Yes
-----BEGIN CERTIFICATE-----
MIIFpTCCA42gAwIBAgIJAJ9l3mnO7y/8MA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
...
aQUtFrV4hpmJUaQZ7ySr/RjCb4KYkQpTkOtKJOU1Ic3GrDD5FYNBwdEg+oXnTzWP
tTj//VVoLD43
-----END CERTIFICATE-----
Для второй части я собираюсь создать еще один файл conf, который легко усваивается. Первый, touch openssl-server.cnf (вы можете сделать один из них для пользовательских сертификатов также).
$ touch openssl-server.cnf
Затем откройте его и добавьте следующее.
HOME = .
RANDFILE = $ENV::HOME/.rnd
####################################################################
[ req ]
default_bits = 2048
default_keyfile = serverkey.pem
distinguished_name = server_distinguished_name
req_extensions = server_req_extensions
string_mask = utf8only
####################################################################
[ server_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = MD
localityName = Locality Name (eg, city)
localityName_default = Baltimore
organizationName = Organization Name (eg, company)
organizationName_default = Test Server, Limited
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Test Server
emailAddress = Email Address
emailAddress_default = test@example.com
####################################################################
[ server_req_extensions ]
subjectKeyIdentifier = hash
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alternate_names
nsComment = "OpenSSL Generated Certificate"
####################################################################
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
Если вы разрабатываете и хотите использовать свою рабочую станцию в качестве сервера, вам может потребоваться выполнить следующие действия для Chrome. В противном случае Chrome может жаловаться, что общее имя недействительно ( ERR_CERT_COMMON_NAME_INVALID ) Я не уверен, какова связь между IP-адресом в SAN и CN в этом случае.
# IPv4 localhost
IP.1 = 127.0.0.1
# IPv6 localhost
IP.2 = ::1
Затем создайте запрос сертификата сервера. Обязательно опустите -x509 *. Добавление -x509 создаст сертификат, а не запрос.
$ openssl req -config openssl-server.cnf -newkey rsa:2048 -sha256 -nodes -out servercert.csr -outform PEM
После выполнения этой команды у вас будет запрос в servercert.csr и закрытый ключ в serverkey.pem,
И вы можете проверить это снова.
$ openssl req -text -noout -verify -in servercert.csr
Certificate:
verify OK
Certificate Request:
Version: 0 (0x0)
Subject: C=US, ST=MD, L=Baltimore, CN=Test Server/emailAddress=test@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ce:3d:58:7f:a0:59:92:aa:7c:a0:82:dc:c9:6d:
...
f9:5e:0c:ba:84:eb:27:0d:d9:e7:22:5d:fe:e5:51:
86:e1
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Subject Key Identifier:
1F:09:EF:79:9A:73:36:C1:80:52:60:2D:03:53:C7:B6:BD:63:3B:61
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com, DNS:mail.example.com, DNS:ftp.example.com
Netscape Comment:
OpenSSL Generated Certificate
Signature Algorithm: sha256WithRSAEncryption
6d:e8:d3:85:b3:88:d4:1a:80:9e:67:0d:37:46:db:4d:9a:81:
...
76:6a:22:0a:41:45:1f:e2:d6:e4:8f:a1:ca:de:e5:69:98:88:
a9:63:d0:a7
Затем вы должны подписать его с вашим CA.
Вы почти готовы подписать сертификат сервера вашим центром сертификации. CA's openssl-ca.cnf нужны еще два раздела перед выдачей команды.
Во-первых, открыть openssl-ca.cnf и добавьте следующие два раздела.
####################################################################
[ signing_policy ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
[ signing_req ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
Во-вторых, добавьте следующее к [ CA_default ] раздел openssl-ca.cnf, Я оставил их раньше, потому что они могут усложнить вещи (они не использовались в то время). Теперь вы увидите, как они используются, так что, надеюсь, они будут иметь смысл.
base_dir = .
certificate = $base_dir/cacert.pem # The CA certifcate
private_key = $base_dir/cakey.pem # The CA private key
new_certs_dir = $base_dir # Location for new certs after signing
database = $base_dir/index.txt # Database index file
serial = $base_dir/serial.txt # The current serial number
unique_subject = no # Set to 'no' to allow creation of
# several certificates with same subject.
В-третьих, коснитесь index.txt а также serial.txt:
$ touch index.txt
$ echo '01' > serial.txt
Затем выполните следующее:
$ openssl ca -config openssl-ca.cnf -policy signing_policy -extensions signing_req -out servercert.pem -infiles servercert.csr
Вы должны увидеть следующее:
Using configuration from openssl-ca.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'US'
stateOrProvinceName :ASN.1 12:'MD'
localityName :ASN.1 12:'Baltimore'
commonName :ASN.1 12:'Test CA'
emailAddress :IA5STRING:'test@example.com'
Certificate is to be certified until Oct 20 16:12:39 2016 GMT (1000 days)
Sign the certificate? [y/n]:Y
1 out of 1 certificate requests certified, commit? [y/n]Y
Write out database with 1 new entries
Data Base Updated
После выполнения команды у вас будет свежеиспеченный сертификат сервера в servercert.pem, Закрытый ключ был создан ранее и доступен в serverkey.pem,
Наконец, вы можете проверить свой свежеиспеченный сертификат следующим образом.
$ openssl x509 -in servercert.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 9 (0x9)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=MD, L=Baltimore, CN=Test CA/emailAddress=test@example.com
Validity
Not Before: Jan 24 19:07:36 2014 GMT
Not After : Oct 20 19:07:36 2016 GMT
Subject: C=US, ST=MD, L=Baltimore, CN=Test Server
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ce:3d:58:7f:a0:59:92:aa:7c:a0:82:dc:c9:6d:
...
f9:5e:0c:ba:84:eb:27:0d:d9:e7:22:5d:fe:e5:51:
86:e1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
1F:09:EF:79:9A:73:36:C1:80:52:60:2D:03:53:C7:B6:BD:63:3B:61
X509v3 Authority Key Identifier:
keyid:42:15:F2:CA:9C:B1:BB:F5:4C:2C:66:27:DA:6D:2E:5F:BA:0F:C5:9E
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com, DNS:mail.example.com, DNS:ftp.example.com
Netscape Comment:
OpenSSL Generated Certificate
Signature Algorithm: sha256WithRSAEncryption
b1:40:f6:34:f4:38:c8:57:d4:b6:08:f7:e2:71:12:6b:0e:4a:
...
45:71:06:a9:86:b6:0f:6d:8d:e1:c5:97:8d:fd:59:43:e9:3c:
56:a5:eb:c8:7e:9f:6b:7a
Ранее вы добавили следующее в CA_default: copy_extensions = copy, Это расширение копии, предоставленное лицом, делающим запрос.
Если вы опустите copy_extensions = copy тогда в сертификате вашего сервера будут отсутствовать альтернативные имена субъекта (SAN), например www.example.com а также mail.example.com,
Если вы используете copy_extensions = copy но не просматривайте запрос, тогда запрашивающая сторона может заставить вас подписать что-то вроде подчиненного корня (а не сертификата сервера или пользователя). Это означает, что он сможет чеканить сертификаты, которые возвращаются к вашему доверенному корню. Не забудьте проверить запрос с openssl req -verify до подписания.
Если вы опустите unique_subject или установите его yes, тогда вам будет разрешено создать только один сертификат под отличительным именем субъекта.
unique_subject = yes # Set to 'no' to allow creation of
# several ctificates with same subject.
Попытка создать второй сертификат во время эксперимента приведет к следующему при подписании сертификата вашего сервера с помощью закрытого ключа ЦС:
Sign the certificate? [y/n]:Y
failed to update database
TXT_DB error number 2
Так unique_subject = no идеально подходит для тестирования.
Если вы хотите убедиться, что Имя организации соответствует самозаверяющим ЦС, Подведомственному ЦС и сертификатам конечных объектов, добавьте следующее в файлы конфигурации ЦС:
[ policy_match ]
organizationName = match
Если вы хотите разрешить изменение имени организации, используйте:
[ policy_match ]
organizationName = supplied
Существуют и другие правила обработки имен DNS в сертификатах X.509/PKIX. Обратитесь к этим документам для правил:
- RFC 5280, Internet X.509 Профиль сертификата инфраструктуры CRL и списка отзыва сертификатов (CRL)
- RFC 6125, Представление и проверка идентичности доменной службы приложений в инфраструктуре открытых ключей Интернета с использованием сертификатов X.509 (PKIX) в контексте безопасности транспортного уровня (TLS)
- RFC 6797, Приложение A, HTTP Strict Transport Security (HSTS)
- RFC 7469, Расширение закрепления открытого ключа для HTTP
- Базовые требования к CA/Browser Forum
- CA/Browser Forum Расширенные правила проверки
RFC 6797 и RFC 7469 перечислены, потому что они более строгие, чем другие документы RFC и CA / B. RFC 6797 и 7469 также не допускают IP-адреса.
Иногда, например, для тестирования, вам просто нужны упрощенные средства создания подписанного сертификата без настройки полноценной конфигурации CA. Это возможно, используя только
openssl req а также
openssl x509команды. Вы бы никогда не использовали этот метод для производственных сертификатов, но, поскольку он полезен для некоторых непроизводственных ситуаций, вот команды.
Создать самозаверяющий сертификат для подписи
Сначала создайте самозаверяющий сертификат, который будет использоваться в качестве корня доверия:
openssl req -x509 -days 365 -key ca_private_key.pem -out ca_cert.pem
Или, что то же самое, если вы хотите сгенерировать закрытый ключ и самозаверяющий сертификат с помощью одной команды:
openssl req -x509 -days 365 -newkey rsa:4096 -keyout ca_private_key.pem -out ca_cert.pem
Создать запрос на сертификат
Затем создайте запрос сертификата для сертификата, который нужно подписать:
openssl req -new -key my_private_key.pem -out my_cert_req.pem
Опять же, при необходимости вы можете сгенерировать закрытый ключ и запрос одновременно:
openssl req -new -newkey rsa:4096 -keyout my_private_key.pem -out my_cert_req.pem
Создать подписанный сертификат
Наконец, используйте самозаверяющий сертификат подписи для создания подписанного сертификата из запроса сертификата:
openssl x509 -req -in my_cert_req.pem -days 365 -CA ca_cert.pem -CAkey ca_private_key.pem -CAcreateserial -out my_signed_cert.pem
В дополнение к ответу @jww, я хотел бы сказать, что конфигурация в openssl-ca.cnf
default_days = 1000 # how long to certify for
определяет по умолчанию количество дней, в течение которых сертификат, подписанный этим root-ca, будет действительным, чтобы установить действительность самого root-ca, следует использовать опцию -days n в
openssl req -x509 -days 3000 -config openssl-ca.cnf -newkey rsa:4096 -sha256 -nodes -out cacert.pem -outform PEM
В противном случае ваш root-ca будет действителен только в течение 1 месяца по умолчанию, и любой сертификат, подписанный этим rot-ca, будет также иметь срок действия 1 месяц.
Я нашел удобный скриптsscgдля этой задачи - https://github.com/sgallagher/sscg
Вот пример для Fedora linux:
Установка:
sudo yum install sscg
Пример:
sscg \
--ca-key-password-prompt \
--lifetime=3650 \
--country=XX \
--state=myState \
--locality=myCity \
--organization=myOrg \
--organizational-unit=myUnit \
--email=myemail@example.com \
--hostname=foo.example.com \
--subject-alt-name=*.example.com \
--ca-key-file=CA.key \
--ca-file=CA.pem \
--cert-key-file=foo.example.com.key \
--cert-file=foo.example.com.pem