OpenSSL: неможливо перевірити перший сертифікат для URL-адреси Experian

Я намагаюся перевірити з'єднання SSL з Experian в Ubuntu 10.10 за допомогою клієнта OpenSSL.

openssl s_client -CApath /etc/ssl/certs/ -connect dm1.experian.com:443

Проблема полягає в тому, що з'єднання замикається за допомогою коду повернення Verify: 21 (не вдається перевірити перший сертифікат).

Я перевірив список сертифікатів, і сертифікат, який використовується для підписання Experian (VeriSign Class 3 Secure Server CA - G3), включений до списку.

/etc/ssl/certs/ca-certificates.crt 

Але я не знаю, чому він не може перевірити перший сертифікат. Заздалегідь спасибі.

Повну відповідь можна переглянути тут: https://gist.github.com/1248790

Перше повідомлення про помилку повідомляє вам більше про проблему:

перевірити помилку: num = 20: не вдалося отримати сертифікат місцевого емітента

Центр видачі сертифікатів сертифіката сервера кінцевої сутності є

Захищений сервер VeriSign класу 3 CA - G3

Уважно подивіться у своєму файлі ЦС - ви не знайдете цього сертифіката, оскільки він є посередницьким ЦС, - те, що Ви знайшли, було подібним іменем G3 Public Primary CA VeriSign.

Але чому вдається інший зв’язок, а цей - ні? Проблема полягає в неправильній конфігурації серверів (дивіться самі, використовуючи -debugопцію). "Хороший" сервер надсилає весь ланцюжок сертифікатів під час рукостискання, надаючи вам необхідні проміжні сертифікати.

Але сервер, який не працює, надсилає вам лише кінцевий сертифікат сутності, і OpenSSL не здатний завантажити відсутній проміжний сертифікат "на льоту" (що було б можливо шляхом інтерпретації розширення доступу до інформації про повноваження). Тому ваша спроба не вдається скористатися, s_clientале вона все одно матиме успіх, якщо ви переглянете ту саму URL-адресу, наприклад, за допомогою FireFox (який підтримує функцію "виявлення сертифіката").

Ваші варіанти вирішення проблеми - це або виправити це на стороні сервера, змусивши сервер надсилати також весь ланцюжок, або передавши відсутній проміжний сертифікат OpenSSL як параметр на стороні клієнта.

Додавання додаткової інформації до відповіді тиснення.

Якщо сказати просто, у вашому ланцюжку сертифікатів є неправильний сертифікат.

Наприклад, ваш центр сертифікації, швидше за все, передасть вам 3 файли.

• your_domain_name.crt
• DigiCertCA.crt # (або будь-яке інше ім'я вашого центру сертифікації)
• TrustedRoot.crt

Ви, швидше за все, об’єднали всі ці файли в один пакет.

-----BEGIN CERTIFICATE----- 
(Your Primary SSL certificate: your_domain_name.crt) 
-----END CERTIFICATE----- 
-----BEGIN CERTIFICATE----- 
(Your Intermediate certificate: DigiCertCA.crt) 
-----END CERTIFICATE----- 
-----BEGIN CERTIFICATE----- 
(Your Root certificate: TrustedRoot.crt) 
-----END CERTIFICATE-----

Якщо ви створюєте пакет, але використовуєте стару або неправильну версію вашого проміжного сертифіката (DigiCertCA.crt у моєму прикладі), ви отримаєте точні симптоми, які ви описуєте.

• Здається, з'єднання SSL працюють із браузера
• Підключення SSL не вдається від інших клієнтів
• Збій curl з помилкою: " curl: (60) SSL-сертифікат: не вдається отримати сертифікат місцевого видавця "
• openssl s_client -connect видає помилку "перевірити помилку: num = 20: не вдається отримати сертифікат місцевого емітента"

Перезавантажте всі сертифікати від вашого центру сертифікації та зробіть новий пакет.

Я зіткнувся з тією ж проблемою, встановивши свій підписаний сертифікат на екземплярі Amazon Elastic Load Balancer.

Здавалося, все знайдено через браузер (Chrome), але доступ до сайту через мій клієнт Java створив виняток javax.net.ssl.SSLPeerUnverifiedException

Що я не зробив, це надавав файл "ланцюжка сертифікатів" під час встановлення мого сертифіката на моєму екземплярі ELB (див. Https://serverfault.com/questions/419432/install-ssl-on-amazon-elastic-load-balancer-with -godaddy-wildcard-сертифікат )

Нам надіслали наш підписаний відкритий ключ від підписувача, тому мені довелося створити власний файл ланцюжка сертифікатів. За допомогою панелі перегляду сертифікатів мого браузера я експортував кожен сертифікат у ланцюжок підписання. (Порядок ланцюжка сертифікатів важливий, див. Https://forums.aws.amazon.com/message.jspa?messageID=222086 )

Ось що ви можете зробити: -

Exim SSL-сертифікати

За замовчуванням /etc/exim.conf використовуватиме файли сертифіката / ключа:

/etc/exim.cert
/etc/exim.key

отже, якщо вам цікаво, де розмістити ваші файли, це де.

Вони контролюються параметрами exim.conf:

tls_certificate = /etc/exim.cert
tls_privatekey = /etc/exim.key

Проміжні сертифікати

Якщо у вас є кореневий сертифікат ЦС (набір ca, ланцюжок тощо), ви додасте вміст свого ЦС у файл exim.cert після фактичного сертифіката.

Можливо, непогано переконатися, що у вас є копія всього іншого, на випадок помилки.

Dovecot та ProFtpd також повинні це правильно прочитати, тому dovecot більше не потребує опції ssl_ca. Отже, в обох випадках немає необхідності вносити будь-які зміни ні в exim.conf, ні в dovecot.conf (/etc/dovecot/conf/ssl.conf)

Якщо ви використовуєте MacOS, використовуйте:

sudo cp /usr/local/etc/openssl/cert.pem /etc/ssl/certs

після цього помилка якоря довіри не знайдено зникає