Сбой подчиненного ЦС Windows server 2012, поскольку отзыв был выполнен в автономном режиме при использовании сертификата корневого ЦС из корневого ЦС Linux / OpenSSL

Хорошо, теперь лучше. Здесь у вас есть ряд проблем:

  Wrong Issuer "Certificate (0)" Time: 0
    [0.0] ldap:///CN=example-TESTPKI-CA,CN=AIA,CN=Public%20Key%20Services,
Services,CN=Configuration,DC=example,DC=com?cACertificate?base?objectCla
certificationAuthority

Эта ошибка указывает на то, что в Active Directory опубликован неправильный сертификат subCA. Вам нужно будет повторно опубликовать сертификат subCA в Active Directory, выполнив следующую команду:

certutil -dspublish -f SubCA.cer SubCA

Теперь ваш корневой ЦС:

  Failed "AIA" Time: 0
    Error retrieving URL: The request is not supported. 0x80070032 (WIN32: 50
ROR_NOT_SUPPORTED)
    testpki.example.com/crld/root.cer

вы неправильно ввели URL-адрес в конфигурации OpenSSL. Префикс протокола отсутствует. Вам нужно добавить http:// префикс и перевыпустить сертификат SubCA.

  Failed "CDP" Time: 0
    Error retrieving URL: Not found (404). 0x80190194 (-2145844844 HTTP_E_STA
_NOT_FOUND)
    http://testpki.example.com/crld/rootca.crl

Этот URL-адрес кажется правильным (по крайней мере, он включает префикс протокола), сервер CA может получить доступ к веб-серверу, но веб-сервер отвечает 404, указывая, что на запрошенном пути нет ничего.

TBH, ваша установка совсем не хороша. У вас слишком много проблем, потому что (как кажется) дизайн не был спланирован или план не был проверен.

Помимо явных проблем, ваш корневой ЦС сам включает в себя расширения точек распространения списков отзыва сертификатов (CDP) и доступа к информации о полномочиях (AIA), которые являются избыточными. Вы должны удалить их из корневого сертификата. AIA не используется, чтобы избежать циклов при построении пути. CDP в корневых сертификатах не используется, потому что вы не можете отозвать корневой (самоподписанный) сертификат из-за проблемы с куриным яйцом. Но они (расширения CDP и AIA) должны быть включены в выпущенный сертификат (то есть подчиненный CA).

Я бы рекомендовал откатить все, что вы здесь сделали, и начать с нуля.

Прежде всего, нужно спроектировать свое решение, спланировать все аспекты.

1. Определите приложения, которые будут использовать сертификаты.
2. Опишите требования к сертификатам и спланируйте объем сертификатов.
3. На основе [2] определите шаблоны сертификатов и их конфигурацию, которую вы будете использовать.
4. Разработайте схему размещения ЦС и создайте диаграмму потока сертификатов (регистрация сертификатов, проверка клиентскими приложениями).
5. Разработайте план аварийного восстановления, который будет включать план резервного копирования и восстановления.

В противном случае ваше решение ничего не будет стоить. Даже если это тестовое развертывание, вам все равно придется пройти все эти шаги.

Правильно спланируйте публикацию CRT / CRL и загрузите URL-адреса. Вам нужно будет проверить это дважды, потому что эти проблемы невозможно легко исправить без повторного развертывания всех сертификатов. Общие предложения по этому поводу:

1. не используйте URL-адреса LDAP в CDP / AIA. Рассмотрите возможность использования только HTTP.
2. использовать выделенный веб-сервер для обслуживания файлов CRT / CRL (не объединяйте SubCA с ролями веб-сервера).
3. не используйте расширения CDP / AIA в корневом сертификате
4. убедитесь, что файлы CRT / CRL доступны для всех клиентов (которые будут использовать ваши сертификаты)

Что касается планирования расширения CDP / AIA, я бы посоветовал проверить свой пост в блоге: Проектирование точек распространения CRL и мест доступа к информации о полномочиях. Хотя статья написана против Microsoft CA, те же принципы применимы к любой другой реализации CA, потому что это лучшие практики.

Мне удалось запустить тестовый промежуточный ЦС. Скорее всего, проблема была в моем файле конфигурации OpenSSL, в частности, в битах CDP и AIA. Но для всех, кто может пытаться достичь чего-то подобного, я опишу, что я сделал, что в итоге сработало.

Перед запуском вы должны взглянуть на ссылку, предоставленную Crypt32, ее можно найти Вот.

Во-первых, для разрешения имен DNS настройте записи A на сервере, на котором запущена служба DNS, которая присоединена к домену, вам потребуются записи как для вспомогательного центра сертификации, так и для сервера IIS. Также убедитесь, что сервер Windows, который будет использоваться в качестве промежуточного центра сертификации, настроен на использование этого DNS-сервера для разрешения адресов.

В корневом ЦС Linux
• Создайте каталог для вашего центра сертификации

  mkdir -p ./ca/{certs,private}  
  
  chmod 700 ./ca/private  
  
  touch index.txt  
  
  echo 0001 > serial  
  
  echo 0001 > crlnumber
  

• скопируйте этот файл конфигурации, необходимые изменения в каталог ca корневого центра сертификации Linux

    
  #
  # OpenSSL configuration file.
  #
  
  # Establish working directory.
  
  ROOT_CA_FILENAME                        = rootca           #example ca filename
  HTTP_HOST                               = pki.example.local #example URL for CDP
  
  dir                                     = .
  
  default_ca                              = CA_Default
  
  [ CA_Default ]
  serial                                  = $dir/serial
  database                                = $dir/index.txt
  new_certs_dir                           = $dir/certs
  crlnumber                               = $dir/crlnumber
  default_crl_days                        = 213
  default_md                              = sha256
  preserve                                = no
  email_in_dn                             = no
  nameopt                                 = default_ca
  certopt                                 = default_ca
  policy                                  = policy_any
  private_key                             = $dir/private/$ROOT_CA_FILENAME.key.pem
  certificate                             = $dir/certs/$ROOT_CA_FILENAME.cert.pem
  
  # SET in script: default_days                            = 7305 
  
  
  [ policy_any ]
  countryName                             = optional
  stateOrProvinceName                     = optional
  localityName                            = optional
  organizationName                        = optional
  organizationalUnitName                  = optional
  commonName                              = supplied
  emailAddress                            = optional
  
  [ req ]
  # Options for the `req` tool (`man req`).
  default_bits        = 4096
  distinguished_name  = req_distinguished_name
  string_mask         = utf8only
  
  # SHA-1 is deprecated, so use SHA-2 instead.
  default_md          = sha256
  
  # Extension to add when the -x509 option is used.
  x509_extensions     = v3_ca
  
  [ req_distinguished_name ]
  # See .
  countryName                     = Country Name (2 letter code)
  stateOrProvinceName             = State or Province Name
  localityName                    = Locality Name
  0.organizationName              = Organization Name
  organizationalUnitName          = Organizational Unit Name
  commonName                      = Common Name
  emailAddress                    = Email Address
  
  # Optionally, specify some defaults.
  countryName_default             = 
  stateOrProvinceName_default     = 
  localityName_default            =
  0.organizationName_default      = 
  organizationalUnitName_default  =
  emailAddress_default            =
  
  [ v3_ca ]
  # Extensions for a typical CA (`man x509v3_config`).
  subjectKeyIdentifier = hash
  authorityKeyIdentifier = keyid:always,issuer
  basicConstraints = critical, CA:true
  keyUsage = critical, digitalSignature, cRLSign, keyCertSign
  
  [ v3_intermediate_ca ]
  # Extensions for a typical intermediate CA (`man x509v3_config`).
  subjectKeyIdentifier = hash
  authorityKeyIdentifier = keyid:always,issuer
  basicConstraints = critical, CA:true, pathlen:0
  keyUsage = critical, digitalSignature, cRLSign, keyCertSign
  crlDistributionPoints = URI:http://$HTTP_HOST/crldist/$ROOT_CA_FILENAME.crl
  authorityInfoAccess = caIssuers;URI:http://$HTTP_HOST/crldist/$ROOT_CA_FILENAME.crt
  
  [ usr_cert ]
  # Extensions for client certificates (`man x509v3_config`).
  basicConstraints = CA:FALSE
  nsCertType = client, email
  nsComment = "OpenSSL Generated Client Certificate"
  subjectKeyIdentifier = hash
  authorityKeyIdentifier = keyid,issuer
  keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
  extendedKeyUsage = clientAuth, emailProtection
  
  [ server_cert ]
  # Extensions for server certificates (`man x509v3_config`).
  basicConstraints = CA:FALSE
  nsCertType = server
  nsComment = "OpenSSL Generated Server Certificate"
  subjectKeyIdentifier = hash
  authorityKeyIdentifier = keyid,issuer:always
  keyUsage = critical, digitalSignature, keyEncipherment
  extendedKeyUsage = serverAuth
  
  [ crl_ext ]
  # Extension for CRLs (`man x509v3_config`).
  authorityKeyIdentifier=keyid:always
  
  [ ocsp ]
  # Extension for OCSP signing certificates (`man ocsp`).
  basicConstraints = CA:FALSE
  subjectKeyIdentifier = hash
  authorityKeyIdentifier = keyid,issuer
  keyUsage = critical, digitalSignature
  extendedKeyUsage = critical, OCSPSigning
  
  

• Создайте пару ключей

   
  openssl genrsa -aes256 -out private/rootca.key.pem 4096  
  chmod 400 private/rootca.key.pem  
  openssl req -config /path/to/config \  
  -key private/rootca.key.pem \  
  -new -x509 -days 1825 -sha256 -extensions v3_ca \  
  -out certs/rootca.cert.pem  
  
  Enter pass phrase for ca.key.pem: secretpassword
  You are about to be asked to enter information that will be incorporated
  into your certificate request.
  -----
  Country Name (2 letter code) [XX]:.
  State or Province Name []:.
  Locality Name []:.
  Organization Name []:.
  Organizational Unit Name []:.
  Common Name []:Test Root CA
  Email Address []:.
  
  chmod 444 certs/rootca.cert.pem
  

На сервере Windows под управлением IIS
• Откройте диспетчер IIS
• Разверните каталог на левой панели и щелкните правой кнопкой мыши «Сайт по умолчанию». Выберите добавить виртуальный каталог
• В диалоговом окне добавления виртуального каталога в разделе «Псевдоним» введите все, что вы использовали для URL-адресов CDP и AIA, в файле конфигурации OpenSSL выше.
• В разделе «Физический путь» введите путь к каталогу, который вы собираетесь использовать для регистрации сертификатов, нажмите «Ввод» и нажмите «ОК».
• Вернувшись в диспетчер IIS, пока ваш новый виртуальный каталог выбран на левой панели, на средней панели выберите просмотр каталога. На панели сведений справа выберите включить
• Пока виртуальный каталог все еще выбран на левой панели, выберите редактор конфигурации.
• В редакторе конфигурации в раскрывающемся меню перейдите к system.webServer \ security \ requestFiltering и установите для параметра «Двойное экранирование» значение True.
• Применять изменения
• Возможно, вам придется повозиться с разрешениями виртуального каталога. Кроме того, теперь вы можете импортировать сертификат rootca в каталог Trusted Root Certificate Authority на локальном компьютере сервера IIS в оснастке MMC Certificates на сервере IIS.

На сервере Windows для использования в качестве промежуточного центра сертификации
• Установите службы сертификации Active Directory через диспетчер серверов (примечание: этот компьютер должен быть присоединен к домену)
• Обязательно установите функции управления, выберите Enterprise CA для службы роли и Subordinate CA для типа CA в мастере установки роли.
• Для настройки закрытого ключа выберите новый закрытый ключ, оставьте MS-RSA выбранным в раскрывающемся меню, для алгоритма хеширования выберите sha256 и установите длину ключа 4096. Это сгенерирует CSR, который будет скопирован в корень Linux. CA
• Теперь вы можете импортировать сертификат rootca в оснастку сертификатов mmc.

Вернемся к ЦС Linux
• После копирования CSR в каталог корневого центра сертификации, который вы создали ранее, выполните:

  openssl ca -config /path/to/config -extensions v3_intermediate_ca -days 1825 -notext -md sha256  -in ca/"CSR File" -out ca/certs/subca.cer

• Теперь у вас есть подписанный промежуточный сертификат ЦС в каталоге ca / ​​certs, который можно скопировать в подчиненный ЦС Windows.
• Перед установкой сертификата subca в ADCS сгенерируйте CRL с помощью следующей команды:

  openssl ca -gencrl -out rootca.crl.pem -config /path/to/config

  и скопируйте сгенерированный сертификат crl и root в виртуальный каталог, который был создан на сервере IIS ранее.

Снова на промежуточном сервере Windows
• Убедитесь, что полное доменное имя сервера IIS разрешается из промежуточного центра сертификации, введите URL-адрес, используемый для CDP, в конфигурационном файле выше, если вы использовали примеры CA_FILENAME и HTTP_HOST в файле конфигурации, вы должны ввести "http: //pki.example .local / crldist / rootca.crl "в адресной строке браузера, и вам будет предложено загрузить или открыть файл crl. Если вы получаете ошибку 404, проверьте разрешения для виртуального каталога, используемого для CDP, и если вы получите ошибку 401, проверьте, какие настройки аутентификации для сервера IIS
• Откройте приложение «Центр сертификации» из диспетчера серверов и щелкните правой кнопкой мыши вложенный файл на левой панели, выберите импорт.
• Перейдите в расположение файла subca.cer, который вы скопировали из корневого центра сертификации Linux. Нажмите ОК

Теперь ваш промежуточный ЦС Windows должен быть запущен.

Источники

Вы можете попробовать отключить проверку CRL следующим образом:

https://social.technet.microsoft.com/wiki/contents/articles/964.certificate-revocation-list-crl-verification-an-application-choice.aspx

certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE