OCSP Stapling issue

Help
1

IIS 10 on Windows Server 2016

So htbridge.com/ssl/ says this:

SERVER DOES NOT SUPPORT OCSP STAPLING

The server does not support OCSP stapling for its RSA certificate. Its support allows better verification of the certificate validation status.

Yet I read that IIS 8 and higher have OCSP Stapling support built-in and enabled by default. So I try testing it on the server itself:

openssl version

OpenSSL 1.1.0e 16 Feb 2017

openssl s_client -connect ocsp.int-x3.letsencrypt.org:443 -tlsextdebug -status

CONNECTED(00000178)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "EC point formats" (id=11), len=4
0000 - 03 00 01 02                                       ....
TLS server extension "session ticket" (id=35), len=0
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify error:num=19:self signed certificate in certificate chain
OCSP response: no response sent
---
Certificate chain
 0 s:/C=US/ST=Massachusetts/L=Cambridge/O=Akamai Technologies, Inc./CN=a248.e.akamai.net
   i:/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
 1 s:/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
 2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/C=US/ST=Massachusetts/L=Cambridge/O=Akamai Technologies, Inc./CN=a248.e.akamai.net
issuer=/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3669 bytes and written 311 bytes
Verification error: self signed certificate in certificate chain
---
New, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384
    Session-ID: 2637D73F3CF22524D43FC70BDB35C68967332D1A2C08E369AAF2B5BDADFFD1E8
    Session-ID-ctx:
    Master-Key: ...
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
...
    Start Time: 1534281497
    Timeout   : 7200 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
    Extended master secret: no
---
closed

Two things I notice:
OCSP response: no response sent
and
verify error:num=19:self signed certificate in certificate chain

  1. how do I enable OCSP Stapling?
  2. what is that self-signed cert doing in the cert chain?

TIA!

2

You do realise that you've tested the Let's Encrypt OCSP server with that command, right? And not your server?

Akamai sends the root certificate in its chain of certificate. This isn't required and just makes the TLS handshake bigger in size. Root certificates are meant to be self-signed. Nothing strange there.

I have no idea, that's probably something you'd be searching on Google with IIS 10 OCSP stapeling and such keywords..

3

Yes, I was testing to see if my server was firewalled or otherwise blocked from communicating to LE since the server initiates the revocation check. The “no response” tells me (I’m assuming) that I was able to connect but the LE server sent no data…? Didn’t know about the root cert, thanks for that.

4

No, it just means the OCSP servers aren't stapling an OCSP response for their own certificate themselves. You didn't actually request an OCSP request for a certain certificate. You just made a TLS connection to the OCSP server and checking if it send an stapled OCSP response, which it didn't. Requesting an OCSP response from the OCSP server is done in another matter. So you can't make any conclusions about whether your server can receive OCSP responses for your certificate with that command.

1 Like
5

OIC. Thank you for that link, I will be doing more reading! My cert does have the info it needs (see below) so I just have to figure out why Windows isn’t doing it.

[1]Authority Info Access
     Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
     Alternative Name:
          URL=http://ocsp.int-x3.letsencrypt.org
6

If you use SNI or central certificates OCSP stapling is not enabled by default, and you have to set a registry key to turn it on:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn786418(v=ws.11)#ocsp-stapling

2 Likes
7

Perfect, exactly what I needed, thanks so much! I also read through the previous page at raymii.org and was able to do a manual test once I figured out that SNI requires an extra parameter:

openssl ocsp -issuer chain.pem -cert mydomain.crt -text -url http://ocsp.int-x3.letsencrypt.org

OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
          Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
          Serial Number: 04C3DBEFBAB44DBFCD2ADE79C95F07C75958
    Request Extensions:
        OCSP Nonce:
            041003C7FB85F144C5AD1AE9A77B03C5B340
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
    Produced At: Aug 12 16:00:00 2018 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
      Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
      Serial Number: 04C3DBEFBAB44DBFCD2ADE79C95F07C75958
    Cert Status: good
    This Update: Aug 12 16:00:00 2018 GMT
    Next Update: Aug 19 16:00:00 2018 GMT

    Signature Algorithm: sha256WithRSAEncryption
    ...
WARNING: no nonce in response
Response verify OK
mydomain.crt: good
        This Update: Aug 12 16:00:00 2018 GMT
        Next Update: Aug 19 16:00:00 2018 GMT
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.