Aby sprawdzić szczegóły certyfikatu SSL, używam następującego narzędzia wiersza poleceń, odkąd jest ono dostępne:
https://github.com/azet/tls_tools
Dobrze jest dwukrotnie sprawdzić, czy wszystkie informacje są prawidłowe do ponownego wystawiania certyfikatów lub sprawdzania poprawności istniejących, a także jako niewielką zależność ORAZ nie wymaga konfiguracji.
Oto jak wygląda kilka pierwszych wierszy wyniku:
$ ./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
Po tych wynikach następuje cały łańcuch certyfikatów na tym samym poziomie szczegółowości.
To, co lubię, zamiast być narzędziem cli zorientowanym na ssl, takim jak s_client openssl, to ono próbuje po prostu wykonać jedną pracę, której potrzebujemy przez większość czasu. Oczywiście openssl jest bardziej elastyczny (tzn. Również sprawdza klientcert, imapy na nieparzystych portach itp.) - ale nie zawsze tego potrzebuję.
Alternatywnie, jeśli masz czas na kopanie i konfigurowanie lub doceniasz więcej funkcji, istnieje większe narzędzie o nazwie sslyze (nie używa go od zależności i instalacji ...)