Содержание

Как создать самоподписанный SSL сертификат в Windows?

Большинству администраторов Windows, знакомых с темой PKI, известна утилита MakeCert.exe, с помощью которой можно создать самоподписанный сертификат. Эта утилита включена в состав Microsoft .NET Framework SDK и Microsoft Windows SDK. В современных версиях Windows 11/10/8.1 и Windows Server 2022/2019/2016/2012R2 вы можете создать самоподписанный сертификат с помощью встроенных командлетов PowerShell без использования дополнительных утилит.

Содержание:

  • New-SelfSignedCertificate: создать самоподписанный SSL сертификат в PowerShell
  • Как сгенерировать SAN (SubjectAltName) сертификат с помощью PowerShell?
  • Экспорт самоподписаного сертификата в Windows
  • Сгенерировать сертификат для подписи кода типа Code Signing
  • Создать самоподписанный SSL сертификат SHA-256 для IIS

New-SelfSignedCertificate: создать самоподписанный SSL сертификат в PowerShell

Для создания самоподписанного сертификата в PowerShell нужно использовать командлет New-SelfSignedCertificate, входящий в состав модуля PKI (Public Key Infrastructure).

Чтобы вывести список всех доступных командлетов в модуле PKI, выполните команду:

Get-Command -Module PKI

Самоподписанные SSL сертификаты рекомендуется использовать в тестовых целях или для обеспечения сертификатами внутренних интранет служб (IIS, Exchange, Web Application Proxy, LDAPS, ADRMS, DirectAccess и т.п.), в тех случая когда по какой-то причине приобретение сертификата у внешнего провайдера или разворачивание инфраструктуры PKI/CA невозможны.

Совет. Не забывайте, что вы можете использования полноценные бесплатные SSL сертификаты от Let’s Encrypt. Например, вы можете SSL сертификат Let’s Encrypt и привязать его к сайту IIS.

Для создания сертификата нужно указать значения

-DnsName (DNS имя сервера, имя может быть произвольным и отличаться от имени localhost) и -CertStoreLocation (раздел локального хранилища сертификатов, в который будет помещен сгенерированный сертификат).

Чтобы создать новый SSL сертификат для DNS имени test. contoso.com (указывается FQDN имя) и поместить его в список персональных сертификатов компьютера, выполните команду:

New-SelfSignedCertificate -DnsName test.contoso.com -CertStoreLocation cert:\LocalMachine\My

Команда вернет отпечаток нового сертификата (Thumbprint), Subject и EnhancedKeyUsageList. По умолчанию такой сертификат можно использовать для аутентификации клиента Client Authentication (1.3.6.1.5.5.7.3.2) или сервера Server Authentication (1.3.6.1.5.5.7.3.1).

По-умолчанию генерируется самоподписанный сертификат со следующим параметрами:

  • Криптографический алгоритм: RSA;
  • Размер ключа: 2048 бит;
  • Допустимые варианты использования ключа: Client Authentication и Server Authentication;
  • Сертификат может использоваться для: Digital Signature, Key Encipherment ;
  • Срок действия сертификата: 1 год.
  • Криптопровадер: Microsoft Software Key Storage Provider

Данная команда создаст новый сертификат и импортирует его в персональное хранилище компьютера. Откройте оснастку certlm.msc и проверьте, что в разделе Personal хранилища сертификатов компьютера появился новый сертификат.

С помощью командлета Get-ChildItem можно вывести все параметры созданного сертификата по его отпечатку (Thumbprint):

Get-ChildItem -Path "Cert:\LocalMachine\My" | Where-Object Thumbprint -eq 76360EAA92D958ECF2717261F75D426E6DB5B4D1 | Select-Object * 

PSPath                   : Microsoft.PowerShell.Security\Certificate::LocalMachine\My\76360EAA92D958ECF2717261F75D426E6
  DB5B4D1
PSParentPath             : Microsoft.PowerShell.Security\Certificate::LocalMachine\My
PSChildName              : 76360EAA92D958ECF2717261F75D426E6DB5B4D1
PSDrive                  : Cert
PSProvider               : Microsoft.
 
 PowerShell.Security\Certificate
PSIsContainer            : False
EnhancedKeyUsageList     : {Client Authentication (1.3.6.1.5.5.7.3.2), Server Authentication (1.3.6.1.5.5.7.3.1)}
DnsNameList              : {test.contoso.com}
SendAsTrustedIssuer      : False
EnrollmentPolicyEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty
EnrollmentServerEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty
PolicyId                 :
Archived                 : False
Extensions               : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,
                           System.Security.Cryptography.Oid, System.Security.Cryptography.Oid}
FriendlyName             :
HasPrivateKey            : True
PrivateKey               : System.Security.Cryptography.RSACng
IssuerName               : System.Security.Cryptography.X509Certificates.X500DistinguishedName
NotAfter                 : 12/2/2023 3:41:18 PM
NotBefore                : 12/2/2022 3:21:18 PM
PublicKey                : System.
 
 
 Security.Cryptography.X509Certificates.PublicKey
 RawData                  : {48, 130, 3, 45…}
SerialNumber             : 24682351DA9C59874573BA2B5BB39874
SignatureAlgorithm       : System.Security.Cryptography.Oid
SubjectName              : System.Security.Cryptography.X509Certificates.X500DistinguishedName
Thumbprint               : 76360EAA92D958ECF2717261F75D426E6DB5B4D1
Version                  : 3
Handle                   : 2007435579936
Issuer                   : CN=test.contoso.com
Subject                  : CN=test.contoso.com

Можно создать цепочку сертификатов. Сначала создается корневой сертификат (CA), а на основании него генерируется SSL сертификат сервера:

$rootCert = New-SelfSignedCertificate -Subject "CN=TestRootCA,O=TestRootCA,OU=TestRootCA" -KeyExportPolicy Exportable  -KeyUsage CertSign,CRLSign,DigitalSignature -KeyLength 2048 -KeyUsageProperty All -KeyAlgorithm 'RSA'  -HashAlgorithm 'SHA256'  -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider"
New-SelfSignedCertificate -CertStoreLocation cert:\LocalMachine\My -DnsName "test2.

contoso.com" -Signer $rootCert -KeyUsage KeyEncipherment,DigitalSignature

Чтобы изменить длину ключа сертификата и алгоритм шифрования, нужно использовать параметры –KeyAlgorithm , –KeyLength и –HashAlgorithm . Например:

New-SelfSignedCertificate -KeyAlgorithm RSA -KeyLength 2048 -HashAlgorithm "SHA256"

Если на компьютере доступен модуль TPM 2.0, можно использовать его для защиты ключа:

New-SelfSignedCertificate -Type Custom -Provider "Microsoft Platform Crypto Provider" ...

Провайдер Microsoft Platform Crypto Provider использует Trusted Platform Module чип устройства для создания ассиметричного ключа.

$Params = @{
"DnsName" = "mylocalhostname"
"CertStoreLocation" = "Cert:\\CurrentUser\\My"
"KeyUsage" = "KeyEncipherment","DataEncipherment","KeyAgreement"
"Type" = "DocumentEncryptionCert"
}
New-SelfSignedCertificate @Params

Как сгенерировать SAN (SubjectAltName) сертификат с помощью PowerShell?

Командлет New-SelfSignedCertificate позволяет создать сертификат с несколькими различными именами Subject Alternative Names (SAN).

Примечание. Утилита Makecert.exe, в отличии от командлета New-SelfSignedCertificate, не умеет создавать сертификаты с SAN.

Если создается сертификат с несколькими именами, первое имя в параметре DnsName будет использоваться в качестве CN (Common Name) сертификата. К примеру, создадим сертификат, у которого указаны следующие имена:

  • Subject Name (CN): adfs1.contoso.com
  • Subject Alternative Name (DNS): web-gw.contoso.com
  • Subject Alternative Name (DNS): enterprise-reg.contoso.com

Команда создания сертификата будет такой:

New-SelfSignedCertificate -DnsName adfs1.contoso.com,web_gw.contoso.com,enterprise_reg.contoso.com -CertStoreLocation cert:\LocalMachine\My

Также можно сгенерировать wildcard сертификат для всего пространства имен домена, для этого в качестве имени сервера указывается

*.contoso.com.

New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname *. contoso.com

Вы можете привязать сертификат не только к DNS имени, но и к IP адресу. Для этого вместе параметр -DnsName нужно использовать -TextExtension. Например:

New-SelfSignedCertificate -TextExtension @("2.5.29.17={text}IPAddress=10.10.2.3&DNS=TESTServer1&DNS=TESTServer1.local")

Как вы видите, в поле Subject Alternative Name теперь содержится IP адрес.

Экспорт самоподписаного сертификата в Windows

Для экспорта полученного сертификата c закрытым ключом в pfx файл, защищенный паролем, нужно получить его отпечаток (Thumbprint). Сначала нужно указать пароль защиты сертификата и преобразовать его в формат SecureString. Значение Thumbprint нужно скопировать из результатов выполнения команды New-SelfSignedCertificate.

$CertPassword = ConvertTo-SecureString -String “YourPassword” -Force –AsPlainText

Export-PfxCertificate -Cert cert:\LocalMachine\My\2779C0490D558B31AAA0CEF2F6EB1A5C2CA83B30 -FilePath C:\test. pfx -Password $CertPassword

Можно экспортировать открытый ключ сертификата:

Export-Certificate -Cert Cert:\LocalMachine\My\2779C0490D558B31AAA0CEF2F6EB1A5C2CA83B30 -FilePath C:\testcert.cer

Проверьте, что в указанном каталоге появился CER (PFX) файл сертификата. Если щелкнуть по нему правой клавишей и выбрать пункт меню Install Certificate, можно с помощью мастера импорта сертификатов добавить сертификат в корневые доверенные сертификаты компьютера.

Выберите Store location -> Local Machine, Place all certificates in the following store -> Trusted Root Certification Authorities.

Можно создать сертификат и сразу импортировать его в доверенные корневые сертификаты компьютера командами:
$cert=New-SelfSignedCertificate …..
$certFile = Export-Certificate -Cert $cert -FilePath C:\certname.cer
Import-Certificate -CertStoreLocation Cert:\LocalMachine\AuthRoot -FilePath $certFile. FullName

Полученный открытый ключ или сам файл сертификата можно распространить на все компьютеры и сервера в домене с помощью GPO (пример установки сертификата на компьютеры с помощью групповых политик).

Сгенерировать сертификат для подписи кода типа Code Signing

В PoweShell 3.0 командлет New-SelfSifgnedCertificate позволял генерировать только SSL сертификаты, которые нельзя было использоваться для подписывания кода драйверов и приложений (в отличии сертификатов, генерируемых утилитой MakeCert).

В версии PowerShell 5 командлет New-SelfSifgnedCertificate теперь можно использовать чтобы выпустить сертификат типа Code Signing.

Вы можете обновить версию PowerShell согласно инструкции.

Для создания самоподписанного сертфиката для подписывания кода приложений, выполните команду:

$cert = New-SelfSignedCertificate -Subject "Cert for Code Signing” -Type CodeSigningCert -CertStoreLocation cert:\LocalMachine\My

Теперь можно подписать ваш PowerShell скрипт эти сертификатом:

Set-AuthenticodeSignature -FilePath C:\PS\test_script. ps1 -Certificate $cert

Если при выполнении команды появится предупреждение UnknownError, значит этот сертификат недоверенный, т.к. находится в персональном хранилище сертификатов пользователя.

Нужно переместить его в корневые сертификаты (не забывайте периодически проверять хранилище сертификатов Windows на наличие недоверенных сертфикатов и обновлять списки корневых сертификатов):

Move-Item -Path $cert.PSPath -Destination "Cert:\CurrentUser\Root"

Теперь вы можете использовать этот самоподписанный сертификат для подписи PowerShell скриптов, драйверов или приложений.

Создать самоподписанный SSL сертификат SHA-256 для IIS

Обратите внимание, что при создании самоподписанный сертификат для IIS через консоль Internet Information Manager (пункт меню Create Self-Signed Certificate), создается сертификат с использованием алгоритма шифрования SHA-1. Такие сертификаты многими браузерами считаются недоверенными, поэтому они могут выдавать предупреждение о небезопасном подключении. Командлет New-SelfSignedCertificate позволяет создать более популярный тип сертификата с помощью алгоритма шифрования SHA-256.

Вы можете привязать самоподписанный сертификат SHA-256, созданный в PowerShell, к сайту IIS. Если вы с помощью PowerShell создали SSL сертификат и поместили его в хранилище сертификатов компьютера, он будет автоматически доступен для сайтов IIS.

Запустите консоль IIS Manager, выберите ваш сайт, затем в настройке Site Binding, выберите созданный вами сертификат и сохраните изменения.

Также можно привязать SSL сертификат к сайту IIS по его отпечатку:

New-IISSiteBinding -Name "Default Web Site" -BindingInformation "*:443:" -CertificateThumbPrint $yourCert.Thumbprint -CertStoreLocation "Cert:\LocalMachine\My" -Protocol https

Онлайн Генератор Самоподписанного SSL Сертификата для Сайта, Создать Самоподписанный SSL Сертификат Бесплатно

self-signed certificate

Введите имя сайта

Создать SSLСоздать

Самоподписанный SSL сертификат может использоваться для настройки и работы с SSL средой во время разработки. Вы можете использовать такой самоподписанный SSL сертификат, когда безопасность не требуется, например, для веб-серверов, предназначенных для тестирования и отладки, а также персональных веб-сайтов и веб-порталов. Чтобы создать самоподписанный SSL сертификат, введите имя сайта (пример: mysite.com) и нажмите ‘Создать SSL’.

Использование SSL сертификатов
Сертификаты SSL необходимы, когда вам нужно открывать веб-сайты, используя HTTPS протокол. Профессиональным веб-сайтам требуются профессиональные надежные SSL сертификаты центров SSL сертификации, таких как Comodo, Symantec, Thawte, GeoTrust, RapidSSL. Доверенные SSL сертификаты используют цепочку доверия, где каждый сертификат подписан (доверен) более высоким и более надежным сертификатом. В верхней части цепочки доверия находятся корневые сертификаты, принадлежащие Verisign или GeoTrust. Такие корневые сертификаты обычно поставляются с вашей операционной системой или веб-браузером.

Как браузер анализирует SSL ответ
Когда вы посещаете веб-сайт по HTTPS протоколу, ваш веб-браузер получает SSL сертификат для веб-сайта. Он проверяет SSL сертификат, чтобы убедиться, что он действительно выдан для этого имени домена, которое вы открываете. После этого он проверит цепочку доверия и кто его подписал. Если этот SSL сертификат является корневым сертификатом, браузер сравнит его с теми, которые поставляются с операционной системой. Если это сертификат не корневой но подписан доверенным SSL сертификатом, он проверит всю цепочку доверия.

При использовании самоподписанного SSL сертификата у него нет цепочки доверия. Сертификат подписан самим собой. Веб-браузер обнаружит это и покажет предупреждение, сообщая вам, что сертификат веб-сайта не трастовый. Поэтому не стоит использовать самоподписанные SSL сертификаты для профессионального использования, так как ваши посетители не будут доверять вашему веб-сайту и могут отказаться от его использования.

Реальные трастовые SSL сертификаты
Настоящие доверенные SSL сертификаты безопасны и защищённы, браузеры доверяют им, а все посетители не получают никаких SSL предупреждений. Мы предоставляем огромное количество настоящих трастовых SSL сертификатов, каждый может найти наиболее подходящий SSL продукт.

Бесплатное облачное онлайн пространство для Ваших SSL Сертификатов и Приватных ключей

Используя SSL Cертификаты от Regery Вы получаете быстрое и бесплатное облачное хранилище для всех Ваших SSL Сертификатов, Промежуточных Сертификатов (CA Bundle), CSR Кодов и Приватных RSA Ключей. В случае, утери ССЛ Сертификата, Вы всегда можете его скачать из панели управления SSL сертификатами на Regery.

Как сгенерировать самозаверяющий 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 = test@example. com
# Раздел 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-адрес.

ssl — Как создать самозаверяющий сертификат для доменного имени для разработки в Windows 10 и ниже?

Мне пришлось ломать голову над самозаверяющими сертификатами в Windows, комбинируя кусочки из полученных ответов и дополнительных ресурсов. Вот мое собственное (и, надеюсь, полное) пошаговое руководство. Надеюсь, это избавит вас от моей собственной болезненной кривой обучения. Он также содержит информацию по связанным темам, которые рано или поздно появятся, когда вы создадите свои собственные сертификаты.

Создайте самозаверяющий сертификат в Windows 10 и более ранних версиях

Не используйте makecert.exe. Microsoft устарела.
Современный способ использует команду Powershell.

Windows 10:

Откройте Powershell с правами администратора:

 New-SelfSignedCertificate -DnsName "*.dev.local", "dev.local", "localhost" -CertStoreLocation cert:\LocalMachine\My -FriendlyName " Сертификат разработчика *.dev.local, dev.local, localhost" -NotAfter (Get-Date).AddYears(15)

Windows 8, Windows Server 2012 R2:

В Powershell на этих системах параметры -FriendlyName и -NotAfter не существуют. Просто удалите их из приведенной выше командной строки.
Откройте Powershell с правами администратора:

 New-SelfSignedCertificate -DnsName "*.dev.local", "dev.local", "localhost" -CertStoreLocation cert:\LocalMachine\My

Альтернативой является использование описанного ниже метода для более старой версии Windows, который позволяет использовать все функции Win 10 для создания сертификата…

Старые версии Windows:

Моя рекомендация для более старых версий Windows — создать сертификат на компьютере с Win 10, экспортировать его в файл .PFX с помощью экземпляра mmc (см. «Доверять сертификату» ниже) и импортировать его. в хранилище сертификатов на целевой машине со старой ОС Windows. Чтобы импортировать сертификат, НЕ щелкайте его правой кнопкой мыши. Хотя в контекстном меню есть пункт «Импорт сертификата», все мои попытки использовать его на Win Server 2008 не увенчались успехом. Вместо этого откройте другой экземпляр mmc на целевой машине, перейдите к «Сертификаты (локальный компьютер)/Личные/Сертификаты». , щелкните правой кнопкой мыши среднюю панель и выберите Все задачи → Импорт.

Полученный сертификат

Обе приведенные выше команды создают сертификат для доменов localhost и *.dev.local .
Версия Win10 дополнительно имеет срок службы 15 лет и удобочитаемое отображаемое имя «Dev Cert *.dev.local, dev.local, localhost».

Обновление: Если вы укажете несколько записей имени хоста в параметре -DnsName (как показано выше), первая из этих записей станет субъектом домена (или общим именем). Полный список всех записей имени хоста будет храниться в поле Альтернативное имя субъекта (SAN) сертификата. (Спасибо @BenSewards за указание на это.)

После создания сертификат будет немедленно доступен в любых HTTPS-привязках IIS (инструкции ниже).

Доверяйте сертификату (на машине, где вы его создали)

Новый сертификат не является частью какой-либо цепочки доверия и поэтому не считается заслуживающим доверия ни одним браузером. Чтобы изменить это, мы скопируем сертификат в хранилище сертификатов для доверенных корневых ЦС на вашем компьютере:

Откройте mmc.exe, Файл → Добавить/удалить оснастку → выберите «Сертификаты» в левом столбце → Добавить → выберите «Компьютер». Учетная запись» → «Далее» → «Локальный компьютер…» → «Готово» → «ОК»

В левой колонке выберите «Сертификаты (Локальный компьютер)/Личные/Сертификаты».
Найдите только что созданный сертификат (в Win 10 может помочь столбец «Понятное имя»).
Выберите этот сертификат и нажмите Ctrl-C, чтобы скопировать его в буфер обмена.

В левой колонке выберите «Сертификаты (локальный компьютер)/Доверенные корневые центры сертификации/Сертификаты».
Нажмите Ctrl-V, чтобы вставить свой сертификат в это хранилище.
Сертификат должен появиться в списке доверенных корневых центров и теперь считается заслуживающим доверия.

Доверять сертификату (на другой машине)

Чтобы доверять тому же сертификату на другой машине, вы должны экспортировать его на машину, на которой вы его создали, и импортировать на другую машину.

На исходном компьютере в MMC щелкните правой кнопкой мыши сертификат → Все задачи → Экспорт. Экспорт без(!) приватного ключа в формат .DER.

Затем скопируйте полученный файл на целевую машину, щелкните правой кнопкой мыши и установите сертификат в хранилище «Локальный компьютер/Доверенные корневые центры сертификации». После этого все приложения, использующие хранилище сертификатов Windows (например, Chrome и IE, но НЕ Firefox), должны доверять вашему самоподписанному сертификату.

Использование в IIS

(Мы вернулись на машину, где вы создали новый сертификат!)

Теперь вы можете перейти в Диспетчер IIS, выбрать привязки локального веб-сайта → Добавить → https → ввести хост имя вида myname.dev.local (ваш сертификат действителен только для *.dev.local ) и выберите новый сертификат → ОК.

Добавить к хостам

Также добавьте имя хоста в C:\Windows\System32\drivers\etc\hosts:

 127. 0.0.1 мое имя.dev.local

Happy

Теперь Chrome и IE должны считать сертификат заслуживающим доверия и загружать ваш сайт при открытии https://myname.dev.local .

Firefox поддерживает собственное хранилище сертификатов. Чтобы добавить сюда свой сертификат, вы должны открыть свой веб-сайт в FF и добавить его в исключения, когда FF предупредит вас о сертификате.

Для браузера Edge могут потребоваться дополнительные действия (см. ниже).

Проверка сертификата

Для проверки сертификатов лучшим выбором будет Firefox. (Поверьте мне, я сам фанат Chrome, но FF в этом случае лучше.)

Вот причины:

  • Firefox использует собственный SSL-кэш, который очищается при Shift-Reload. Таким образом, любые изменения в сертификатах ваших локальных веб-сайтов будут немедленно отражены в предупреждениях FF, в то время как другим браузерам может потребоваться перезапуск или ручная очистка кеша Windows SSL.
  • Также FF дает вам несколько ценных советов по проверке действительности вашего сертификата: Нажмите «Дополнительно», когда FF отобразит предупреждение о сертификате. FF покажет вам короткий текстовый блок с одним или несколькими возможными предупреждениями в центральных строках текстового блока:

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

Это предупреждение верно! Как отмечалось выше, Firefox не использует хранилище сертификатов Windows и будет доверять этому сертификату только в том случае, если вы добавите для него исключение прямо в Firefox. Кнопка для этого находится прямо под предупреждениями.

Сертификат недействителен для имени…

Это предупреждение показывает, что вы сделали что-то не так. (Подстановочный) домен вашего сертификата не соответствует домену вашего веб-сайта. Проблема должна быть решена либо путем изменения (суб)домена вашего веб-сайта, либо путем выпуска нового соответствующего сертификата. На самом деле вы можете добавить исключение в FF, даже если сертификат не совпадает, но вы никогда не получите зеленый символ замка в Chrome с такой комбинацией.

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

Какой шаблон (под)домена выбрать для разработки?

В приведенной выше команде New-SelfSignedCertificate мы использовали подстановочный домен *.dev.local .

Вы можете подумать: почему бы не использовать *.local ?

Простая причина: это незаконный домен с подстановочными знаками.
Подстановочные сертификаты должны содержать по крайней мере буквальное доменное имя второго уровня. Звездочка (*) допускается только с третьего уровня и выше.

Итак, домены вида xyz.local подходят, когда вы разрабатываете под HTTP и вам не нужны сертификаты. Но если вы используете этот шаблон домена с HTTPS, вам придется выпускать новый соответствующий сертификат для каждого нового проекта, который вы начинаете. Лучше использовать домены вида xyz.dev.local и один групповой сертификат для *.dev.local .

Важные примечания:

  • Действительные домены хостов могут содержать ТОЛЬКО буквы от a до z, цифры, дефисы и точки. Подчеркивания не допускаются! Некоторые браузеры очень придирчивы к этой детали и могут доставить вам неприятности, когда упорно отказываются сопоставлять ваш домен motör_head.dev.local с шаблоном подстановки *.dev.local . Они будут подчиняться, когда вы переключитесь на motoer-head.dev.local .
  • Подстановочный знак в сертификате будет соответствовать только ОДНОЙ метке (= разделу между двумя точками) в домене и никогда больше. *.dev.local соответствует myname.dev.local , но НЕ other.myname.dev.local !
  • Многоуровневые подстановочные знаки ( *.*.dev.local ) НЕ возможны в сертификатах. Таким образом, other.