locked
Installing OCSP RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi

    I've got a two tier infraestructure in Windows server 2016.

    IIS that provides crls is installed on the issuing ca.

    Now I need to install ocsp and i have read it is recommended the installation on an independent server but I don't know if there is any type of conflict or is just a matter of traffic.

    My organization is small and I don't need to publish revokation information outside my organization.

    Is it a problem installing ocsp on issuing ca?

    Is in this case a best practice installation on an independent server too?

    Thanks in advance

    Tuesday, September 4, 2018 10:17 AM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    The main reason comes down to good practice, reducing the attack surface of a CA by minimising the services that it offers, but technically there is no reason why you could not deploy an OCSP responder onto the same server as a CA.

    On deployments I've worked on, I tend to deploy the web related PKI services onto one or more web servers separately from the CA(s).

    You state that you are already serving CRL requests using IIS from the CA in question, although I would recommend against that in an ideal world for the reasons stated, adding OCSP to the mix will not add any significant risk that you have't already taken.

    Hope this helps.


    • Edited by Mike Elliott Tuesday, September 4, 2018 10:29 AM
    • Proposed as answer by Mike Elliott Tuesday, September 4, 2018 12:49 PM
    • Marked as answer by ZazAra Tuesday, September 4, 2018 5:23 PM
    Tuesday, September 4, 2018 10:23 AM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    The main reason comes down to good practice, reducing the attack surface of a CA by minimising the services that it offers, but technically there is no reason why you could not deploy an OCSP responder onto the same server as a CA.

    On deployments I've worked on, I tend to deploy the web related PKI services onto one or more web servers separately from the CA(s).

    You state that you are already serving CRL requests using IIS from the CA in question, although I would recommend against that in an ideal world for the reasons stated, adding OCSP to the mix will not add any significant risk that you have't already taken.

    Hope this helps.


    • Edited by Mike Elliott Tuesday, September 4, 2018 10:29 AM
    • Proposed as answer by Mike Elliott Tuesday, September 4, 2018 12:49 PM
    • Marked as answer by ZazAra Tuesday, September 4, 2018 5:23 PM
    Tuesday, September 4, 2018 10:23 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    > My organization is small

    > Now I need to install ocsp

    I believe, you don't really need OCSP. You will get no benefit from installing OCSP and will increase management and administrative efforts for nothing. I would review the initial design and evaluate the neccessity of OCSP.

    Microsoft OCSP is built on "high-volume low-cost" paradigm and has benefits in envirionments with high revocation flow. In small environment it brings no value.

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

    Tuesday, September 4, 2018 12:46 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks for your response.

    The reason for installing ocsp is an application that verifies certificates using ocsp and not crls. If it worked with crls, I would never installed ocsp in my organization.

    Tuesday, September 4, 2018 5:16 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thank you for your explanation. That's just what I wanted to know. If there is any technical reason.

    So now, I will decide installing either ocsp role on the issuing CA or ocsp role and iis serving crl on an independent server.

    Tuesday, September 4, 2018 5:23 PM