How can I verify SSL certificates on the command line?
I’m trying to validate/verify that the rsa key, ca-bundle, and certificate stored here are ok. They are not being served by a webserver. How can I verify them?
5 Answers 5
Assuming your certificates are in PEM format, you can do:
If your «ca-bundle» is a file containing additional intermediate certificates in PEM format:
openssl verify -untrusted ca-bundle cert.pem If your openssl isn’t set up to automatically use an installed set of root certificates (e.g. in /etc/ssl/certs ), then you can use -CApath or -CAfile to specify the CA.
Warning, the openssl verify command is more permissive than you might expect! By default, in addition to checking the given CAfile, it also checks for any matching CAs in the system’s certs directory e.g. /etc/ssl/certs. To prevent this behavior and make sure you’re checking against your particular CA cert given by CAfile, you must also pass a -CApath option with a non-existant directory, e.g.: openssl verify -verbose -CApath nosuchdir -CAfile cacert.pem server.crt
One further caveat: If you use -CApath nosuchdir then the combination of server.crt and cacert.pem must include the root CA; if openssl can only work up to an intermediate CA with those files then it will complain.
Or instead you can use flag designed for this: openssl verify -verbose -no-CAfile -no-CApath -untrusted ca.pem server.pem . Though don’t use it for checking a bundle, verify only works for first certificate in server.pem .
Here is one-liner to verify a certificate chain:
openssl verify -verbose -x509_strict -CAfile ca.pem -CApath nosuchdir cert_chain.pem This doesn’t require to install CA anywhere.
As noted by Klaas van Schelven, the answer above is misleading as openssl appears to verify only single top certificate per file. So it’s necessary to issue multiple verify commands for each certificate chain node placed in separate file.
No problem, glad to help. 🙂 One caveat that I figured out after posting my earlier comment: if the file specified with -CAfile is itself just an intermediate certificate, then openssl will complain. This is correct behavior, since verify requires a complete chain all the way up to a root CA, but can be misleading.
My version ( OpenSSL 1.1.1 11 Sep 2018 ) requires the argument to -CApath to be an existing directory.
This answer is misleading, because «openssl verify» does not in fact verify more than 1 certificate per file, and thus cannot be used on bundles. See stackoverflow.com/a/66782460/339144
@KlaasvanSchelven, thanks for letting know about this issue. I’ve updated the answer with with your link.
I recently used this tool https://github.com/drwetter/testssl.sh and it provides a comprehensive report related to SSL.
Testing protocols via sockets except NPN+ALPN SSLv2 not offered (OK) SSLv3 not offered (OK) TLS 1 not offered TLS 1.1 not offered TLS 1.2 offered (OK) TLS 1.3 not offered and downgraded to a weaker protocol NPN/SPDY not offered ALPN/HTTP2 h2, http/1.1 (offered) Testing cipher categories NULL ciphers (no encryption) not offered (OK) Anonymous NULL Ciphers (no authentication) not offered (OK) Export ciphers (w/o ADH+NULL) not offered (OK) LOW: 64 Bit + DES, RC[2,4], MD5 (w/o export) not offered (OK) Triple DES Ciphers / IDEA not offered Obsolete: SEED + 128+256 Bit CBC cipher offered non-FS Strong encryption (AEAD ciphers) offered (OK) Forward Secure Strong encryption (AEAD ciphers) offered (OK) Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4 PFS is offered (OK) ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA Elliptic curves offered: prime256v1 secp384r1 secp521r1 X25519 X448 Testing server preferences Has server cipher order? yes (OK) Negotiated protocol TLSv1.2 Negotiated cipher ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256) Cipher order TLSv1.2: ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA AES128-GCM-SHA256 AES128-SHA AES256-SHA Testing server defaults (Server Hello) TLS extensions (standard) "renegotiation info/#65281" "server name/#0" "EC point formats/#11" "session ticket/#35" "status request/#5" "max fragment length/#1" "application layer protocol negotiation/#16" "encrypt-then-mac/#22" "extended master secret/#23" Session Ticket RFC 5077 hint 7200 seconds, session tickets keys seems to be rotated < daily SSL Session ID support yes Session Resumption Tickets: yes, ID: yes TLS clock skew Random values, no fingerprinting possible Signature Algorithm SHA256 with RSA Server key size RSA 2048 bits Server key usage Digital Signature, Key Encipherment Server extended key usage TLS Web Server Authentication, TLS Web Client Authentication Serial / Fingerprints REDACTED / SHA1 REDACTED SHA256 REDACTED Common Name (CN) REDACTED (CN in response to request w/o SNI: *.REDACTED ) subjectAltName (SAN) REDACTED Issuer Let's Encrypt Authority X3 (Let's Encrypt from US) Trust (hostname) Ok via SAN (SNI mandatory) Chain of trust Ok EV cert (experimental) no ETS/"eTLS", visibility info not present Certificate Validity (UTC) 72 >= 30 days (2020-03-19 22:41 --> 2020-06-17 22:41) # of certificates provided 2 Certificate Revocation List -- OCSP URI http://ocsp.int-x3.letsencrypt.org OCSP stapling offered, not revoked OCSP must staple extension -- DNS CAA RR (experimental) not offered Certificate Transparency yes (certificate extension) Testing HTTP header response @ "/" HTTP Status Code 200 OK HTTP clock skew -1 sec from localtime Strict Transport Security 366 days=31622400 s, just this domain Public Key Pinning -- Server banner nginx Application banner -- Cookie(s) (none issued at "/") Security headers X-Frame-Options SAMEORIGIN X-Content-Type-Options nosniff X-Served-By REDACTED, REDACTED Cache-Control public, max-age=3600 Reverse Proxy banner X-Cache: HIT, HIT X-Cache-Hits: 3, 1 Via: 1.1 varnish Testing vulnerabilities Heartbleed (CVE-2014-0160) not vulnerable (OK), no heartbeat extension CCS (CVE-2014-0224) not vulnerable (OK) Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK) ROBOT not vulnerable (OK) Secure Renegotiation (RFC 5746) supported (OK) Secure Client-Initiated Renegotiation not vulnerable (OK) CRIME, TLS (CVE-2012-4929) not vulnerable (OK) BREACH (CVE-2013-3587) potentially NOT ok, uses gzip HTTP compression. - only supplied "/" tested Can be ignored for static pages or if no secrets in the page POODLE, SSL (CVE-2014-3566) not vulnerable (OK), no SSLv3 support TLS_FALLBACK_SCSV (RFC 7507) No fallback possible (OK), no protocol below TLS 1.2 offered SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK) FREAK (CVE-2015-0204) not vulnerable (OK) DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK) make sure you don't use this certificate elsewhere with SSLv2 enabled services https://censys.io/ipv4?q=REDACTED could help you to find out LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with Another cool CLI tool is gnutls-cli . It is built-in on MacOS and Linux-Unix systems.
Open SSL
openssl verify [-help] [-CRLfile filename|uri] [-crl_download] [-show_chain] [-verbose] [-trusted filename|uri] [-untrusted filename|uri] [-vfyopt nm:v] [-nameopt option] [-CAfile file] [-no-CAfile] [-CApath dir] [-no-CApath] [-CAstore uri] [-no-CAstore] [-engine id] [-allow_proxy_certs] [-attime timestamp] [-no_check_time] [-check_ss_sig] [-crl_check] [-crl_check_all] [-explicit_policy] [-extended_crl] [-ignore_critical] [-inhibit_any] [-inhibit_map] [-partial_chain] [-policy arg] [-policy_check] [-policy_print] [-purpose purpose] [-suiteB_128] [-suiteB_128_only] [-suiteB_192] [-trusted_first] [-no_alt_chains] [-use_deltas] [-auth_level num] [-verify_depth num] [-verify_email email] [-verify_hostname hostname] [-verify_ip ip] [-verify_name name] [-x509_strict] [-issuer_checks] [-provider name] [-provider-path path] [-propquery propq] [--] [certificate . ]
DESCRIPTION
This command verifies certificate chains. If a certificate chain has multiple problems, this program attempts to display all of them.
OPTIONS
Print out a usage message.
-CRLfile filename|uri
The file or URI should contain one or more CRLs in PEM or DER format. This option can be specified more than once to include CRLs from multiple sources.
Attempt to download CRL information for certificates via their CDP entries.
Display information about the certificate chain that has been built (if successful). Certificates in the chain that came from the untrusted list will be flagged as "untrusted".
Print extra information about the operations being performed.
-trusted filename|uri
A file or URI of (more or less) trusted certificates. See openssl-verification-options(1) for more information on trust settings.
This option can be specified more than once to load certificates from multiple sources.
-untrusted filename|uri
A file or URI of untrusted certificates to use for chain building. This option can be specified more than once to load certificates from multiple sources.
-vfyopt nm:v
Pass options to the signature algorithm during verify operations. Names and values of these options are algorithm-specific.
This specifies how the subject or issuer names are displayed. See openssl-namedisplay-options(1) for details.
To load certificates or CRLs that require engine support, specify the -engine option before any of the -trusted, -untrusted or -CRLfile options.
-CAfile file, -no-CAfile, -CApath dir, -no-CApath, -CAstore uri, -no-CAstore
-allow_proxy_certs, -attime, -no_check_time, -check_ss_sig, -crl_check, -crl_check_all, -explicit_policy, -extended_crl, -ignore_critical, -inhibit_any, -inhibit_map, -no_alt_chains, -partial_chain, -policy, -policy_check, -policy_print, -purpose, -suiteB_128, -suiteB_128_only, -suiteB_192, -trusted_first, -use_deltas, -auth_level, -verify_depth, -verify_email, -verify_hostname, -verify_ip, -verify_name, -x509_strict -issuer_checks
Set various options of certificate chain verification. See "Verification Options" in openssl-verification-options(1) for details.
-provider name -provider-path path -propquery propq
Indicates the last option. All arguments following this are assumed to be certificate files. This is useful if the first certificate filename begins with a -.
One or more target certificates to verify, one per file. If no certificates are given, this command will attempt to read a single certificate from standard input.
DIAGNOSTICS
When a verify operation fails the output messages can be somewhat cryptic. The general form of the error message is:
server.pem: /C=AU/ST=Queensland/O=CryptSoft Pty Ltd/CN=Test CA (1024 bit) error 24 at 1 depth lookup:invalid CA certificateThe first line contains the name of the certificate being verified followed by the subject name of the certificate. The second line contains the error number and the depth. The depth is number of the certificate being verified when a problem was detected starting with zero for the target ("leaf") certificate itself then 1 for the CA that signed the target certificate and so on. Finally a textual version of the error number is presented.
A list of the error codes and messages can be found in X509_STORE_CTX_get_error(3); the full list is defined in the header file .
This command ignores many errors, in order to allow all the problems with a certificate chain to be determined.
SEE ALSO
HISTORY
The -show_chain option was added in OpenSSL 1.1.0.
The -engine option was deprecated in OpenSSL 3.0.
COPYRIGHT
Copyright 2000-2021 The OpenSSL Project Authors. All Rights Reserved.
Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at https://www.openssl.org/source/license.html.
master manpages
This manpage
Please report problems with this website to webmaster at openssl.org.
Copyright © 1999-2023 The OpenSSL Project Authors. All Rights Reserved.
Проверка SSL на валидность при помощи openssl
Частенько приходится устанавливать сертификаты и бывают не соответствия, что бы убедится что сертификаты валидны есть openssl который в этом нам поможет.
Проверка pem,crt — сертификата вместе с цепочкой(если у вас несколько файлов, объедините в один, сначала идет сертификат потом цепочка)
openssl x509 -noout -modulus -in server.crt | openssl md5
openssl rsa -noout -modulus -in server.key | openssl md5
openssl req -noout -modulus -in request.csr | openssl md5
MD5 у всех должен совпадать — но для работоспособности должны быть одинаковы только у приватного ключа и сертификата, csr вам может пригодится если вы соберетесь продлевать данный сертификат.
Данная команда покажет информацию о сертификате
openssl x509 -in certificate.crt -text -noout
openssl rsa -in server.key -check
openssl s_client -connect clsv.ru:443
openssl s_client -proxy 192.168.103.115:3128 -connect clsv.ru:443
openssl req -x509 -nodes -newkey rsa:2048 -days 365 -keyout ./key.pem -out cert.pem -subj /C=/ST=/L=/O=/CN=clsv.ru
И в каталоге у вас появится Ключ — key.pem и Сертификат cert.pem и теперь можно их использовать для шифрования трафика вашего сервиса.
Сделать PFX сертификат из имеющихся
openssl pkcs12 -export -out domain.name.pfx -inkey domain.name.key -in domain.name.crt