Role Separation, keyCertSign CA and cRLSign CA with same AKI(Authority Key Identifier)

[drjoms]

Hello.

I am poking my newly minted EJBCA container with persistant DB.(Awesome Sauce! And thanks!)

I have no expectations. Major players in the PKI/CAB industry don't use Role Separation.

I used to deal with product which did it.

Now I am making a home lab.
I wanted to create a CA trust chain that would have, as per title: Role Separation, keyCertSign CA and cRLSign CA with same Authority Key ID. For bragging rights and general Sh**z and Giggles.
Is this possible?

I was trying to find documentation on EJBCA site and in git hub. But I failed.

I tried something like this:

1. created crypto token, software one.

2. Created two key pairs. Named them appropriately.

3. Created 2 new Certificate Profiles. Where one only did Cert Signign and second only did CRL signing.

4. Created new CA(rsa 4096, because everyone, bigger number is cooler and anything red is going faster!). One with cert signing. So far so good. AKI field is present. only Cert Signing is allowed as per Certificate Profile.

   Version: 3 (0x2)
   Serial Number:
   12:cf:b6:62:8f:a5:fe:22:7a:c2:46:73:3f:f2:d8:56:fc:e1:bc:6d
   Signature Algorithm: sha256WithRSAEncryption
   Issuer: CN=RootCA2 RSA4096
   Validity
   Not Before: Jul 16 22:11:20 2026 GMT
   Not After : Jul 17 22:11:19 2051 GMT
   Subject: CN=RootCA2 RSA4096
   Subject Public Key Info:
   Public Key Algorithm: rsaEncryption
   Public-Key: (4096 bit)
   Modulus:

    X509v3 extensions:
        X509v3 Basic Constraints: critical
            CA:TRUE
        X509v3 Authority Key Identifier: 
            EA:DD:01:5F:5B:7B:9C:ED:32:C3:5F:D8:3C:59:1F:12:F3:B9:FC:96
        X509v3 CRL Distribution Points: 
            Full Name:
              URI:http://ejbca-node1:80/ejbca/publicweb/webdist/certdist?cmd=crl&issuer=CN=TestCA,O=AnaTom,C=SE
            CRL Issuer:
              DirName:CN = TestCA, O = AnaTom, C = SE
        X509v3 Subject Key Identifier: 
            EA:DD:01:5F:5B:7B:9C:ED:32:C3:5F:D8:3C:59:1F:12:F3:B9:FC:96
        X509v3 Key Usage: critical
            Certificate Sign
   

lets not be confused by CRL issues and Full Name. They are red herring as far as I understand it.

5. Now where I fail. I try to create a second CA(?). So what I expect: to have cert signing RSA cert to sign my CRL signing cert. I also expect to bind my CRL signing CA to Authority Key Identifier of existing Cert Signing CA.

I see not a way to associate my second CA cert with first one. AKI number is not an option anywhere.
Technically speaking CRL only "CA Cert" is not really a CA cert. It does NOT need "is a CA" as far as I am aware.(since it wont be creating any new subca/EE certs anyway)

So I tried creating new CRL only CA and fail as i can't bind it to existing CA cert signing CA.

Since its not really a CA, I decided to use RA interface to see if I can issue "End Entity" CRL signer. No such luck there, to chose CRL only profile I created earlier.

If I try to create it as a CA, it should not be possible. Because if I chose it to be signed by Root signing cert CA - it makes it immedeatelly a subca. Which would be a bug(what if create a chain where root CA is ONLY level in a trust chain, apart from EE?)

Cert signing CA has just that one key use.(as per copy paste above)

Am I doing something stupid here?

No rush, and thank you in advance!
Dmitri

[primetomas]

Authority Key ID is derived from the public key of the CA, as per RFC5280.
Generally EJBCA does not support a different CRL signer than the CA. But I would expect the CRL Signer to be a subordinate CA of the cert signer would you not? Especially if it has it's own CRL signing key which is not the same as the cert signing key. If you make your CRL signer a subCA, or an end entity, to the cert signer CA it will get the AKI from the cert signer certificates SKI (which is the AKI/SKI chaining that is key ID is all for).

In order to sign an end entity as you say, why was this not possible? You need to make the certificate profile an end entity certificate profile and not a CA certificate profile. You have the "type" when you create a certificate profile.

So I think there are some non-RFC5280-compliant claim in your experiment. 1. You can not have a Root CA with an AKI that doesn't match it's public key, that does not compute. 2. A separate CRL signer in RFC5280 is a separate entity, i.e. with it's own SKI, but signed by a CA so the AKI matches that CA, the CRL signer is an "end entity". 3. A CRL-only CA does not make any sense, a CA is a "certificate" authority, CRLs are a service to manage those certificates. You can have a "different" CA sign CRLs, but that is specific to an ICAO9303 NameChange where a new CA takes over the responsibility of issuing CRLs for an old CA (it's quite weird and non-RFC5280-compliant but it's how they standardized it).

Those are some thoughts. Always stick within the boundaries of RFC5280ö

[drjoms]

You are absolutely right on so many levels. The hamster wheel in my head finally caught up with the math.

I was trying to force a 'Role Separation' identity onto the Root itself, but as you pointed out, that violates the fundamental relationship between the key and the AKI. A separate CRL signer cannot be the Root; it must be a subordinate (either an End Entity or a Sub-CA) signed by the Root to maintain the chain of trust.

I suspect in the products I dealt with previously, the 'CRL-only CA' was actually an End Entity or an Intermediate CA being abstracted by a GUI, and I failed to verify it with OpenSSL.

Thanks for the patience and for pointing me back to the RFC 5280 reality. I'll go back to my lab with a much better understanding of the hierarchy!
Perhaps I should read RFC one more time.

Fantastic response, to a free tier(read, freeloader) "customer"! Business owners/IT managers should look at this interaction if they consider your product. This is pro response through and through.