Is this invocation of "openssl s_client -connect" actually querying OCSP responder servers to confirm the current validity of certificates?

Question

I am curious as to whether invocation of a single line of openssl command line interface has the ability to perform complete OCSP verification protocol, e.g. query all the OCSP responder servers in a chain to confirm the current validity of certificates.

To see if this might be so, I specified the -CAfile option as /dev/null, hoping that would avoid any cached certificates being used in lieu of lookup: As explained in @pepo 's answer, the server certificate chain is sent a part of the basic TLS1.2 handshake specified in RFC 5246 (more details in update below)

# openssl s_client -CAfile /dev/null -connect www.equifaxsecurity2017.com:443

which gave the output:

CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = GeoTrust Inc., OU = Domain Validated SSL, CN = GeoTrust DV SSL CA - G3
verify return:1
depth=0 CN = www.equifaxsecurity2017.com
verify return:1
---
Certificate chain
 0 s:/CN=www.equifaxsecurity2017.com
   i:/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G3
 1 s:/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G3
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
<omitted>
-----END CERTIFICATE-----
subject=/CN=www.equifaxsecurity2017.com
issuer=/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G3
---
No client certificate CA names sent
....

It looks as though openssl has found all three links in the chain without any help from cached files, and so must have communicated over the internet with agents (1) GeoTrust DV SSL CA - G3, and (2) GeoTrust Global CA, to build the chain. Is that correct? No! It's not correct!

Has openssl also verified the chain by making the appropriate OCSP request to each of the three OCSP responders?

(My guess is "no". I am also aware that openssl ocsp ... can be used in conjunction with manual text operations on certificates to perform OSCP verification one link at a time. However, it does seem plausible, even preferable, that openssl would have been written to perform full OCSP verification, and that is why I am asking.)

UPDATE 9-14-2017:

Thanks to @pepo 's answer "SSL server (if configured correctly) will send certificate chain (except root CA certificate)", I looked up RFC 5246 and found section "7.4.2 Server Certificate" which explains the content of the "Server Certificate" part of the TLS1.2 handshake:

This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.

Furthermore, thanks to @pepo's answer about the -crl_check_all option, I tried that and got the following output:

CONNECTED(00000003)
depth=0 CN = www.equifaxsecurity2017.com
verify error:num=3:unable to get certificate CRL
verify return:1
depth=1 C = US, O = GeoTrust Inc., OU = Domain Validated SSL, CN = GeoTrust DV SSL CA - G3
verify error:num=3:unable to get certificate CRL

It failed with error unable to get certificate CRL. It turns out not be critical, because the chosen website has OCSP stapling enabled.

If instead of -crl_check_all to perform CRL checking, we instead add the option -status which requests OCSP stapling, then the following output is received:

CONNECTED(00000003)
<stuff omitted omitted>
OCSP response: 
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: CE2C8B1E8BD2300FD1B15446E9B594254949321B
    Produced At: Sep 10 11:12:45 2017 GMT
    Responses:
    Certificate ID: ...
    Cert Status: good
    This Update: Sep 10 11:12:45 2017 GMT
    Next Update: Sep 17 11:12:45 2017 GMT
    Signature Algorithm: sha1WithRSAEncryption
<stuff omitted>

This shows OCSP stapling is enabled on the server side, but it appears to only be enabled for the first (the leaf) certificate, and not for the second certificate. (The self-signed third certificate must be validated independently anyway). So, to verify the second certificate, either CRL-checking or OCSP-request-response must be used. Since CRL-checking is not enabled by this particular authorization chain, that leaves only OCSP-request-response.

Thanks to @pepo 's reply, I understand much better the relationship between openssl, the TLS1.2 protocol, and these methods for verifying authorization (listed in historical order):

• CRL (certificate revocation list) checking
• OSCP request and response
• OCSP stapling

However, a new question has also been raised:

• Regarding the OCSP-stapling response sent by the server along with the certificates in the chain during the "Server Certificate" message step - this has signature information (from the next level up) that needs to be verified. Is this signature information actually verified during the processing of openssl ... -status?

UPDATE: 9-15-2017

The safe answer to the question "Is this signature information actually verified during the processing of openssl ... -status? " seems to be NO, according to this answer and also @dave_thompson_085 's comment below (he has looked through the source code).

Is it confusing? Yes! Oddly, the "OpenSSL Cookbook (feistyduck, Ivan Ristić)" is unusually unclear about this question, showing no explicit way to verify the signature, while also not explicitly saying the whether or not the signature has been verified. In contrast, for both of the other types revocation checking:

• CRL-checking
• and OCSP-request-response (find "submit OCSP request")

the "OpenSSL Cookbook" shows explicit methods (recipes) to go the extra distance and complete the verification manually using the information already yielded by openssl. It would be a very human mistake to infer that reason "OpenSSL Cookbok" does not include the recipe for full validation of a stapled OCSP-reponse is because it is not necessary.

IMHO, it would be very responsible of OpenSSL (or any similar library) to include top level documentation, in the following order of priority

• (1) explanation that OpenSSL does NOT offer a black box solution to TLS+authorization,
• (2) explanation about what limited part of that solution it DOES offer (e.g., TLS handshake without authorization checking),
• (3) documentation on recipes for assembling OpenSSL components to complete the authorization checking solution.

Misunderstanding spreads very easily. Just a few days ago I was trying to write a simple program to send notification mail from my Linux Ubuntu PC. The standard Python releases (both ver 2 and 3) include an SMTP and an SSL library "implementing" TLS1.2. In 10 minutes I could write the program and walk through it in the debugger. I could see the call from the python SSL library to OpenSSL's handshake() function and assumed that handshake() must be handling all the authorization checking, based on the assumption that the SSL library and the SMTP library would not be released without including authorization checking. Strangely, the calling code in the SSL library included a post-handshake() check to make sure the received certificate name matched that of the called server. "Why would such a primitive check be necessary if handshake() already handled all the signature verifications, etc.?", I thought. That doubt started a journey peeling back layers of the TLS security onion and I haven't been able to stop crying since.

I don't want to try to re-invent the wheel, which would probably be wobbly anyway. Yet, I can't seem to find any available wheels. Where to go from here?

Answer 1

SSL server (if configured correctly) will send certificate chain (except root CA certificate). You can verify it here.

Openssl did not fetch these certificate but it got them served when initiating ssl connection. You can read more about s_client behavior in openssl documentation

I don't know if it performs OCSP verification but I doubt it. IMHO (based on The s_client utility is a test tool and is designed to continue the handshake after any certificate verification errors.) it does not perform any validation by default at all but you can at least enable CRL checking by specifying argument -crl_check_all

openssl s_client -connect www.equifaxsecurity2017.com:443 -crl_check_all