Compartir a través de

Support for Independent OCSP Signer and Custom OCSP URLs

  • Artículo

Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista

To be considered a valid OCSP signing certificate, the certificate must contain the OCSP Signing Enhanced Key Usage (EKU) object identifier (1.3.6.1.5.5.7.3.9). In addition, the certificate must form a valid chain from the OCSP signing certificate to a trusted root CA. Windows Vista SP1 and Windows Server 2008 support an OCSP Signing certificate that chains to a different root CA than the certificate being checked for revocation status (as shown in Figure 3). If the OCSP signing certificate chains up to a different root CA, the chain must be valid for the OCSP Signing usage. In this figure, the OCSP responder implements a signing certificate that chains to Root CA2, but is signing OCSP responses for the Internal Issuing CA1 that chains to Root CA1.

Additionally, Windows Vista SP1 and Windows Server 2008 enable configuration of custom OCSP download locations through Group Policy.

Figure 3 Implementing an independent OCSP signing certificate

Motivating Scenarios

Windows Vista SP1 and Windows Server 2008 support the following scenarios for implementing custom OCSP URLs in the authority information access extensions and for implementing OCSP signing certificates that are self-signed or chain to a different root CA than the CA certificate:

  1. Specify OCSP download locations for certificates issued without an OCSP URL in the authority information access.

    If you have previously deployed many certificates that did not include an OCSP URL, you can designate an OCSP download location through Group Policy instead of re-configuring the CA and reissuing all affected certificates.

  2. Override existing OCSP URLs in the authority information access with new locations.

    If an organization has deployed internal OCSP URLs in their certificates and now wishes to use the certificates on the external network, the authority information access OCSP URLs must be updated with externally available URLs. Like specifying OCSP download locations for certificates without an OCSP URL, you can designate an externally available URL by using Group Policy.

  3. Use internal OCSP responder when firewall policies prevent network retrieval for revocation checking.

    Some networks do not enable connectivity to external networks. If a certificate was issued by a commercial provider, the lack of connectivity to external networks will prevent successful revocation checking. The clients can be redirected to an internally accessible OCSP URL for certificates issued by the commercial provider. Again, Group Policy can be used to designate the internally accessible URL for OCSP revocation checking.

  4. Check revocation using OCSP when OCSP signer certificate is self-signed.

    If a segment of the network is detached from the rest of the network, clients may be unable to connect to any OCSP responders on the network. For example, a submarine crew may be unable to connect to the military network for a period greater than six months. The use of a self-signed certificate for OCSP signing will enable successful revocation checking of the presented certificates.

  5. Check revocation using OCSP when OCSP signer certificate chains up to a different root than the root for the end-entity certificate chain.

    If an organization has a very diverse PKI with multiple issuing CAs, the organization may want to limit the sources of revocation information and the CAs that can issue OCSP signing certificates. It is possible for the OCSP signing certificate to be issued by a CA that chains to a different root CA than the CA for which the OCSP responder is issuing revocation information.

Building the OCSP Signing Certificate Chain

To allow the use of a different rooted chain for the OCSP signing certificate, the following changes were made to the chaining engine:

  • The certificates, which are part of the chain for the OCSP signing certificate to its root CA, will be sent by the OCSP server as part of the OCSP response. As described in RFC 2560, the OCSP response can also include an explicit sequence of certificates. CryptoAPI 2.0 will look through the certificates in the OCSP response to discover the intermediate certificates that exist between the OCSP signing certificate and the trusted root CA.

  • If the OCSP response does not provide enough information to build a certificate chain, CryptoAPI 2.0 will use the authority information access extension in the OCSP signing certificate to build the certificate chain.

If a certificate chain from the OCSP signing certificate to a trusted root CA cannot be validated, then CryptoAPI 2.0 will return an error message that the revocation server was offline.

Revocation Checking for the OCSP Signing Chain

CryptoAPI 2.0 will perform revocation checking on all certificates in the chain for the OCSP signing certificate. The only exception is if the OCSP signing certificate has the szOID_PKIX_OCSP_NOCHECK (1.3.6.1.5.5.7.48.1.5) extension. In this case, no revocation checking will be performed on the OCSP signing certificate.

During the revocation check of the OCSP signing certificate, the following will occur:

  • All network retrievals for CRLs and OCSP responses are accounted in the cumulative network time-outs for the original chain build.

  • If the result of revocation checking on the OCSP signer certificate chain is revocation offline or unknown, CryptoAPI 2.0 ignores the error and return the revocation status as reported to the original chain build.

  • If the result of the revocation checking on the OCSP signing certificate is revoked, then CryptoAPI 2.0 reports a status of revocation offline for the original chain build.

  • If any other fatal errors are reported for the OCSP signing certificate chain, then CryptoAPI 2.0 reports a status of revocation offline for the original chain build.

In order to avoid the circularity of revocation checking, CryptoAPI 2.0 does not support independent OCSP signer during revocation checking on this chain. CryptoAPI 2.0 supports CRL and delegated OCSP signer only.

Note

If the chain building is monitored in CryptoAPI 2.0 diagnostics, CryptoAPI 2.0 reports the errors in the OCSP signing certificate chain build. CryptoAPI 2.0 diagnostics will assign the OCSP signing certificate chain build the same TaskID as the original chain build. All certificates used in both chain builds will be logged. For more information about using CryptoAPI 2.0 diagnostics, see Troubleshooting PKI Problems on Windows Vista (https://go.microsoft.com/fwlink/?LinkID=102080).