Suppose I have several independent PKIs that are used

  • Two internal PKIs: One with SHA1 support the other with Suite B algorithms.

  • A partner who I trust and have a policy map with.

Since both my PKIs have offline roots, and during chain validation the roots will be in the middle of the computed "chain" (depending on who is validating which certificate), should my offline roots have an AIA or CRL?

2 Answers 2


The Authority Information Access extension is used to publish in a given certificate:

  • where a copy of the issuer's certificate may be downloaded;
  • at which address / URL an OCSP server may be found, which will yield fresh revocation information on the certificate which contains the AIA.

See section of RFC 5280.

Both usages make sense only in a certificate which is meant to have an issuer, i.e. a certificate which is not the first certificate in a validation path. The first certificate in a path is the "trust anchor", aka "the root CA": this is the name+key in which you trust "by definition", not because of a delegation from some issuer. As such, trust anchors have no issuer and no revocation status (they cannot be revoked by some upper CA; at best, you manually decide to cease to trust them). Trust anchors (root CA) are represented as certificates out of tradition but extensions in a root CA make little sense (when such extensions are used, this is often with a semantic which is quite distinct from what the extension usually embodies).

There is a possible confusion which you must learn to avoid: a CA is not the same thing as a CA certificate. A Certification Authority is an entity which has a name (an X.500 Distinguished Name) and a key. That name and that public key can be copied into several distinct certificates. This is common in the situation where two hierarchical PKI decide to "trust each other". Consider two PKI, called (unimaginatively) "A" and "B". Each PKI consists in:

  • a root CA (called "root_A" and "root_B", respectively), which we can imagine as an offline system with a Hardware Security Module;
  • a subordinate CA (called "sub_A" and "sub_B", respectively), which is an online system, possibly also with a HSM, and which issues the end-entity certificates;
  • end-entity certificates.

Each CA, be it online or offline, must publish revocation information on a regular basis, so we must assume that even for the offline CA, there is an online server somewhere, where an adequate CRL is pushed through some manual procedure (or possibly automatically if there is a one-way network link from the root to the online server -- the one-wayness of the link allowing to maintain the offlineness of the CA).

Before PKI A and B decide to trust each other, some certificates exist, with the following characteristics:

  • The name and key of root_A are published as a self-signed certificate, and a copy of that certificate is available on: http://serverA.com/root_A.cer
  • The name and key of sub_A are published as a certificate, signed by root_A, with an AIA which points at the URL where root_A.cer is made available. A copy of the certificate for sub_A is available on: http://serverA.com/sub_A.cer
  • In each end-entity certificate published by sub_A is an AIA which contains the URL on which sub_A.cer resides.
  • Similarly for PKI B.

Thus, a verifier who wants to validate an end-entity certificate from PKI A follows the AIA extensions to download all required certificates, i.e. sub_A.cer. The verifier may also download root_A.cer but this is hardly necessary, since, for validation to succeed, the verifier must already have a copy of this self-signed certificate. Pointers to OCSP servers (also in the AIA) and to CRL (as CRL Distribution Points extensions) follow the same pattern, although, in that case, the pointer to the CRL/OCSP from root_A is not superfluous (verifiers must check that sub_A is not revoked).

Now comes the covenant by which A and B decide to bind their fates, mingle their blood, and generally be best friends forever. To that effect, PKI A and B will "merge", or at least be linked with what is usually known as a "bridge CA". The point is to allow people who trust root_A to automatically accept the end-entity certificates from PKI B as valid. There are mostly four ways to achieve this:

  1. Root_A issues a new certificate for root_B: the certificate contains the name and key of root_B, but this certificate is not self-signed; instead, it is signed by root_A. Let's call bridge_AB.cer this new certificate. Being issued by root_A, this certificate contains an AIA which points at root_A.cer and the OCSP server which maintains revocation status of certificates issued by root_A.

    Since no existing certificate has been altered or revoked or deprecated in any way, people who trust root_B (as a trust anchor) can keep on validating EE certificates from PKI B, as before. For such an EE certificate, the path to validate will be root_B->sub_B.cer->EE for people who have root_B as a trust anchor; for people who have only root_A as a trust anchor, the path will be root_A->bridge_AB.cer->sub_B.cer->EE.

    For this process to work automatically, involved certificates should contain AIA extensions which allow the reconstruction of both chains. In that case, it suffices to replace the root_B.cer (on the serverB.com server) with a copy of bridge_AB.cer, but under the name root_B.cer. Thus, the AIA in sub_B.cer now points to bridge_AB.cer, without needing to change any single bit of sub_B.cer. People who trust root_B can use it directly, they don't even look at the AIA in sub_B.cer (at least for path reconstruction); people who trust root_A only follow the AIA and rebuild the path which begins with root_A. Everything is fine.

    Replacing root_B.cer with the bridge certificate works only as long as there are only two PKI. If a third PKI C joins them in a ménage-à-trois, a more generic method must be employed: a new certificate is issued for sub_B: that certificate will contain an AIA which points at all the certificates for root_B: the old self-signed certificate, bridge_AB.cer, bridge_CB.cer, and so on. The AIA format allows for containing several URI. That new certificate for sub_B can be published as sub_B.cer, replacing the previous one.

  2. Root_A issues a new certificate for sub_B. Since this new certificate is issued by root_A, it contains an AIA which points to root_A.cer. Let's call sub_AB.cer this new certificate.

    At that point, we have an issue with regards to path building. An EE certificate from PKI B still contains an AIA which points to sub_B.cer on server serverB.com. If we replace sub_B.cer with the new certificate issued by root_A (sub_AB.cer), then path building finishes on root_A with no possibility to plug back to root_B: validation for people who trust root_B only is now broken. The generic solution would be to reissue all EE certificates, with a new AIA which points at both certificates for sub_B (the one issued by root_B, and the one issued by root_A). However, mass reissuing is expensive. An alternative way is to "make available" sub_AB.cer to people who want to verify certificates. There is a certificate store in Windows meant for that (called "Intermediate CA"). Even though this certificate will not be referenced in AIA, software should be smart enough to use it where necessary. Since an intermediate CA is not a priori trusted, mass deployment of such a certificate is less problematic than deploying a new trust anchor.

  3. Sub_A issues a certificate for root_B. Treatment is similar to the case 1.

  4. Sub_A issues a certificate for sub_B. Treatment is similar to the case 2.

These four methods are for delegation of trust from PKI A to PKI B, allowing people who trust in root_A to validate EE certificates from PKI B. For a full bridge, the other direction must also be done (people who trust in root_B should be able to validate EE certificates from PKI A). It is not necessary for both bridges to follow the same topology (but the fancier you get, the more confusing the whole thing becomes).

The salient points are that:

  • Any CA can have several certificates, which contain the same name and key. A given certificate (EE or CA) has a single issuer (the entity which signed the certificate) but any certificate containing the name and key of that issuer can be plugged at that point in the path. Correspondingly, certificate paths may merge (X.509 explicitly prohibits full loops).

  • The AIA extensions are used to help in path building, by pointing to potential certificates for the issuer. Use of these certificate is not mandatory; mass deployment of intermediate CA certificates is a viable alternative (at least in organized networks which offer facilities for that, e.g. Active Directory servers).

  • None of this is impacted by policy mappings. It is the other way round: if PKI A and B use certificate policies, and both have their own distinct OID, then the bridge will have to include a mapping, so that verifiers can follow the policies through all paths that the may build.

  • By "extensions in a root CA make little sense" you're only saying that AIA and CRL "extensions" don't make sense... and not referring to EKU or Policies, a Path= in Basic Constraints? Jan 6, 2013 at 21:23
  • I mean that RFC 5280 describes the validation algorithm by beginning with some default values in some variables, some of which describing the "trust anchor" (DN, public key...), but nowhere is it written that the TA is a certificate, and how extensions in such a certificate are to be interpreted. TA as certificates is a widespread usage but there is no consensus on what to do with them besides looking at the name (subjectDN) and the public key. Jan 6, 2013 at 22:48
  • There might be some use in revoking a root certificate via a CRL. In the case of a cross signed CA the Issuer of the root certificate is the cross signer, for that reason an AIA for the issuer might make sense on thie (now intermediate) certificate.
    – eckes
    Jul 12, 2017 at 17:07

Self signed root certificates shouldn't have AIA -- there's no CRL that will be checked by PKIX conforming implementations.

If you have a service that uses certificates issued by your own root, but that must be verifiable using only the other CA then the intermediate should have AIA extension -- it's not a root certificate any more.

To illustrate (correct me if I understood your architecture wrong):

     +---------+                +----------+
     |SHA-1 CA |                |Suite-B CA|
     |         |                |          |
     | public  |                | public   |
     |     key |                |     key  |
     +---+-----+                +----+-----+
         |                           |
         |                           |
         |                           |
         |                           |
     +---+------+               +----+-----+
     |server A  |               |server B  |
     |     cert |               |     cert |
     |          |               |          |
     |public key|               |public key|
     +----------+               +----------+

Now, you want a client to be able to verify the Server A certificate when it only trusts the Suite-B CA. Same thing with Server B and SHA-1 CA

To do that, in effect, both of the CA's have to have two certificates. First certificate is self-signed and the second is signed by the other CA. The catch is, that both have to have the same DN and use the same public key. The other issue is that the server may not present CA certificate to the client and that client has to have the CA certificate in its store (quite regular situation) and the intermediate version of the other CA certificate (not typical situation). This intermediate certificate should have AIA pointing to the other CA CRL DP.

So, for a Suite-B client, the architecture would look like this:

                                |Suite-B CA|
                                |          |
                                | public   |
                                |     key  |
                          ,--~'      |
                 +------~'--+        |
                 |SHA-1 CA  |        |
                 | (a subCA)|        |
                 | public   |        |
                 |     key  |        |
                 +--,-'-----+        |
                ,-~'                 |
             ,-'                     |
     +---,-~'---+               +----+-----+
     |server A  |               |server B  |
     |     cert |               |     cert |
     |          |               |          |
     |public key|               |public key|
     +----------+               +----------+

In this situation, the SHA-1 CA certificate would have AIA and issuer info of the Suite-B CA. From the verifier point's of view this subCA certificate is completely different that the certificate in first diagram.

  • 1
    That is a lovely ASCII drawing ... Aug 20, 2013 at 21:45
  • @Sid: I've made them using JavE: jave.de Aug 26, 2013 at 12:32
  • Which also means unfortunatelly that the AIA-isuer source in "server A" will most likely point to "SHA-1 CA" and not "SHA-1 CA (a subCA)" copy of the certificate. That makes interpreting the cross signing tricky.
    – eckes
    Jul 12, 2017 at 17:09
  • AIA fields are optional so they can be safely omitted. But yes, you need to be careful when adding them in cross-signed environments. Jul 13, 2017 at 15:47

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.