Posted:
Янв 12, 2023
Comments:
0 Comments

Генерация сертификатов openssl: Создание сертификата OpenSSL — Losst

Генерация запроса на подпись сертификата вручную (CSR) Использование OpenSSL

Этот урок покажет вам, как вручную создать Запрос на подпись сертификата (или CSR) в среде веб-хостинга Apache или Nginx с использованием OpenSSL. Нажмите здесь для обучения по заказу сертификатов, или здесь для получения дополнительной информации о том, как установить новый сертификат SSL.com.

Чтобы получить дополнительные полезные инструкции и последние новости кибербезопасности, подпишитесь на информационный бюллетень SSL.com здесь:

Видео

В этих инструкциях мы собираемся использовать OpenSSL req утилита для генерации как закрытого ключа, так и CSR в одной команде. Генерация секретного ключа таким способом гарантирует, что вам будет предложено ввести пароль для защиты закрытого ключа. Во всех приведенных примерах команд замените имена файлов, показанные в ALL CAPS, на фактические пути и имена файлов, которые вы хотите использовать. (Например, вы можете заменить PRIVATEKEY.key с /private/etc/apache2/server.key в среде MacOS Apache.) Это практическое руководство охватывает генерацию обоих RSA и ECDSA ключи.

RSA

Приведенная ниже команда OpenSSL сгенерирует 2048-битный закрытый ключ RSA и CSR:

openssl req -newkey rsa: 2048 -keyout PRIVATEKEY.key -out МОЙCSR.csr

Давайте разберем команду:

  • openssl это команда для запуска OpenSSL.
  • req это утилита OpenSSL для создания CSR.
  • -newkey rsa:2048 сообщает OpenSSL создать новый 2048-битный закрытый ключ RSA. Если вы предпочитаете ключ 4096 бит, вы можете изменить это число на 4096.
  • -keyout PRIVATEKEY.key указывает, где сохранить файл закрытого ключа.
  • -out MYCSR.csr указывает, где сохранить CSR .
  • С этими двумя последними элементами не забудьте использовать свои собственные пути и имена файлов для закрытого ключа и CSR, а не заполнители.

После ввода команды нажмите вводить, Вам будет представлен ряд подсказок:

  • Сначала создайте и подтвердите парольную фразу. Запомните эту парольную фразу, потому что она понадобится вам снова для доступа к вашему секретному ключу.
  • Теперь вам будет предложено ввести информацию, которая будет включена в ваш CSR, Эта информация также известна как Отличное имя или DN, Распространенное имя поле обязательно для SSL. com при отправке вашего CSR, но остальные не являются обязательными. Если вы хотите пропустить дополнительный элемент, просто введите вводить когда это появится:
    • Компания Имя страны (необязательно) занимает две буквы код страны.
    • Компания Название населенного пункта Поле (необязательно) предназначено для вашего города.
    • Компания Название организации поле (необязательно) предназначено для названия вашей компании или организации.
    • Компания Распространенное имя поле (обязательное) используется для Полное доменное имя (FQDN) сайта этот сертификат будет защищать.
    • Ваш e-mail (опционально)
    • Компания Пароль для вызова поле является необязательным и может быть пропущено.

По завершении этого процесса вы вернетесь в командную строку. Вы не получите никакого уведомления о том, что ваш CSR был успешно создан.

Вернуться к началу

ECDSA

Чтобы создать закрытый ключ ECDSA с вашим CSR, вам необходимо вызвать вторую утилиту OpenSSL, чтобы сгенерировать параметры для ключа ECDSA.

Эта команда OpenSSL сгенерирует файл параметров для 256-битного ключа ECDSA:

openssl genpkey -genparam -algorithm ec -pkeyopt ec_paramgen_curve: P-256 -out ECPARAM.pem
  • openssl genpkey запускает утилиту openssl для генерации закрытого ключа.
  • -genparam генерирует файл параметров вместо закрытого ключа. Вы также можете сгенерировать закрытый ключ, но используя файл параметров при генерации ключа и CSR гарантирует, что вам будет предложено ввести пароль.
  • -algorithm ec определяет алгоритм эллиптической кривой.
  • -pkeyopt ec_paramgen_curve:P-256 выбирает 256-битную кривую. Если вы предпочитаете 384-битную кривую, измените часть после двоеточия на P-384.
  • -out ECPARAM. pem предоставляет путь и имя файла для файла параметров.

Теперь укажите ваш файл параметров при создании CSR:

openssl req -newkey ec: ECPARAM.pem -keyout PRIVATEKEY.key -out МОЙCSR.csr

Команда такая же, как мы использовали в примере RSA выше, но -newkey RSA:2048 был заменен на -newkey ec:ECPARAM.pem, Как и прежде, вам будет предложено ввести пароль и информацию о различающемся имени для CSR.

При желании вы можете использовать перенаправление для объединения двух команд OpenSSL в одну строку, пропуская создание файла параметров, как показано ниже:

openssl req -newkey ec: <(openssl genpkey -genparam -algorithm ec -pkeyopt ec_paramgen_curve: P-256) -keyout PRIVATEKEY.key -out MYCSR.csr

Далее Шаги

Для получения дополнительной информации об установке сертификата см. прочитайте здесь, для привязки к IIS 10, читать здесь. 

Генерация сертификатов вручную | Kubernetes

При аутентификации с помощью клиентского сертификата сертификаты можно генерировать вручную с помощью easyrsa, openssl или cfssl.

easyrsa

easyrsa поддерживает ручную генерацию сертификатов для кластера.

  1. Скачайте, распакуйте и инициализируйте пропатченную версию easyrsa3.

    curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
tar xzf easy-rsa.tar.gz
cd easy-rsa-master/easyrsa3
./easyrsa init-pki

  2. Создайте новый центр сертификации (certificate authority, CA). --batch задает автоматический режим;
    --req-cn указывает общее имя (Common Name, CN) для нового корневого сертификата CA.

    ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass

  3. Сгенерируйте сертификат и ключ сервера.

    Аргумент --subject-alt-name задает допустимые IP-адреса и DNS-имена, с которых будет осуществляться доступ к серверу API. MASTER_CLUSTER_IP обычно является первым IP из CIDR сервиса, который указан в качестве аргумента --service-cluster-ip-range как для сервера API, так и для менеджера контроллеров. Аргумент --days задает количество дней, через которое истекает срок действия сертификата. В приведенном ниже примере предполагается, что cluster.local используется в качестве доменного имени по умолчанию.

    ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
"IP:${MASTER_CLUSTER_IP},"\
"DNS:kubernetes,"\
"DNS:kubernetes.default,"\
"DNS:kubernetes.default.svc,"\
"DNS:kubernetes.default.svc.cluster,"\
"DNS:kubernetes.default.svc.cluster.local" \
--days=10000 \
build-server-full server nopass

  4. Скопируйте pki/ca.crt, pki/issued/server.crt и pki/private/server. key в свою директорию.

  5. Заполните и добавьте следующие параметры в параметры запуска сервера API:

    --client-ca-file=/yourdirectory/ca.crt
--tls-cert-file=/yourdirectory/server.crt
--tls-private-key-file=/yourdirectory/server.key

openssl

openssl поддерживает ручную генерацию сертификатов для кластера.

  1. Сгенерируйте 2048-разрядный ключ ca.key:

    openssl genrsa -out ca.key 2048

  2. На основе ca.key сгенерируйте ca.crt (используйте -days для установки времени действия сертификата):

    openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt

  3. Сгенерируйте 2048-битный ключ server.key:

    openssl genrsa -out server.key 2048

  4. Создайте файл конфигурации для генерации запроса на подписание сертификата (Certificate Signing Request, CSR).

    Замените значения, помеченные угловыми скобками (например, <MASTER_IP>), нужными значениями перед сохранением в файл (например, csr.conf). Обратите внимание, что значение для MASTER_CLUSTER_IP – это cluster IP сервиса для сервера API, как описано в предыдущем подразделе. В приведенном ниже примере предполагается, что cluster.local используется в качестве доменного имени по умолчанию.

    [ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
[ dn ]
C = <country>
ST = <state>
L = <city>
O = <organization>
OU = <organization unit>
CN = <MASTER_IP>
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster
DNS.5 = kubernetes.default.svc.cluster.local
IP.1 = <MASTER_IP>
IP.2 = <MASTER_CLUSTER_IP>
[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectAltName=@alt_names

  5. Сгенерируйте запрос на подписание сертификата, используя файл конфигурации:

    openssl req -new -key server. key -out server.csr -config csr.conf

  6. С помощью ca.key, ca.crt и server.csr сгенерируйте сертификат сервера:

    openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
    -CAcreateserial -out server.crt -days 10000 \
    -extensions v3_ext -extfile csr.conf  -sha256

  7. Используйте следующую команду, чтобы просмотреть запрос на подписание сертификата:

    openssl req  -noout -text -in ./server.csr

  8. Используйте следующую команду, чтобы просмотреть сертификат:

    openssl x509  -noout -text -in ./server.crt

Наконец, добавьте эти параметры в конфигурацию запуска сервера API.

cfssl

cfssl – еще один инструмент для генерации сертификатов.

  1. Скачайте, распакуйте и подготовьте пакеты, как показано ниже.

    Обратите внимание, что команды необходимо адаптировать под архитектуру и используемую версию cfssl.

    curl -L https://github. com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
chmod +x cfssl
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
chmod +x cfssljson
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
chmod +x cfssl-certinfo

  2. Создайте директорию для хранения артефактов и инициализируйте cfssl:

    mkdir cert
cd cert
../cfssl print-defaults config > config.json
../cfssl print-defaults csr > csr.json

  3. Создайте JSON-конфиг для генерации файла CA (например, ca-config.json):

    {
  "signing": {
    "default": {
      "expiry": "8760h"
    },
    "profiles": {
      "kubernetes": {
        "usages": [
          "signing",
          "key encipherment",
          "server auth",
          "client auth"
        ],
        "expiry": "8760h"
      }
    }
  }
}

  4. Создайте JSON-конфиг для запроса на подписание сертификата (CSR) (например,
    ca-csr. json). Замените значения, помеченные угловыми скобками, на нужные.

    {
  "CN": "kubernetes",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names":[{
    "C": "<country>",
    "ST": "<state>",
    "L": "<city>",
    "O": "<organization>",
    "OU": "<organization unit>"
  }]
}

  5. Сгенерируйте ключ CA (ca-key.pem) и сертификат (ca.pem):

    ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca

  6. Создайте конфигурационный JSON-файл для генерации ключей и сертификатов для сервера API (например, server-csr.json). Замените значения, помеченные угловыми скобками, на нужные. MASTER_CLUSTER_IP – это cluster IP сервиса для сервера API, как описано в предыдущем подразделе. В приведенном ниже примере предполагается, что cluster.local используется в качестве доменного имени по умолчанию.

    {
  "CN": "kubernetes",
  "hosts": [
    "127. 0.0.1",
    "<MASTER_IP>",
    "<MASTER_CLUSTER_IP>",
    "kubernetes",
    "kubernetes.default",
    "kubernetes.default.svc",
    "kubernetes.default.svc.cluster",
    "kubernetes.default.svc.cluster.local"
  ],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [{
    "C": "<country>",
    "ST": "<state>",
    "L": "<city>",
    "O": "<organization>",
    "OU": "<organization unit>"
  }]
}

  7. Сгенерируйте ключ и сертификат для сервера API (по умолчанию они сохраняются в файлах server-key.pem и server.pem соответственно):

    ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
     --config=ca-config.json -profile=kubernetes \
     server-csr.json | ../cfssljson -bare server

Распространение самоподписанного сертификата CA

Клиентский узел может отказаться признавать самоподписанный сертификат CA действительным. В случае его использования не в production или в инсталляциях, защищенных межсетевым экраном, самоподписанный сертификат CA можно распространить среди всех клиентов и обновить локальный список действительных сертификатов.

Для этого на каждом клиенте выполните следующие операции:

sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
sudo update-ca-certificates

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....
done.

API для сертификатов

Для создания сертификатов x509, которые будут использоваться для аутентификации, можно воспользоваться API certificates.k8s.io. Для дополнительной информации см. Управление TLS-сертификатами в кластере.

Изменено December 04, 2022 at 4:05 AM PST: [ru] Document generating SHA256 CA certificate (acb7721e8c)

Как сгенерировать самозаверяющий SSL-сертификат с помощью OpenSSL?

Я что-то упустил? Это правильный способ создания самозаверяющего сертификата?

Создать самозаверяющий сертификат очень просто. Вы просто используете команду openssl req . Может быть сложно создать такой, который сможет использовать самый большой выбор клиентов, таких как браузеры и инструменты командной строки.

Это сложно, потому что браузеры имеют свой собственный набор требований, и они более строгие, чем IETF. Требования, используемые браузерами, задокументированы на форумах CA/Browser (см. ссылки ниже). Ограничения возникают в двух ключевых областях: (1) якоря доверия и (2) DNS-имена.

Современным браузерам (таким как варез, который мы использовали в 2014/2015 годах) нужен сертификат, который связывается с якорем доверия, и они хотят, чтобы DNS-имена представлялись в сертификате определенным образом. И браузеры активно выступают против самоподписанных серверных сертификатов.

Некоторые браузеры не позволяют легко импортировать самозаверяющий сертификат сервера. Фактически, вы не можете использовать некоторые браузеры, такие как браузер Android. Таким образом, полное решение состоит в том, чтобы стать своим собственным авторитетом.

Если вы не становитесь своим собственным авторитетом, вы должны получить правильные DNS-имена, чтобы дать сертификату наибольшие шансы на успех. Но я бы посоветовал вам стать авторитетом для себя. Легко стать авторитетом для себя, и это позволит обойти все проблемы с доверием (кому лучше доверять, чем себе?).

Вероятно, это не тот сайт, который вы ищете!
Сертификат безопасности сайта не является доверенным!

Это связано с тем, что браузеры используют предопределенный список якорей доверия для проверки сертификатов сервера. Самозаверяющий сертификат не связывается с доверенным якорем.

Лучший способ избежать этого:

  1. Создайте свой собственный центр сертификации (т. е. станьте ЦС)
  2. Создайте запрос на подпись сертификата (CSR) для сервера
  3. Подпишите CSR сервера своим ключом ЦС
  4. Установить сертификат сервера на сервер
  5. Установите сертификат ЦС на клиенте

Шаг 1 — Создайте свой собственный центр сертификации просто означает создание самозаверяющего сертификата с CA: true и правильным использованием ключа. значит Субъект и Издатель — это одна и та же сущность, для CA установлено значение true в Basic Constraints (он также должен быть помечен как критический), использование ключа — keyCertSign и crlSign (если вы используете CRL), Идентификатор ключа субъекта (SKI) совпадает с идентификатором ключа органа (AKI).

Чтобы стать собственным центром сертификации, см. *Как подписать запрос на подпись сертификата в своем центре сертификации? о переполнении стека. Затем импортируйте свой ЦС в хранилище доверия, используемое браузером.

Шаги 2–4 примерно соответствуют тому, что вы делаете сейчас для общедоступного сервера, когда подключаете услуги центра сертификации, такого как Startcom или CAcert. Шаги 1 и 5 позволяют вам избежать стороннего авторитета и действовать как собственный авторитет (кому лучше доверять, чем себе?).

Следующий лучший способ избежать предупреждения браузера — доверять сертификату сервера. Но некоторые браузеры, такие как браузер Android по умолчанию, не позволяют вам это сделать. Так что это никогда не будет работать на платформе.

Проблема с браузерами (и другими подобными пользовательскими агентами) , а не , доверяющие самозаверяющим сертификатам, станет большой проблемой в Интернете вещей (IoT). Например, что произойдет, когда вы подключитесь к своему термостату или холодильнику, чтобы запрограммировать его? Ответ: ничего хорошего с точки зрения пользовательского опыта.

Рабочая группа W3C WebAppSec начинает изучать проблему. См., например, Предложение: Маркировка HTTP как небезопасного.

Как создать самозаверяющий сертификат с OpenSSL

Приведенные ниже команды и файл конфигурации создают самозаверяющий сертификат (также показано, как создать запрос на подпись). Они отличаются от других ответов в одном отношении: DNS-имена, используемые для самозаверяющего сертификата, находятся в альтернативном имени субъекта (SAN) , а не в общем имени (CN) .

DNS-имена размещаются в SAN через конфигурационный файл со строкой subjectAltName = @alternate_names (через командную строку это сделать нельзя). Тогда есть секция alter_names в конфигурационном файле (настройте на свой вкус):

 [ alter_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
# Добавьте их, если они вам нужны. Но обычно вы не хотите их или
# они нужны в производстве. Они могут понадобиться вам для развития.
# DNS.5 = локальный хост
# DNS.6 = localhost.localdomain
# IP.1 = 127.0.0.1
# IP.2 = ::1

Важно указать DNS-имя в SAN, а не в CN, потому что и как IETF, так и форумы CA/Browser определяют практику. Они также указывают, что DNS-имена в CN устарели (но не запрещены). Если вы помещаете DNS-имя в CN, то оно должно быть включено в SAN согласно политикам CA/B. Таким образом, вы не можете избежать использования альтернативного имени субъекта.

Если вы не поместите DNS-имена в SAN, сертификат не пройдет проверку в браузере и других пользовательских агентах, которые следуют рекомендациям CA/Browser Forum.

Связано: браузеры следуют политикам CA/Browser Forum; а не политики IETF. Это одна из причин, по которой сертификат, созданный с помощью OpenSSL (который обычно следует IETF), иногда не проверяется в браузере (браузеры следуют CA/B). Это разные стандарты, у них разные политики выдачи и разные требования к проверке.

Создайте самозаверяющий сертификат (обратите внимание на добавление опции -x509 ):

openssl req -config пример-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes \
    -keyout пример-com.key.pem -days 365 -out пример-com.cert.pem

Создать запрос на подпись (обратите внимание на отсутствие параметра -x509 ):

 openssl req -config example-com.conf -new -sha256 -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

Файл конфигурации (передается через опцию -config ) 

 [ req ]
биты по умолчанию = 2048
default_keyfile = server-key.pem
отличительное_имя = тема
req_extensions = req_ext
x509_extensions = x509_ext
string_mask = только utf8
# DN субъекта может быть сформирован с использованием X501 или RFC 4514 (описание см. в RFC 4519).
# Это своего рода мэшап. Например, RFC 4514 не предоставляет адрес электронной почты.
[ предмет ]
countryName = название страны (двухбуквенный код)
countryName_default = США
stateOrProvinceName = название штата или провинции (полное название)
stateOrProvinceName_default = Нью-Йорк
localityName = Название местности (например, город)
localityName_default = Нью-Йорк
OrganizationName = Название организации (например, компания)
организацияName_default = Пример, ООО
# Используйте понятное имя, потому что оно представлено пользователю.  DNS сервера
# имена помещаются в альтернативные имена субъектов. Кроме того, DNS-имена здесь устарели.
# как IETF, так и CA/Browser Forums. Если вы разместите здесь DNS-имя, то вы
# также должно включать DNS-имя в SAN (в противном случае Chrome и другие
# строго следовать базовым требованиям CA/браузера не удастся).
commonName = Общее имя (например, полное доменное имя сервера или ВАШЕ имя)
commonName_default = Пример компании
адрес электронной почты = адрес электронной почты
emailAddress_default = [email protected]
# Раздел x509_ext используется при создании самоподписанного сертификата. То есть openssl req -x509...
[ x509_ext ]
subjectKeyIdentifier = хэш
authorKeyIdentifier = идентификатор ключа, эмитент
# Вам нужна только цифровая подпись ниже. *Если* вы не разрешаете
# Передача ключа RSA (т. е. вы используете эфемерные наборы шифров), затем
# опустить keyEncipherment, потому что это передача ключей.
базовые ограничения = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alternate_names
nsComment = "Сгенерированный сертификат OpenSSL"
# RFC 5280, раздел 4. 2.1.12 делает EKU необязательным
# CA/базовые требования к браузеру, Приложение (B)(3)(G) меня смущает
# В любом случае вам, вероятно, понадобится только serverAuth.
# extendedKeyUsage = serverAuth, clientAuth
# Раздел req_ext используется при формировании запроса на подпись сертификата. То есть запрос openssl ...
[req_ext]
subjectKeyIdentifier = хэш
базовые ограничения = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alternate_names
nsComment = "Сгенерированный сертификат OpenSSL"
# RFC 5280, раздел 4.2.1.12 делает EKU необязательным
# CA/базовые требования к браузеру, Приложение (B)(3)(G) меня смущает
# В любом случае вам, вероятно, понадобится только serverAuth.
# extendedKeyUsage = serverAuth, clientAuth
[альтернативные_имена]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
# Добавьте их, если они вам нужны. Но обычно вы не хотите их или
# они нужны в производстве. Они могут понадобиться вам для развития.
# DNS.5 = локальный хост
# DNS. 6 = localhost.localdomain
# DNS.7 = 127.0.0.1
# IPv6 локальный хост
# DNS.8 = ::1

Вам может потребоваться сделать следующее для Chrome. В противном случае Chrome может сообщить, что Common Name недействителен ( ERR_CERT_COMMON_NAME_INVALID ). Я не уверен, какая связь между IP-адресом в SAN и CN в данном случае.

 # локальный хост IPv4
# IP.1 = 127.0.0.1
# IPv6 локальный хост
# IP.2 = ::1

Существуют и другие правила, касающиеся обработки DNS-имен в сертификатах X.509/PKIX. Обратитесь к этим документам для правил:

  • RFC 5280, Internet X.509 Сертификат инфраструктуры открытых ключей и список отозванных сертификатов (CRL) Профиль
  • RFC 6125, Представление и проверка удостоверения службы доменных приложений в инфраструктуре открытых ключей Интернета с использованием сертификатов X.509 (PKIX) в контексте безопасности транспортного уровня (TLS)
  • RFC 6797, Приложение A, Строгая транспортная безопасность HTTP (HSTS)
  • RFC 7469, Расширение для закрепления открытого ключа для HTTP
  • Базовые требования форума CA/Browser
  • Руководство CA/Browser Forum по расширенной проверке

Перечислены RFC 6797 и RFC 7469, поскольку они имеют более строгие ограничения, чем другие документы RFC и CA/B. RFC 6797 и 7469 также не разрешают IP-адрес.

openssl — не задавать вопрос при создании SSL-сертификата

спросил

Изменено
1 год, 9несколько месяцев назад

Просмотрено
297 раз

Иногда я тестирую веб-сайт SSL на своем локальном компьютере. Я устал использовать самозаверяющий сертификат и добавлять их в свою цепочку ключей на Mac (в браузере или другой ОС). Более того, Chrome всегда на них жалуется. Более того, этот подход немного отличался от того, что использовался в производстве.

Эта статья показалась мне очень полезной: вы один раз создаете свой собственный корневой сертификат ЦС, добавляете его один раз в свою цепочку для ключей, а затем используете закрытый ключ ЦС для подписи тысяч тестовых сертификатов SSL для моих локальных веб-сайтов.
https://deliciousbrains.com/ssl-certificate-authority-for-local-https-development/

Учебник работает отлично, но я хотел бы его автоматизировать. Для корневого сертификата ЦС это было легко, я просто использовал параметр -subj следующим образом:

 openssl req -x509 -new -nodes -key /certs/myCA.key -sha256 -days 1825 -subj "/C= $CA_COUNTRY/ST=$CA_STATE/L=$CA_CITY/O=$CA_ORGANIZATION/CN=$CA_COMMON_NAME" -out /certs/myCA2.pem

где переменная среды (CA_COUNTRY, CA_STATE, CA_CITY, CA_ORGANIZATION, CA_COMMON_NAME) считывается из внешнего файла.

Однако, когда я попытался воспроизвести то же самое для сертификата веб-сайта, я не смог получить тот же результат. Команда следующая:

 openssl x509 -req -in dev.deliciousbrains.com.csr -CA myCA.pem -CAkey myCA.key -CAcreateserial -out dev.deliciousbrains.com.crt -days 825 -sha256 -extfile dev. deliciousbrains.com.ext

Кажется, что опция -subj не работает. Есть ли способ передать приведенную выше информацию этой команде и избежать интерактивных вопросов?

  • ssl
  • openssl
  • ssl-certificate
  • x509certificate

Команда, которую вы показываете openssl x509 -req -CA/-CAkey . .. которая не задает никаких вопросов, кроме ключа если вы следовали инструкциям на связанной странице). Это команда , предшествующая , для создания CSR openssl req -new , которая запрашивает имя субъекта и для этого (например, команда для создания сертификата ЦС, которая также ).0007 req , но с -x509 — примечание -x509 не совпадает с x509 ) вы можете использовать -subj . Утверждение на этой странице, что «ваши ответы не имеют значения», не совсем верно; это правда, что когда вы используете SubjectAlternativeName в листовом сертификате, как советует/указывает эта страница, значение Subject игнорируется (по крайней мере) для идентификации HTTPS-сервера, но оно должно (все еще) быть отличным от имени, используемого для CA, чтобы разрешить работу проверки сертификата. Стандарты разрешают, чтобы имя субъекта в листовом сертификате было пустым, когда используется SAN (и пустое всегда отличается от непустого, и в сертификате ЦС требуется непустое имя), но OpenSSL не обрабатывает этот случай.

This entry was posted in Популярное