Щоб перевірити наявність деталей сертифіката SSL, я використовую такий інструмент командного рядка з моменту його появи:
https://github.com/azet/tls_tools
Чудово повторно перевірити, чи є у вас вся інформація правильна для повторної видачі сертифікатів або перевірки існуючих, а також як мало залежностей І це не вимагає налаштування.
Ось так виглядають перші кілька рядків виводу:
$ ./check_certificate_chain.py gnupg.org 443
>> Certificate Chain:
[+]* OU=Domain Control Validated, OU=Gandi Standard SSL, CN=gnupg.org
[+]** C=FR, O=GANDI SAS, CN=Gandi Standard SSL CA
[+]*** C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware
>> Certificate Information:
................................................................................
- [Subject]: OU=Domain Control Validated, OU=Gandi Standard SSL, CN=gnupg.org
- [Issuer]: C=FR, O=GANDI SAS, CN=Gandi Standard SSL CA
- [Valid from]: Mar 18 00:00:00 2014 GMT
- [Valid until]: Mar 18 23:59:59 2016 GMT
- [Authority]: Is not a CA
- [Version]: 2
- [Serial No.]: 43845251655098616578492338727643475746
- [X.509 Extension Details]:
-- [x509_authorityKeyIdentifier]:
keyid:B6:A8:FF:A2:A8:2F:D0:A6:CD:4B:B1:68:F3:E7:50:10:31:A7:79:21
За цим результатом йде весь ланцюжок сертифікатів з однаковим рівнем деталізації.
Що мені подобається, замість того, щоб бути інструментом клі-орієнтованого на ssl, як s_client openssl, цей намагається просто виконати ту роботу, яка нам потрібна більшу частину часу. Звичайно, openssl є більш гнучким (тобто перевірка клієнтських діаграм, зображень на непарних портах тощо) - але мені це не завжди потрібно.
Крім того, якщо у вас є час викопати & налаштувати або оцінити більше функцій, є більший інструмент під назвою sslyze (не використовуючи його з-за залежностей та встановлення ...)