There are times you would want to create a SAN (Subject Alternative Name) certificate for your deployments in the organization. This is a much more secure approach as compared to using a wildcard as it allows only a limited number of servers to send and receive traffic. Unless you specifically compromise one of the machines specified in the certificate, it’s too hard to impersonate and do any real harm.
In this blog post, I will show you how to create a CSR (Certificate Signing Request) using any Windows machine in the organization that’s domain joined and subsequently, use the request file to issue a certificate using the internal Certification Authority (CA) server.
Create a Certificate Signing Request (CSR)
The first step is to create a CSR file and you can use any domain joined Windows server in the organization. I have used the Citrix Storefront server in this example.
Open the MMC console and add the Certificate snap-in to it as Local Computer. Right Click Personal node on the left and Select All Tasks –> Advanced Operations –> Create Custom Request
Choose Proceed without enrollment policy and Click Next. Choose No Template Legacy Key for compatibility reasons. Use PKCS#10
Click Next and click Properties
Give a friendly name for the certificate and a description. Ensure that you hit Apply as soon as you are done with the tab.
Click on Subject tab and add all the hostnames under “Alternative Name“
Under Subject Name, enter the Common Name (CN), Organizational Unit (OU), Organization (O), State (S) and Country (C) values. Click Apply
Under the Extensions tab, expand Extended Key Usage (application policies) and select Server Authentication and Client Authentication
Click Apply
Under the Private Key tab, set the Key size to 2048 under Key options
P.S – Using a key size of 4096 or above will cause issues with NetScaler monitors failing if VPXs are used. MPXs don’t have this issue.
Tick Make Private Key exportable
Select Exchange as the Key type
Click Apply. Click OK
Select a location to save the file. Choose the file format as Base 64
Click Finish
Send the Certificate Request
Now navigate to the URL of the internal Certificate Authority (CA) server. Replace your CA server name for the <certauthority> value.
https://certauthority/certsrv
- Click the Request a Certificate link.
- Click the Advanced certificate request link.
- Click Submit a certificate.
- Paste the contents of your CSR file into the Saved Request text box. (Open the CSR file (with a .req extension) in Notepad and copy the contents without any leading or trailing spaces.)
- For the Certificate Template drop-down list, select Web Server.
- Click Submit.
You get the below once you click submit.
Issue the Certificate
- Connect to the server where the Certification Authority is installed, if necessary.
- Select Start > Control Panel > Administrative Tools > Certification Authority.
- In the Certification Authority (Local) tree, select Your Domain Name > Pending Requests.
- Select the CSR in the right navigation pane.
- In the Action menu, select the ID number of the request > Issue.
- Close the Certification Authority window.
Download the Certificate
- In your web browser address bar, type the IP address of the server where the Certification Authority is installed, followed by certsrv.
- Click the View the status of a pending certificate request link.
- Select the certificate request with the time and date you submitted.
- Select the encoding format for the downloaded certificate, such as Base 64 for a PEM certificate.
- Click Download CA certificate to save the certificate. The certificate will have .CER extension
Install the Certificate
- Navigate to the server where the certificate needs to be installed.
- Open a MMC console as Administrator and add Certificate snap-in under Local Computer
- Expand Personal node and right click the Certificates node.
- Select All Tasks –> Import
- Click Next
- Locate the downloaded certificate file
- Click Next
- Place it under Personal node
- Click Next
- Click Finish
Note – The installed certificate in Certificate MMC shows a little key symbol and a badge. You gotta see these 2 things for the certificate to work or show up in IIS Manager in later steps.
Export the certificate as a .PFX file
Now, you need to export the certificate as a PFX file so that this could be installed on all the other servers which doesn’t have any clue of the privaty key used while requesting the CSR. If you recall, we did the CSR from one of the Storefront servers. The PFX certificate files contains the private key which is paramount for SSL deployments.
- Navigate to the server where the certificate has been already installed.
- Open a MMC console as Administrator and add Certificate snap-in under Local Computer
- Expand Personal node and right click the Certificates node.
- Select All Tasks –> Export
- Click Next
- Export the private key
- Click Next
- Under the Personal Interchange Format, PKCS#12, Tick all except for “delete the private key after successful export”
- Click Next
- Give it a password of your choice (make sure that you remember this; This is required for installing the certs on other servers)
- Specify a file name to save it in a location
- Click Next
- Click Finish
Bind the website in IIS
- Open IIS Manager and expand the Server name and choose the Default Web Site
- Under Actions, select Bindings
- Add the https and select the newly installed certificate
- Click OK
Install the exported PFX certificate on the other servers and change the binding to https following the steps above. That’s all to it folks.
If there is anything that’s unclear, please feel free to comment or provide feedback in the comment section below.
По умолчанию в центре сертификации, сертификаты могут быть привязаны к одному FQDN. Это не всегда удобно, иногда требуется создать один сертификат для нескольких доменных имён. Для создания сертификатов с альтернативными доменными именами нужно в центре сертификации включить функцию SAN.
SAN (Subject Alternative Name) — расширение спецификации X.509 (формат X.509 определён в RFC 5280, обновлён в RFC 6818) позволяет добавлять в сертификат безопасности дополнительные значения, используя поле subjectAltName. Можно добавлять:
- otherName — Пары type=, value=, включая имена Kerberos (RFC 4556): oid = 1.3.6.1.5.2.2, kerberos-principal (IA5String), или SRVName (RFC 4985): oid = 1.3.6.1.5.5.7.8.7, srv-name (IA5String)
- rfc822Name— email me@example.com
- dNSName — DNS-имя host1.example.com
- x400Address — Почтовый адрес X.400,если Вы в курсе, что это
- directoryName — Альтернативный DN
- ediPartyName — Материалы EDI
- uniformResourceIdentifier — URI ldap://ldap.example.com
- iPAddress — IP V4/V6 192.168.0.1
- registeredID — OID
По RFC имена не чувствительны к регистру. Разрешается присутствие нескольких записей, использование subjectAltName решает проблему нескольких имён DNS у одного сервера, плюс IP.
В этом нам поможет утилита certutil.
Запускаем в центре сертификации командную строку под администратором. Выполняем команду:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
После выполнения команды нужно перезапустить службу Certification Authority. Делаем это сразу из командной строки:
net stop certsvc && net start certsvc
Для добавления IP и альтернативного доменного имени при генерации сертификата указываем дополнительные атрибуты.
Синтаксис такой:
san:ipaddress=10.11.12.13&dns=vcenter.domain1.local&dns=vcenter.domain2.local&dns=vcenter&dns=vcenter-machineБольшинству администраторов 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).
Если вы запустите эту команду в PowerShell без прав администратор, появится ошибка:
New-SelfSignedCertificate : CertEnroll::CX509Enrollment::_CreateRequest: Access denied. 0x80090010 (-2146893808 NTE_PERM)
Если вы указали нестандартный криптографический провайдер CSPs (например, с помощью параметров
-KeyAlgorithm "ECDSA_secP256r1" -Provider 'Microsoft Smart Card Key Storage Provider'
), убедитесь, что он установлен на компьютере (по умолчанию используется CSP Microsoft Enhanced Cryptographic Provider). Иначе появится ошибка:
New-SelfSignedCertificate: CertEnroll::CX509Enrollment::_CreateRequest: Provider type not defined. 0x80090017 (-2146893801 NTE_PROV_TYPE_NOT_DEF).
По-умолчанию генерируется самоподписанный сертификат со следующим параметрами:
- Криптографический алгоритм: 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
Примечание. Срок действия такого самоподписанного сертификата истекает через 1 год с момента его создания. Можно задать другой срок действия сертификата с помощью атрибута —NotAfter.Чтобы выпустить сертификат на 3 года, выполните следующие команды:
$todaydate = Get-Date
$add3year = $todaydate.AddYears(3)
New-SelfSignedCertificate -dnsname test.contoso.com -notafter $add3year -CertStoreLocation cert:\LocalMachine\My
Можно создать цепочку сертификатов. Сначала создается корневой сертификат (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
Please refer to the steps below on how to generate CSR from Windows Server with SAN (Subject Alternative Name) as SSL certificates generated from IIS do not contain a SAN
Google Chrome requires SSL certificates to use SAN (Subject Alternative Name) instead of the popular Common Name (CN) since version 58 – https://www.thesslstore.com/blog/security-changes-in-chrome-58/
- Run “certlm.msc” to open the Certificate – Local Computer
- Right click on Personal and select All Tasks – Advanced Operations – Create Custom Request
- Click Next
- Select Custom Request – Proceed without enrollment policy and click Next
- Click Next
- Expand Detail and click on Properties
- Enter Name & Description
- Select DNS with *.aventislab.com – this will be the SAN (Subject Alternative Name) included in our SSL Certificate
- Change the Key Size to 2048 and Check Make Private Key Exportable
- Enter C:\temp\aventislab.req to export the CSR File
- Login to LAB-AD01 which is our Enterprise Root CA Server, and run “certreq -submit -attrib “CertificateTemplate:webserver” C:\temp\aventislab.req C:\temp\aventislab.cer” to generate the aventislab.cer file
certreq -submit -attrib "CertificateTemplate:webserver" C:\temp\aventislab.req C:\temp\aventislab.cer
Active Directory Enrollment Policy
{C14446F0-EC5A-4A11-8BCD-EC6B0044C156}
ldap:
RequestId: 7
RequestId: "7"
Certificate retrieved(Issued) Issued
Import the SSL Certificate and generate the PFX File
- Go to Certificate – Local Computer and select Import
- Select c:\temp\aventislab.cer
- Place the certificate in Personal
- Verify the SAN (Subject Alternative Name) is included
- Right click *.aventislab.com and select Export
- Select Yes, export the private key
- Click Next
- Enter Password for the Private Key
- Export the PFX file to C:\temp\aventislab.pfx
We can keep the PFX file and import it to Microsoft Exchange Server or IIS Web Server later.
Contents of this directory is archived and no longer updated.
Достаточно часто администраторы занимаются выпуском сертификатов с использованием нескольких имён. Например, когда нужно привязать один сертификат к нескольким именам: mail.company.com и owa.compny.com. Однако поле Subject может содержать только одно имя. Для разрешения этой проблемы используется расширение Subject Alternative Name (SAN). В этом расширении вы можете использовать сколько угодно дополнительных имён для сертификата.
Но как правильно же оформить несколько имён в сертификате на примере mail.company.com и owa.company.com? Здесь варианта всего 2:
- Использовать поле Subject и расширение SAN
Данный способ используется чаще для внешних сертификатов. Поле Subject заполняется следующим образом (красным выделены обязательные компоненты):
CN = mail.company.com
OU = <название подразделения>
OU = <ещё какое-то название подразделения>
O = <название организации>
L = <местоположение компании>
C = <код страны, где расположена компания>
Т.е. включается основное имя сертификата (по правде говоря, при использовании SAN, понятие основного имени отсутствует, т.к. все имена считаются равноценными. Здесь следует указывать имя, которое будет использоваться чаще всего приложениями, неподдерживающими расширение SAN) и опционально можно задать дополнительные DN суффиксы, отражающие принадлежность сертификата. И расширение SAN заполняется следующим образом:
DNS Name=mail.company.com
DNS Name=owa.company.com
Как видите, имя из Subject продублировано в SAN. Дело в том, что если в сертификате есть расширение SAN и приложение умеет его обрабатывать, приложение как правило настраивается только на проверку расширения SAN и в Subject они не заглядывают. Но это не всегда так. Иногда приложение смотрит и в Subject и в SAN. В таком случае имена дублировать не обязательно. Но в целях обеспечения совместимости следует ВСЕГДА дублировать имя из Subject в расширении SAN.
- Использовать только расширение SAN
Этот способ редко применяется во внешних сертификатах, а только внутренних. В этом случае поле Subject не заполняется совсем и оставляется пустым. А расширение SAN будет включать все необходимые имена:
DNS Name=mail.company.com
DNS Name=owa.company.com
Такая форма заполнения поддерживается в Internet PKI и описана в RFC 5280. Согласно этому RFC, если поле Subject не определено (пусто), имя для сертификата выбирается из расширения SAN, а само расширение помечается как критичное (см. RFC 5280 §4.2.1.6). Вот примерные пруфпики, как это выглядит в жизни:
на вкладке General имя формируется либо из первого имени в расширении SAN или из имени используемого конкретным приложением (например, при просмотре из браузера) и котрое перечислено в расширении SAN.
Здесь продемонстрировано пустое поле Subject.
И перечисление необходимых имён в расширении SAN. Критичность расширения определяется по наличию жёлтого треугольничка и восклицательного знака.
На заметку: что такое критичное расширение (critical extension)? Это просто расширение, которое приложение должно проверить в обязательном порядке. Если приложение видит такое расширение, приложение должно уметь его обработать и понять значение в этом расширении. Если приложение не знает, что делать с этим расширением или приложение не может разобрать значение этого расширения, приложение обязано отклонить данный сертификат. Более подробно о порядке поведения приложения.
Примечание: хоть и заявляется, что приложение должно отклонить сертификат, если значение расширения непонятно, это не в полной мере относится к расширению SAN. Приложение не обязано поддерживать все формы SAN, а может поддерживать только некоторые формы, например, только DNS Name. Но если поддерживаемая форма не может быть распознана, сертификат должен быть отклонён.
Поскольку расширение SAN является единственным средством идентификации имени сертификата, вполне логично ожидать, что это расширение будет помечено как критичное и обязательное для обработки приложением.
Какой способ из двух выбрать? А какой считаете более приемлемым. Если это сертификат внешнего веб-сервера, целесообразно использовать первый вариант, поскольку при помощи DN суффиксов можно конкретизировать принадлежность сертификата к вашей компании. А так же если предполагается доступ из приложений неподдерживающих расширение SAN. Это не обязательно компьютерные приложения, это могут быть приложения мобильных устройств. В целях избежания чрезмерного пиара VeriSign’a в моём бложике, представляю образцово-показательный сертификат выполненный первым способом на сайте Thawte: https://www.thawte.com/
Для использования внутри организации можно использовать и второй вариант, с пустым Subject. Например, для логонных сертификатов смарт-карт. Контроллеры домена вообще не смотрят на Subject логонного сертификата, а смотрят только в SAN на предмет наличия UPN в расширении.
Что бы почитать?
- RFC 5280
- Web server certificate enrollment with SAN extension