• titlepage
• table-of-contents
• SonicOS 8
• About SonicOS
  • Working with SonicOS
  • SonicOS Workflow
  • How to Use the SonicOS Administration Guides
  • Guide Conventions
• IPSec VPN Overview
  • About Virtual Private Networks
  • VPN Types
    • IPsec VPN
    • DHCP over VPN
    • L2TP with IPsec
    • SSL VPN
  • VPN Security
    • About IKEv1
    • About IKEv2
    • Mobility and Multi-homing Protocol for IKEv2 (MOBIKE)
    • About IPsec (Phase 2) Proposal
    • About Suite B Cryptography
  • VPN Base Settings and Displays
    • Policies
    • Active Tunnels
    • Down Tunnels
    • Settings
  • IPv6 VPN Configuration
• Site to Site VPNs
  • Planning Site to Site Configurations
  • General VPN Configuration
    • Configuring Settings on the General Tab
    • Configuring Settings on the Network Tab
    • Configuring Settings on the Proposals Tab
    • Configuring Settings on the Advanced Tab
  • Managing GroupVPN Policies
    • Configuring IKE Using a Preshared Secret Key
    • Configuring IKE Using 3rd Party Certificates
    • Downloading a GroupVPN Client Policy
  • Creating Site to Site VPN Policies
    • Configuring with a Preshared Secret Key
    • Configuring with a Manual Key
    • Configuring with a Third-Party Certificate
    • Configuring the Remote SonicWall Network Security Appliance
• VPN Auto Provisioning
  • About VPN Auto Provisioning
    • Defining VPN Auto Provisioning
    • Benefits of VPN Auto Provisioning
    • How VPN Auto Provisioning Works
      • About Establishing the IKE Phase 1 Security Association
      • About Establishing IKE Phase 2 using a Provisioned Policy
  • Configuring a VPN AP Server
    • Starting the VPN AP Server Configuration
    • Configuring VPN AP Server Settings on General
    • Configuring VPN AP Server Settings on Network
    • Configuring Advanced Settings on Proposals
    • Configuring Advanced Settings on Advanced
  • Configuring a VPN AP Client
• Rules and Settings
  • Adding a Tunnel Interface
    • Creating a Static Route for the Tunnel Interface
  • Route Entries for Different Network Segments
  • Redundant Static Routes for a Network
• Advanced
  • Configuring Advanced VPN Settings
  • Configuring IKEv2 Settings
  • Using OCSP with SonicWall Network Security Appliances
    • OpenCA OCSP Responder
    • Loading Certificates to Use with OCSP
    • Using OCSP with VPN Policies
• DHCP over VPN
  • DHCP Relay Mode
  • Configuring the Central Gateway for DHCP Over VPN
  • Configuring DHCP over VPN Remote Gateway
  • Current DHCP over VPN Leases
• L2TP Servers and VPN Client Access
  • Configuring the L2TP Server
  • Viewing Currently Active L2TP Sessions
  • Configuring Microsoft Windows L2TP VPN Client Access
  • Configuring Google Android L2TP VPN Client Access
• AWS VPN
  • Overview
  • Creating a New VPN Connection
  • Reviewing the VPN Connection
    • Configuration on the Firewall
    • Configuration on Amazon Web Services
  • Route Propagation
  • AWS Regions
  • Deleting VPN Connections
• SonicWall Support
  • About This Document

Using OCSP with SonicWall Network Security Appliances

OCSP is designed to augment or replace CRL in your Public Key Infrastructure (PKI) or digital certificate system. The CRL is used to validate the digital certificates comprised by the PKI. This allows the Certificate Authority (CA) to revoke certificates before their scheduled expiration date and is useful in protecting the PKI system against stolen or invalid certificates.

The main disadvantage of Certificate Revocation Lists is the need for frequent updates to keep the CRL of every client current. These frequent updates greatly increase network traffic when the complete CRL is downloaded by every client. Depending on the frequency of the CRL updates, a period of time can exist when a certificate is revoked by the CRL but the client has not received the CRL update and permits the certificate to be used.

Online Certificate Status Protocol determines the current status of a digital certificate without using a CRL. OCSP enables the client or application to directly determine the status of an identified digital certificate. This provides more timely information about the certificate than is possible with CRLs. In addition, each client typically only checks a few certificates and does not incur the overhead of downloading an entire CRL for only a few entries. This greatly reduces the network traffic associated with certificate validation.

OCSP transports messages over HTTP for maximum compatibility with existing networks. This requires careful configuration of any caching servers in the network to avoid receiving a cached copy of an OCSP response that might be out of date.

The OCSP client communicates with an OCSP responder. The OCSP responder can be a CA server or another server that communicates with the CA server to determine the certificate status. The OCSP client issues a status request to an OCSP responder and suspends the acceptance of the certificate until the responder provides a response. The client request includes data such as protocol version, service request, target certificate identification and optional extensions. These optional extensions might or might not be acknowledged by the OCSP responder.

The OCSP responder receives the request from the client and checks that the message is properly formed and if the responder is able to respond to the service request. Then it checks if the request contains the correct information needed for the service desired. If all conditions are satisfied, the responder returns a definitive response to the OCSP client. The OCSP responder is required to provide a basic response of GOOD, REVOKED, or UNKNOWN. If both the OCSP client and responder support the optional extensions, other responses are possible. The GOOD state is the desired response as it indicates the certificate has not been revoked. The REVOKED state indicates that the certificate has been revoked. The UNKNOWN state indicates the responder does not have information about the certificate in question.

OCSP servers typically work with a CA server in push or pull setup. The CA server can be configured to push a CRL list (revocation list) to the OCSP server. Additionally the OCSP server can be configured to periodically download (pull) the CRL from the CA server. The OCSP server must also be configured with an OCSP response signing certificate issued by the CA server. The signing certificate must be properly formatted or the OCSP client cannot accept the response from the OSCP server.