Knowledge Base

Overview

By following this article, you will confirm whether your Windows Server is stapling a certificate revocation response to the TLS handshake, and enable stapling on the binding types where Windows does not do so automatically. The article covers the prerequisites, confirming version support, testing the site from an external client, identifying the Online Certificate Status Protocol (OCSP) responder address, testing connectivity to it, reviewing the Internet Information Services (IIS) binding type, applying the Schannel registry value when required, and revalidating. Four terms recur: the OCSP responder is the Certificate Authority (CA) service that reports whether a certificate is still valid; Server Name Indication (SNI) lets one IP address host several certificates; Centralized Certificate Store (CCS) serves IIS certificates from a shared file share; and Schannel is the Windows component that performs the TLS handshake and holds the stapling setting.

Prerequisites

Confirm the following on the Windows Server you are configuring.

• Windows Server 2008 or later is in use. Earlier versions do not support OCSP stapling.
• The certificate is installed correctly in IIS and bound to the intended website.
• The server presents the complete certificate chain to clients.
• The server can reach the OCSP responder Uniform Resource Locator (URL) listed in the certificate Authority Information Access (AIA) extension.
• If the IIS binding uses Server Name Indication (SNI) or Centralized Certificate Store (CCS), review the binding type section before making any change.

Confirm the Windows Server version supports stapling

Windows Server 2008 and later support OCSP stapling, and for standard IIS TLS bindings it is enabled by default. Earlier versions do not support it, so upgrade before continuing. Check the installed version with either command below.

Open the Windows version dialog:

winver

Or read the version from PowerShell:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Verify OCSP stapling from an external client

Test the public endpoint from a client machine before changing anything on the server. You can test from the command line or with a public testing service.

Test with OpenSSL

Run the following command from a client machine that can reach the public TLS endpoint of the site. Include the -servername option so the test presents the correct Server Name Indication (SNI) hostname.

openssl s_client -connect your-domain.com:443 -servername your-domain.com -status

If OCSP stapling is working, the output includes an OCSP Response Data section and the following status line.

OCSP Response Status: successful (0x0)

Test with an SSL testing service

A public SSL testing service, such as Qualys SSL Labs Server Test or the DigiCert SSL Installation Checker, also reports whether the site staples an OCSP response. Wording varies by tool, with results such as Yes, Good, Enabled, No, Not Enabled, or No Response. Review the full certificate chain and revocation details rather than a single label.

Identify the OCSP responder address

Take the OCSP responder address from the certificate Authority Information Access (AIA) extension. Do not hardcode responder IP addresses, because Certificate Authority responder infrastructure can change. The example ocsp.sectigo.com used below is illustrative, and the correct address depends on the certificate issuer.

Read the responder Uniform Resource Locator (URL) with OpenSSL, from a system where the certificate file is available:

openssl x509 -in certificate.crt -noout -ocsp_uri

Example output:

http://ocsp.sectigo.com

You can also open the certificate in Windows Certificate Manager and read the responder address from its Authority Information Access extension.

Test connectivity to the OCSP responder

From the Windows Server, test whether the server can reach the OCSP responder address you identified in the certificate. Use either of the following commands.

Test the connection with PowerShell, replacing the hostname with the responder address from your certificate:

Test-NetConnection ocsp.sectigo.com -Port 80

Or test the connection with curl on the Windows Server:

curl.exe -I http://ocsp.sectigo.com

If connectivity fails, review firewall rules, proxy configuration, Domain Name System (DNS) resolution, network filtering policies, and outbound access to the responder port. OCSP over HTTP commonly uses Transmission Control Protocol (TCP) port 80.

Review the IIS binding type

For standard IIS TLS bindings, Windows staples an OCSP response by default and no further configuration is needed. Microsoft documents one exception: OCSP stapling is not enabled by default for IIS websites that use Require Server Name Indication (SNI) or Centralized Certificate Store (CCS) bindings.

If the website uses SNI or CCS and stapling is required, apply the Schannel registry value described in the next section. Microsoft notes that enabling stapling for these binding types can affect performance, so apply it only after testing and normal change control.

Enable OCSP stapling for SNI or CCS bindings

Apply this section only when the IIS website uses Server Name Indication (SNI) or Centralized Certificate Store (CCS) bindings and no stapled response is being sent. Add the following Schannel registry value on the Windows Server.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" /v EnableOcspStaplingForSni /t REG_DWORD /d 1 /f

Or add the same value with PowerShell:

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" -Name "EnableOcspStaplingForSni" -PropertyType DWord -Value 1 -Force

Restart IIS, or reboot the server, during an approved maintenance window so that Schannel and IIS reload the configuration.

iisreset

To reverse the change later, set the same value to 0:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" /v EnableOcspStaplingForSni /t REG_DWORD /d 0 /f

Revalidate OCSP stapling

After confirming connectivity and applying any required Schannel change, test the site again from an external client.

openssl s_client -connect your-domain.com:443 -servername your-domain.com -status

A working configuration returns an OCSP Response Data section and the following status line.

OCSP Response Status: successful (0x0)

A missing OCSP Response Data section does not always mean stapling is unsupported. It can also indicate SNI or CCS binding behavior, an outbound connectivity failure, an incomplete certificate chain, a responder availability issue at the Certificate Authority, or a response the server has not yet cached.

Troubleshooting

If no stapled OCSP response is returned, check the following on the Windows Server.

• Confirm the certificate includes a responder address in its Authority Information Access (AIA) extension.
• Confirm the server can resolve and connect to the OCSP responder hostname.
• Confirm outbound firewall and proxy rules allow access to the responder.
• Confirm IIS is serving the correct certificate and the complete certificate chain.
• If the site uses SNI or CCS bindings, confirm whether EnableOcspStaplingForSni is required and configured.
• Review Windows Event Viewer and the IIS logs for certificate, Schannel, or network errors.
• Retest after IIS or the server has had time to retrieve and cache a valid response.

References

• Microsoft Learn, Transport Layer Security (TLS) registry settings, including EnableOcspStaplingForSni: https://learn.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings
• Microsoft Learn, Manage Transport Layer Security (TLS): https://learn.microsoft.com/en-us/windows-server/security/tls/manage-tls