Online Certificate Status Protocol
The Online Certificate Status Protocol (OCSP) is defined in RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. The protocol enables users to determine the revocation state of a specific certificate, and may provide a more efficient source of revocation information than is possible with Certificate Revocation Lists (CRL).
The protocol specifies the data exchanged between an OCSP client (for example, the Oracle Communications Session Border Controller) and an OCSP responder, the Certification Authority (CA), or its delegate, that issued the target certificate. An OCSP client issues a request to an OCSP responder and suspends acceptance of the certificate in question until the responder replies with a certificate status.
Certificate status is reported as
- good
- revoked
- unknown
good indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate’s validity interval.
revoked indicates that the certificate has been revoked, either permanently or temporarily.
unknown indicates that the responder cannot identify the certificate.
Caveats
OCSP is currently supported only on TLS interfaces; it is not currently supported for use with IKEv1 and IKEv2.
Online Certificate Status Protocol Configuration
- Configuring one or more certificate status profiles; each profile contains information needed to contact a specific OCSP responder.
- Enabling certificate revocation checking by assigning a certificate status profile to a previously configured TLS profile.
Unreachable OCSP Responder
With OCSP enabled, the client implementation running on the SBC supports message exchange between the SBC and an OCSP responder as specified in RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. The SBC contacts the OCSP responder whenever a remote client attempts to establish an SSL/TLS connection with the SBC. The SBC sends a request to the OCSP responder to check the current status of the certificate presented by the remote client. The SBC suspends processing of the SSL/TLS connection request pending receipt of the OCSP response. In previous releases (prior to Version S-CX6.3.0), a good OCSP response resulted in the establishment of a secure SSL/TLS connection. A revoked or unknown OCSP response, or the failure to reach an OCSP responder, resulted in the rejection of the connection attempt.
This behavior, which adheres to the requirements of RFC 2560, conflicts with the requirements of Section 5.4.6.2.1.6.4.a.i of UCR 2008 which requires an OCSP client to attempt authentication of remote clients in the event of an unreachable OCSP responder.
The attribute ignore-dead-responder in the TLS profile configuration element provides compliance with DISA/DoD requirements specifying OCSP client operations when faced with unreachable OCSP responders. By default, the attribute is disabled meaning that all client connections will be disallowed in the event of unreachable OCSP responders.
In DISA/DoD environments ignore-dead-responder should be enabled, allowing local certificate-based authentication by the SBC in the event of unreachable OCSP responders. Successful authentication is achieved if the certificate presented by the remote client was signed by a Certificate Authority (CA) referenced by the trusted-ca-certificates attribute. If the local authentication succeeds, the secure TLS/SSL connection is established; otherwise the connection is rejected.
Unreachable OCSP Responder Configuration
The following sample configuration implements DISA/DoD-compliant client behavior in the event of an unreachable OCSP responder.
ACMEPACKET# configure terminal
ACMEPACKET(configure)# security#
ACMEPACKET(security)# tls-profile
ACMEPACKET(security)# show
tls-profile
name DoD
end-entity-certificate sylarCert-2048
trusted-ca-certificates dod1 dod2 disaA disaB IBM1
cipher-list all
verify-depth 10
mutual-authenticate disabled
tls-version tlsv13
cert-status-check enabled
cert-status-profile-list DoD
ignore-dead-responder enabled
...
...
ACMEPACKET(tls-profile)# OCSP Status Monitoring
OCSP monitoring is provided to track the reachability of individual OCSP responders, and, in topologies containing multiple OCSP responders, the overall availability of the OCSP service.
If monitoring is enabled for individual OCSP responders, reachability is monitored by observing responder transactions.
Initially, all OCSP responders are considered reachable. If a previously reachable OCSP responder fails to respond to a certificate status request, the SBC marks the OCSP responder as unreachable, and generates an SNMP trap and log entry indicating that status. If a previously unreachable OCSP responder responds to a certificate status request, the SBC returns the OCSP responder to the reachable status, and generates an SNMP trap and log entry indicating that status change.
Use the following procedure to enable monitoring of individual OCSP responders.
OCSP Access via FQDN
OCSP responders can be accessed via IPv4 addresses and port numbers as well as FQDNs. Since multiple public key infrastructure (PKI) elements capable of supporting OCSP requests can exist within a DISA/DoD environment, the Domain Name Service (DNS) lookup that resolves the FQDN can result in more than one OCSP responder IP address being returned to the SBC in its role of OCSP client. When processing a lookup that contains more than one IP address, the SBC uses a round-robin algorithm to select from the list of OCSP responder addresses.
OCSP access via FQDN is available on all media interfaces and on the wancom0 administrative interface. Note that support for FQDN-based access requires the configuration of DNS support.
If the realm attribute is configured in the certificate-status-profile configuration element, the required DNS query is issued on the corresponding network interface. This model requires configuration of the dns-ip-primary attribute, and optionally the dns-ip-backup1 and dns-ip-backup2 attributes for the realm’s network interface.
If the realm attribute is not configured in the certificate-status-profile, the required DNS query is issued on the wancom0 interface. This model requires configuration of the dns-ip-primary attribute, and optionally the dns-ip-backup1 and dns-ip-backup2 attributes for the wancom0 interface.
Access via an FQDN is supported by the hostname attribute in the cert-status-profile configuration element.
The SBC allows configuration of both an OCSP responder IP address and port number (using the ip-address and port attributes) and an OCSP responder domain (using the hostname attribute).
In such cases the verify-config command issues a warning and notes that IP address-based access will be used.
OCSP Access Configuration via IP Address
The following sample configuration accesses an OCSP responder at 192.168.7.100:8080.
ORACLE# configure terminal
ORACLE(configure)# security#
ORACLE(secirity)# cert-status-profile#
ORACLE(cert-status-profile)# show
cert-status-profile
name defaultOCSP
ip-address 192.168.7.100
hostname
port 8080
type OCSP
trans-proto HTTP
requestor-cert ocspVerisignClient
responder-cert VerisignCA2
trusted-cas
realm-id admin
retry-count 1
dead-time 0
last-modified-by
last-modified-date
ORACLE(cert-status-profile)#OCSP Access Configuration via FQDN
The following sample configuration accesses one or more OCSP responders at example.disa.mil.
Note that in the absence of a specified domain, the wancom0 interface must be DNS-enabled.
ORACLE# configure terminal
ORACLE(configure)# security#
ORACLE(cert-status-profile)# show
cert-status-profile
name DISAdomain2
ip-address
hostname example.disa.mil
port
type OCSP
trans-proto HTTP
requestor-cert
responder-cert
trusted-cas dod1 dod2 disaA disaB IBM1
realm-id
retry-count 1
dead-time 0
last-modified-by
last-modified-date
ORACLE(cert-status-profile)#Direct and Delegated Trust Models
RFC 2560 specifies that an OCSP responder must digitally sign OCSP responses, and that an OCSP client must validate the received signature. In prior releases, successful validation of the signed response served to authenticate the responder. Such an authentication method is referred to as a direct trust model in that it does not require confirmation from a trusted Certificate Authority (CA). Rather it requires that the OCSP client be in possession of the public counterpart of the private key used by the OCSP responder to sign the response. This certificate is identified by the responder-cert attribute in the cert-status-profile configuration element.
The SBC continues support for the direct trust model, while also supporting an alternative delegated trust model as described in Section 5.4.6.2.1.6.1.e.3.c of UCR 2010. The delegated trust model requires that the OCSP responder be authenticated by a trusted CA. Within the DISA/DoD delegated trust model, an OCSP responder certificate is appended to every response, thus eliminating the need for a pre-provisioned responder certificate. The appended certificate is a signing certificate issued and signed by a DoD-approved CA that issued the certificate that is being validated. These OCSP responder certificates have a short lifespan and are reissued regularly.
Direct Trust Model Configuration
The direct trust model is used in virtually all commercial/enterprise environments. Configuration of the direct trust model is unchanged from that contained in the latest version of your hardware or the Oracle Communications Session Border ControllerConfiguration Guide.