Merely because of private interest and usage in my own network, I'm creating a certificate chain (Root CA → Intermediate CA → Server cert) using openssl. I'd like the certificate chain to be traceable and also being able to revoke certificates.

At the moment, I am not sure, which CRL distribution Points (crlDistributionPoints in openssl config speech) and OSCP URIs (authorityInfoAccess = OCSP;URI: ... and authorityInfoAccess = OCSP;caIssuers: ...) are the correct ones to set when creating a certificate. Examining the certificates of some public websites, it seems to me, that the following is the way to go. So, would you please check whether I'm right?

Root CA certificate:

  • CRL: Root CA CRL or none at all
  • OCSP URI: OCSP URI of Root CA or none at all
  • CA Issuer: URI of Root CA certificate or none at all

Intermediate CA certificate:

  • CRL: Root CA CRL
  • CA Issuer: URI of Root CA

Server certificate:

  • CRL: Intermediate CA CRL
  • OCSP URI: OCSP URI of Intermediate CA*)
  • CA Issuer: URI of Intermediate CA

*) It seems, one OCSP responder could handle OSCP requests for the Root and the intermediate CA. If so, I could also use the Root CA's OSCP URI, right?

So, every certificates data have to point "one level up", to the location, where its own validity can be checked. Is that correct?

Thank you in advance!

  • Voting to close. The subject is more suitable for ServerFault as it talks about particular application configuration. And we are not giving any software recommendations. – Crypt32 Apr 5 at 17:51
  • Sorry about the last point, I removed the line about the OCSP responder. But anyway, the question is not (...intended to be...) about a specific software configuration. I'm using openssl as an example here, but the "real" underlying question is, if the assumptions i made in the bullet points are correct, which is not specific to openssl but a general certificate related question. – ahuemmer Apr 7 at 15:49

All of these fields have no meaning for the root certificate, as it is already known by the application, and the only way to revoke it is to modify the application. There is no CA more trusted than the root CA to certify that the root is trusted, or that it should no longer be trusted (i.e. revoked).

All of those fields are optional, and the baseline requirements, which define what is required of publicly trusted Certificate Authorities, only require the CRL distribution points for intermediate CA certificates.

CRL distribution points

For CRL distribution points, if you only specify an uri, it is considered to point to a CRL signed by the same issuer, that will contain a reference to this certificate if it is revoked. It is not necessary that all certificates issued by a certificate authority have the same CRL distribution point, and you could segment these so that the CRLs do not grow too much (for example, every 1000 certificates issued, you change the CRL distribution point, and the CRL at that URL will only contain references to those 1000 certificates).

You can however also specify a crlIssuer field in addition to the URL in the CRL distribution point, to specify that the CRL will be signed by a different CA. So you could also point to the same CRL in the leaf certificate and intermediate certificate, and specify in the leaf certificate that the crlIssuer is the root certificate, though that would require you to use the root certificate to revoke a leaf...


For OCSP URIs, it should point to an OCSP server that can provide an OCSP response for the certificate. Similarly to CRLs, you need not use the same server for all certificates issued by a given CA and could segment it, though this is far less common as the OCSP answer does not grow with the number of certificates issued by the CA. You can also point to the same URL as that used by other certificates. An identifier for the certificate for which OCSP is checked is provided in the OCSP query, so that server can answer with the correct answer even if it handles multiples CAs.

CA Issuers

If present, CA issuers must point to a url that contains the certificate that issued the certificate, though that url can contain multiple certificates encoded as a certs-only CMS message. I'm not aware of that possibility being used very often though.


This is all documented in RFC5280 (section for CRL distribution points, and section for Authority Information Access, including OCSP and CA issuers).

| improve this answer | |
  • Thank you a lot for your detailed and comprehensible explanation! Now everything is clear to me. – ahuemmer Apr 8 at 16:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.