Как создать сертификат SSL больше чем для одного субдомена?

Это правильный вопрос. К сожалению, насколько я понимаю, протоколы никогда не предполагали, что владелец домена сможет подписывать сертификаты только для поддоменов.

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

Глупо, но это так. Просто купите отдельный сертификат для каждого домена, которым вы владеете $$$, правильно для каждого, так что не пытайтесь защитить встроенные устройства, которые вы продаете.

Так же, как и FYI, существует другой вид сертификата, называемый унифицированным сертификатом связи. Подстановочный символ может быть выдан только для *.domain.com, но UCC сертификат позволяет перечислять до 100 полностью квалифицированных доменных имен (FQDN) под любым доменом. Основной причиной получения такого сертификата является то, что компания Microsoft не слишком увлечена подстановочными знаками для таких вещей, как MS Domain Controllers, Exchange, и т.д.

https://www.godaddy.com/help/what-is-a-multiple-domain-ucc-ssl-certificate-3908

A Unified Communications Certificate (UCC) - это SSL сертификат, который защищает несколько доменных имен и несколько имен хостов в пределах доменного имени. UCC позволяет защитить основное доменное имя и до 99 дополнительных Subject Alternative Names (SANs) в одном сертификате. UCC идеально подходят для Microsoft® Exchange Server 2007, Exchange Server 2010 и Microsoft Live® Communications Server.

UCC совместимы с общим хостингом. Однако, печать сайта и информация о сертификате "Issued To" будет содержать только первичное имя домена. Обратите внимание, что любые учетные записи вторичного хостинга также будут перечислены в сертификате, поэтому если вы не хотите, чтобы сайты выглядели "связанными" друг с другом, вам не следует использовать этот тип сертификата.

Основным недостатком UCC является то, что вы должны перечислять все свои домены вперед (подстановочные знаки не требуют этого). Если список когда-нибудь изменится, вам нужно будет получить новый сертификат. Кстати, Namecheap (только один, о котором я знаю, делает это) предлагает Extended Validation UCC (вы платите за каждый домен, что означает, что сертификат на 100 доменов ОЧЕНЬ дорог), что является единственным способом получить EV сертификат для более чем одного домена, так как никто не предлагает EV Wildcards.

Я не могу комментировать, поэтому добавляю отдельный ответ. Я попытался создать самозаверяющий сертификат для NGINX, и это было легко, но когда я захотел добавить его в белый список Chrome, у меня возникла проблема. И моим решением было создать корневой сертификат и подписать им дочерний сертификат.

Итак, шаг за шагом. Создайте файл config_ssl_ca.cnf Обратите внимание, в конфигурационном файле есть опция basicConstraints=CA:true, что означает, что этот сертификат должен быть корневым.

Это хорошая практика, потому что вы создаете его один раз и можете использовать повторно.

[ req ]
default_bits = 2048

prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req

[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=root region
localityName=root city
organizationName=Market(localhost)
organizationalUnitName=roote department
commonName=market.localhost
emailAddress=root_email@root.localhost

[ alternate_names ]
DNS.1        = market.localhost
DNS.2        = www.market.localhost
DNS.3        = mail.market.localhost
DNS.4        = ftp.market.localhost
DNS.5        = *.market.localhost

[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:true
subjectKeyIdentifier = hash
subjectAltName = @alternate_names

Следующий файл конфигурации для вашего дочернего сертификата будет называться config_ssl.cnf.

[ req ]
default_bits = 2048

prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req

[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=Kyiv region
localityName=Kyiv
organizationName=market place
organizationalUnitName=market place department
commonName=market.localhost
emailAddress=email@market.localhost

[ alternate_names ]
DNS.1        = market.localhost
DNS.2        = www.market.localhost
DNS.3        = mail.market.localhost
DNS.4        = ftp.market.localhost
DNS.5        = *.market.localhost

[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:false
subjectAltName = @alternate_names
subjectKeyIdentifier = hash

Первый шаг — создание корневого ключа и сертификата.

openssl genrsa -out ca.key 2048
openssl req -new -x509 -key ca.key -out ca.crt -days 365 -config config_ssl_ca.cnf

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

openssl genrsa -out market.key 2048
openssl req -new -sha256 -key market.key -config config_ssl.cnf -out market.csr

Откройте терминал Linux и выполните эту команду

echo 00 > ca.srl
touch index.txt

Текстовый файл ca.srl, содержащий следующий серийный номер для использования в шестнадцатеричном формате . Обязательный. Этот файл должен присутствовать и содержать действительный серийный номер.

Последний шаг, создайте еще один файл конфигурации и назовите его config_ca.cnf

# we use 'ca' as the default section because we're usign the ca command
[ ca ]
default_ca = my_ca

[ my_ca ]
#  a text file containing the next serial number to use in hex. Mandatory.
#  This file must be present and contain a valid serial number.
serial = ./ca.srl

# the text database file to use. Mandatory. This file must be present though
# initially it will be empty.
database = ./index.txt

# specifies the directory where new certificates will be placed. Mandatory.
new_certs_dir = ./

# the file containing the CA certificate. Mandatory
certificate = ./ca.crt

# the file contaning the CA private key. Mandatory
private_key = ./ca.key

# the message digest algorithm. Remember to not use MD5
default_md = sha256

# for how many days will the signed certificate be valid
default_days = 365

# a section with a set of variables corresponding to DN fields
policy = my_policy

# MOST IMPORTANT PART OF THIS CONFIG
copy_extensions = copy

[ my_policy ]
# if the value is "match" then the field value must match the same field in the
# CA certificate. If the value is "supplied" then it must be present.
# Optional means it may be present. Any fields not mentioned are silently
# deleted.
countryName = match
stateOrProvinceName = supplied
organizationName = supplied
commonName = market.localhost
organizationalUnitName = optional
commonName = supplied

Вы можете спросить, почему так сложно, почему мы должны создать еще один файл конфигурации, чтобы подписать дочерний сертификат root. Ответ прост, потому что дочерний сертификат должен иметь блок SAN — альтернативные имена субъекта. Если мы подпишем дочерний сертификат с помощью утилиты «openssl x509», корневой сертификат удалит поле SAN в дочернем сертификате. Поэтому мы используем «openssl ca» вместо «openssl x509», чтобы избежать удаления поля SAN. Мы создаем новый файл конфигурации и говорим ему скопировать все расширенные поля copy_extensions = copy.

openssl ca -config config_ca.cnf -out market.crt -in market.csr

Программа задает вам 2 вопроса:

1. Подписать сертификат? Произнесите "Y"
2. 1 из 1 запросов на сертификат сертифицирован, зафиксировать? Произнесите "Y"

В терминале вы увидите предложение со словом "База данных", оно означает файл index.txt, который вы создаете командой "touch". Он будет содержать всю информацию по всем сертификатам, созданным с помощью утилиты «openssl ca». Чтобы проверить действительность сертификата, используйте:

openssl rsa -in market.key -check

Если вы хотите увидеть, что внутри в CRT:

openssl x509 -in market.crt -text -noout

Если вы хотите увидеть, что внутри в CSR:

openssl req -in market.csr -noout -text