Назад | Перейти на главную страницу

Установленная цепочка ключей OSX Ошибка сертификата Windows Server

У меня проблема с внутренним сертификатом SSL. Итак, у меня есть оплаченный домен, который используется для наших внутренних сетевых ресурсов (интрасети). существует сервер Windows Server 2012 Active Directory, использующий SSL-сертификат, подписанный самоподписанным корневым сертификатом CA серверов. и это отлично работает в Windows (как показано на первом изображении ниже), если корневой центр сертификации не установлен, он выдаст предупреждение SSL. Когда корневой ЦС установлен, он работает правильно, поэтому я знаю, что сертификат недействителен.

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

Я пытался:

  1. Переключение браузера, поэтому я привязался к Firefox, Chome и Safari.
  2. Использование более старой версии OSX вплоть до OS X 10.7 и все та же проблема

Вывод OpenSSL:

CONNECTED(00000005) depth=0  verify error:num=20:unable to get local issuer certificate verify return:1 depth=0  verify error:num=21:unable to verify the first certificate verify return:1
--- Certificate chain  0 s:    i:/DC=ltd/DC=beaconsoft/CN=eddystone-ca
-----END CERTIFICATE-----
--- Server certificate subject= issuer=/DC=ltd/DC=beaconsoft/CN=eddystone-ca
--- No client certificate CA names sent Server Temp Key: ECDH, X25519, 253 bits
--- SSL handshake has read 2161 bytes and written 293 bytes
--- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 8D370000FC765F11E029CA4E23ED4AE0804CAA88CAE16435514843DAF1C7E7D3
    Session-ID-ctx: 
    Master-Key: EC6F98CE80E8F82A97D2D554335A41FF71B1E13D0097DC0F2755795085B97B426FE95B8EA81D6BE511C28EB3EECFAA51
    Start Time: 1559054773
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)

Фактические данные сертификата были обрезаны по размеру.

Как я и подозревал, причиной ваших проблем является сертификат сервера.

В нем есть как минимум 2 вещи, которые следует исправить:

  • Точка распространения CRL:

    [1]CRL Distribution Point
  Distribution Point Name:
    Full Name:
      URL=ldap:///CN=eddystone-ca,CN=eddystone,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=beaconsoft,DC=ltd?certificateRevocationList?base?objectClass=cRLDistributionPoint (ldap:///CN=eddystone-ca,CN=eddystone,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=beaconsoft,DC=ltd?certificateRevocationList?base?objectClass=cRLDistributionPoint)

  • Доступ к информации о полномочиях:

    [1]Authority Info Access
  Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
    Alternative Name:
      URL=ldap:///CN=eddystone-ca,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=beaconsoft,DC=ltd?cACertificate?base?objectClass=certificationAuthority (ldap:///CN=eddystone-ca,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=beaconsoft,DC=ltd?cACertificate?base?objectClass=certificationAuthority)
[2]Authority Info Access
  Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
    Alternative Name:
      URL=http://eddystone.beaconsoft.ltd

Ваша точка распространения CRL недоступна для Windows, не подключенной к домену, и для всех клиентов, отличных от Windows.

В соответствии с передовой современной практикой рекомендуется избегать использования LDAP как в CRL Distribution Point и Authority Info Access записи.

Вы можете прочитать больше, например, там

Также я не уверен, что в вашем сертификате пустая тема. Пока у вас еще есть определенное имя SAN DNS Name=Cape.beaconsoft.ltd, Я бы тоже поставил правильную тему.

Кстати мы обсуждаем сертификат на overlord.beaconsoft.ltd, и вы отправили один за Cape.beaconsoft.ltd. Но если они созданы одним и тем же центром сертификации с использованием одного и того же шаблона - на самом деле это не имеет значения - просто исправьте записи CRL и AIA, чтобы они имели HTTP только точки доступа