locked
OCSP Responder implementation - is the default website required? RRS feed

  • Question


  • Hello,
     I'm implementing a 2 tier pki hierarchy and have a few questions regarding OCSP.

    Firstly, I have an issue whereby I can't install OCSP as the default website on my IIS server has been removed and a custom site has been added.According to the link below, I can add an OCSP virtual directory, but I'm not sure this will help - the article mentions using your own custom virtual directory, however the installation\configuration wizard creates an OCSP virtual APPLICATION - am I supposed to create a custom virtual application to get around this?

     Do I need to set any OCSP values on the root CA? Specifically, do I need to include the OCSP extension in the AIA location for my root CA? So far, I've only checked the value on the Enterprise sub CA.

     In addition, the examples I've seen show OCSP configuration using a single CA, but I have multiple CAs, how can I configure OCSP to handle multiple CAs?

     http://social.technet.microsoft.com/wiki/contents/articles/13767.attempt-to-configure-online-responder-failed-with-error-code-0x80070002-the-system-cannot-find-the-file-specified.aspx

    Thanks in advance.
    Thursday, March 10, 2016 5:50 PM

Answers

  • I would not recommend installing OCSP to a Web site other than the default Web site (and am not sure if it is a supported scenario).

    I would not implement OCSP for the root CA, as the root CA only issue subCA certificates and with the long lived CRL of the root CA (and CRL caching), no need to implement OCSP.

    For multiple CAs, you simply create a revocation configuration for:

    - Each issuing CA in the CA  hierarchy

    - Each active version of each issuing CA's certificate (when you renew with a new key pair).

    The OCSP signing certificate can come from one issuing CA or from each individual issuing CA. The MS implementation does not require that the OCSP signing certificate come from the same CA, but must chain to a trusted root CA on the clients.

    Brian

    Thursday, March 10, 2016 6:32 PM
  • > and am not sure if it is a supported scenario

    it is not supported.


    Vadims Podāns, aka PowerShell CryptoGuy
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: pspki.codeplex.com
    Check out new: SSL Certificate Verifier
    Check out new: PowerShell File Checksum Integrity Verifier tool.

    • Proposed as answer by Amy Wang_ Friday, March 11, 2016 9:41 AM
    • Marked as answer by Amy Wang_ Thursday, March 24, 2016 10:40 AM
    Friday, March 11, 2016 7:07 AM

All replies

  • I would not recommend installing OCSP to a Web site other than the default Web site (and am not sure if it is a supported scenario).

    I would not implement OCSP for the root CA, as the root CA only issue subCA certificates and with the long lived CRL of the root CA (and CRL caching), no need to implement OCSP.

    For multiple CAs, you simply create a revocation configuration for:

    - Each issuing CA in the CA  hierarchy

    - Each active version of each issuing CA's certificate (when you renew with a new key pair).

    The OCSP signing certificate can come from one issuing CA or from each individual issuing CA. The MS implementation does not require that the OCSP signing certificate come from the same CA, but must chain to a trusted root CA on the clients.

    Brian

    Thursday, March 10, 2016 6:32 PM
  • > and am not sure if it is a supported scenario

    it is not supported.


    Vadims Podāns, aka PowerShell CryptoGuy
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: pspki.codeplex.com
    Check out new: SSL Certificate Verifier
    Check out new: PowerShell File Checksum Integrity Verifier tool.

    • Proposed as answer by Amy Wang_ Friday, March 11, 2016 9:41 AM
    • Marked as answer by Amy Wang_ Thursday, March 24, 2016 10:40 AM
    Friday, March 11, 2016 7:07 AM